Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755352AbbDUPYF (ORCPT ); Tue, 21 Apr 2015 11:24:05 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:51877 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751753AbbDUPYA (ORCPT ); Tue, 21 Apr 2015 11:24:00 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Wang\, Xiaoming" Cc: Tejun Heo , "akpm\@linux-foundation.org" , "oleg\@redhat.com" , "andriy.shevchenko\@linux.intel.com" , "linux\@rasmusvillemoes.dk" , "eparis\@redhat.com" , "chenhanxiao\@cn.fujitsu.com" , "tglx\@linutronix.de" , "linux-kernel\@vger.kernel.org" , "Schallberger\, Timothy M" , "Zhang\, Dongxing" References: <1429236796-22387-1-git-send-email-xiaoming.wang@intel.com> <20150417025624.GA12709@htj.duckdns.org> Date: Tue, 21 Apr 2015 10:19:42 -0500 In-Reply-To: (Xiaoming Wang's message of "Fri, 17 Apr 2015 05:36:56 +0000") Message-ID: <87k2x5tsoh.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1//5SR/of/zIMn2QUBmQKBGazl8FkBbwwY= X-SA-Exim-Connect-IP: 97.119.22.70 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 XMSubMetaSx_00 1+ Sexy Words * 1.2 XMSubMetaSxObfu_03 Obfuscated Sexy Noun-People X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;"Wang\, Xiaoming" X-Spam-Relay-Country: X-Spam-Timing: total 657 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.1 (0.5%), b_tie_ro: 2.3 (0.3%), parse: 0.65 (0.1%), extract_message_metadata: 27 (4.0%), get_uri_detail_list: 3.7 (0.6%), tests_pri_-1000: 14 (2.1%), tests_pri_-950: 1.19 (0.2%), tests_pri_-900: 0.93 (0.1%), tests_pri_-400: 27 (4.2%), check_bayes: 26 (4.0%), b_tokenize: 8 (1.3%), b_tok_get_all: 10 (1.5%), b_comp_prob: 2.5 (0.4%), b_tok_touch_all: 3.6 (0.5%), b_finish: 0.67 (0.1%), tests_pri_0: 575 (87.5%), tests_pri_500: 5 (0.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] proc: move the adding option Ngid to the end of proc/PID/status X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3552 Lines: 80 "Wang, Xiaoming" writes: > Dear tejun > >> -----Original Message----- >> From: htejun@gmail.com [mailto:htejun@gmail.com] On Behalf Of Tejun Heo >> Sent: Friday, April 17, 2015 11:42 AM >> To: Wang, Xiaoming >> Cc: akpm@linux-foundation.org; oleg@redhat.com; >> andriy.shevchenko@linux.intel.com; linux@rasmusvillemoes.dk; >> ebiederm@xmission.com; eparis@redhat.com; chenhanxiao@cn.fujitsu.com; >> tglx@linutronix.de; linux-kernel@vger.kernel.org; Schallberger, Timothy M; >> Zhang, Dongxing >> Subject: Re: [PATCH] proc: move the adding option Ngid to the end of >> proc/PID/status >> >> On Thu, Apr 16, 2015 at 11:37 PM, Wang, Xiaoming >> wrote: >> >> git describe --contains says 3.13 and it's about 1.5 years ago. >> >> >> > Yes this kernel change is 1.5 years ago. >> > As we known not all user update the kernel so frequently. >> > They just use the stable one. >> > We met this issue when update to 3.13 now. >> > A lot of application failed to run which run well previously. >> > Do you have any idea on this issue? >> >> Not really. It's a sucky situation. How many applications are we talking about? I >> tried to find information on libsecuritysdk but couldn't find it anywhere. >> > This lib libsecuritysdk is included in application. > Taobao, weibo, tmall, alipay, etc > It refer to security . *cough* snake oil *cough* Buggy non-robust code that is sold as providing a security function deeply disturbs me. In this case libsecuritysdk is clearly buggy. The point of labels at the beginning of lines is so that order is irrelevant. If this had been reported by someone who cares enough to test any time during the 6 weeks of an rc series or even shortly after a stable release we would have take this patch immediately. Because breaking userspace is something we don't want to do, and it would have been clear what the trade-offs are. In this case Tejun is right. We need to weigh the risk of fixing one application against the risk of breaking others. So far there has been no analysis about the possibility what other software might be affected by this change. With respect to testing, linux is developed as a community and it is the responsibility for everyone in the community to pitch in and do what they can for the bits they care about. As best as I can infer libsecuritysdk is doing it's best to ensure that a debugger is not attached while the library is being run. The code appears to be binary and proprietary. So the entire community of developers can not go out and read the code and see what is going on. This places a higher burden on those who develop and maintian libsecuritysdk to test and to verify their software will work with future versions of the linux kernel, and to more promptly bring issues to our attention. In this instance until due dilligence has been done to indicate that making the change proposed will not result in another bug report in another 1.5 years from now about a different piece of software I am inclined to strongly suggest we do nothing. Further is there any indication that even with this small change that the applications that use libsecuritysdk will work on 4.1-rc1 when it comes out in the next couple of days? Or even that those applications work on 4.0? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/