"Wang, Xiaoming" <xiaoming.w...@intel.com> writes: > Dear tejun > >> -----Original Message----- >> From: hte...@gmail.com [mailto:hte...@gmail.com] On Behalf Of Tejun Heo >> Sent: Friday, April 17, 2015 11:42 AM >> To: Wang, Xiaoming >> Cc: a...@linux-foundation.org; o...@redhat.com; >> andriy.shevche...@linux.intel.com; li...@rasmusvillemoes.dk; >> ebied...@xmission.com; epa...@redhat.com; chenhanx...@cn.fujitsu.com; >> t...@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 >> <xiaoming.w...@intel.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
