Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Let me suggest one thing to you: Pragmatism.
what security fix?
Posted Nov 9, 2008 21:52 UTC (Sun) by ncm (subscriber, #165)
A useful remark would be "this fixes a bug in SCTP", which means I can skip it, and be the better off for skipping it if I don't run any programs that use SCTP.
Posted Nov 10, 2008 14:09 UTC (Mon) by tialaramex (subscriber, #21167)
It would be relatively easy to carve out patches that only touch code in a specific area of the tree (for example, the SCTP implementation). But the recent e1000e bug illustrates beautifully that bugs aren't very good at respecting modularisation of design, since they're not designed but are instead unintentional.
If you do want to try this, as I said, it's fairly possible, Git makes it very practical for you to knock together a script that lists only those patches which touch your subset of the kernel, assuming you have the technical knowledge to understand how the kernel is laid out, and you have a complete list of the components you do or don't use, plus the time to examine architectural changes that might alter that list.
One thing that's going on is that there are many different constituencies who think that the kernel developers ought to make /their/ lives easier by doing just a minute or two's extra work. Since the kernel developers are a very precious resource I suggest that wherever possible you should look for ways to make things better without asking the developers to do more paperwork for you.
Posted Nov 10, 2008 14:54 UTC (Mon) by PaXTeam (subscriber, #24616)
huh? are you sure you understood the discussion at all? since when is withholding information *less* work than simply passing along what they already have?
Posted Nov 10, 2008 18:00 UTC (Mon) by tialaramex (subscriber, #21167)
I have a copy of the novel "A Fire Upon the Deep" here but those tired of this increasingly long thread will be glad to know that it was perfectly simple to "withhold" the contents of the novel from this message, I simply didn't choose to manually retype the entire thing into this little text box, saving myself hours of work.
On the other hand, this post will automatically identify me as the poster. To create another account in order to disguise my true identity would be a considerable amount of work just to withhold some information...
Posted Nov 10, 2008 19:24 UTC (Mon) by PaXTeam (subscriber, #24616)
Posted Nov 10, 2008 18:23 UTC (Mon) by iabervon (subscriber, #722)
Then everybody would want to apply the patch, since either it would provide a benefit (either stability or security) or it would not require any downtime to apply. For that matter, it would be nice to have a make target that wouldn't recopy modules that hadn't changed, and an lsmod flag to show modules which are different on disk from what's loaded.
Posted Nov 10, 2008 18:31 UTC (Mon) by dlang (✭ supporter ✭, #313)
Posted Nov 9, 2008 22:15 UTC (Sun) by efexis (guest, #26355)
If there are known security issues, I need to know, because I need to protect my servers and my clients, either by applying the fix, or by creating a seperation between the bug and potential triggers of it. If not, if it's say, timing tweaks to the schedulars to undo a regression, I need to make sure that it applies to me. If the regression hasn't affected my workloads, changes to the schedular could, and I wouldn't want to apply it without some stress testing during a planned upgrade time (we lost *loads* during early 2.6.2x kernels as IO would grind to a halt under certain loads as each of the cores just seemed to be blocking... the problem went away dropping back to the maintained 2.6.16 series, and post 2.6.25 seems okay, but boy did it cost us and did we learn our lesson).
Note that this isn't a complaint, I play about with risky experimental code because I enjoy the new stuff. If I thought they were crap, I wouldn't be using their kernel.
Posted Nov 10, 2008 2:01 UTC (Mon) by qg6te2 (guest, #52587)
Personally I'd like to know whether a kernel upgrade fixes a "known possible security bug", where the bug can be triggered by a deliberate and remote attack. However, one can also suspect that a reason for the rather obfuscated security warnings by Greg KH et al (i.e. "strongly encouraged to upgrade") is not the definition of a security issue, but the politics of the Linux Foundation. Once a bug has a CVE number, the count of security issues in Linux goes up. Obviously it's very useful for marketing reasons if the number of security issues in Linux is lower than other systems. Hence why add to the count of security bugs (even though they may lack CVEs), through kernel update disclosures ?
Posted Nov 10, 2008 7:21 UTC (Mon) by nix (subscriber, #2304)
Posted Nov 10, 2008 8:12 UTC (Mon) by PaXTeam (subscriber, #24616)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds