Read the followup by pagexec [LWN.net]

Read the followup by pagexec

Posted Jun 12, 2011 0:38 UTC (Sun) by Julie (guest, #66693)
In reply to: Read the followup by pagexec by spender
Parent article: Quotes of the week

you've categorized already a subset of all bugs into "serious" bugs, and then further categorized them into boot issues, filesystem corruption, driver problems, general crashes, and potential security issues.

Not really, with respect, _you_ just did. I just thought I'd mentioned a varied collection of bug examples (whilst not being altogether serious in my choice of 'serious' ones)- bugs can result in more than one type of offending behaviour, and sometimes might even be discovered/fixed _by accident_ when the bugfixer is fixing up something else.

Which is why I think the most sensible thing is to find bugs regardless of their effect, which to me is what 'a bug is a bug' means - it's a philosophical _starting point_, not an attempt to blur together classifications that may be artificial anyway. Some observed misbehaviour might tell you where to start looking but even then you might be wrong with any assumptions you immediately jump to and it's a good idea to be humble enough to allow the possibility. At best, you avoid a very red face later.
At the simplest level you look at suspicious code or features, find things that shouldn't be there and are or should be there and aren't, and fix it (well, sometimes this turns into development...).

Argue about whether it's a bug by all means and definitely discuss its context and the best way of fixing it in light of the intended purpose and possible side effects of the code it's in, but come to a conclusion and sort it. That does seem to be what the mailing list is for.
And don't spend all day explaining to others exactly how and why you did it, why would you want to do that, there are plenty more to fix? ;-)

Clarity from upstream is great (and I've seen maintainers make contributors go back and re-write changelogs to make them clearer) but nobody that writes code cares for explaining piecemeal to everyone what they did. You'd spend all your time documenting your changes instead of making them.
The poor documentation/lack of helpful comments in code/unhelpful config 'help' that sometimes results from this attitude irritates or inconveniences me a lot more than shoddy changelogs. Users probably won't read the changelogs and reviewers probably ought to look at the code too in any case. But from what I've seen any idea of a deliberate campaign of obfuscation is a fantasy.

So for you, as with everyone, you're concerned about serious bugs, but you don't care what type they are.

Actually, I am concerned about all bugs. I want a perfect kernel :-) It's a quality issue and if Linux can't do it with its talent and development model then no-one can.
It might be a practical impossibility, but this is due to restrictions imposed by a shortage of bug fixers/time. Not to do with aspiration or potential or even method :-)

Are you using a distro kernel? How often are you updating?

I use a distro kernel until I've set up my git kernel tree on the machine and done a hand-stripped config, then I use -next-2011whatever or -rcN or whatever I just built (including patch testing kernels I'm too lazy to reboot from :-)). Having said that I do keep an eye on updates and occasionally use the distro kernels and I've never had problems. I know that means I'm not a typical 'user' and if I was a server admin or someone I might take a different attutude - but I did say it 'works for me'.

to post comments

Read the followup by pagexec

Posted Jun 12, 2011 9:07 UTC (Sun) by mingo (subscriber, #31122) [Link] (2 responses)

Btw., the primary way we back-port fixes to -stable is to simply consider whether the bug fix is relevant to the -stable tree - i.e. we try to answer the "does this fix a bug in an earlier kernel as well?" question.

That is something that bug fixers are generally capable to determine and they are willing to classify it. It's basically the same task they already did when fixing the bug, just time shifted back 3 or 6 months. It's not perfect but it works reasonably well in practice.

The "could this bug possibly be used to be a parasite in the system" question is a lot less interesting and a lot less natural to the average bug fixer (they are not thinking like parasites) and hence this information is a lot less obvious to extract and it's thus also not part of the regular flow of fixing bugs. It is also a lot more complex mathematically, because the space of potential unintended interactions between kernel bugs and the rest of the kernel and thousands of applications is very, very large. It's hard enough for bug fixers to consider all the intended interactions.

So at this stage we do not pretend to be able to answer that question, and we refuse to participate in the CVE security circus, for all the reasons outlined above.

So yes, the upstream policy is that a bug is a bug and that is applied consistently across the board, to -stable as well.

Read the followup by pagexec

Posted Jun 12, 2011 10:09 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

I'll note that bug fixers tend to only look back a short while when considering -stable fixes (if you look at the number of changesets in the various long-term and -stable supported kernels, you will see that they tend to get a lot of fixes initially, but that the rate of fixes tapers off fairly rapidly)

Read the followup by pagexec

Posted Jun 12, 2011 12:54 UTC (Sun) by mingo (subscriber, #31122) [Link]

I'll note that bug fixers tend to only look back a short while when considering -stable fixes (if you look at the number of changesets in the various long-term and -stable supported kernels, you will see that they tend to get a lot of fixes initially, but that the rate of fixes tapers off fairly rapidly)

Well, that's an expected curve: current empirical studies show that the distribution / time evolution of software defects goes along a Simon-Yule distribution - which goes down sharper than a bell curve as time goes on.

It's also roughly what you get if you use a simple bug fixing model: take the set of bugs still unfixed, and let bug fixers (developers) random walk the code, then there's a fixed probability to find a bug, with every man-hour spent on looking at the code.

As time goes on, the probability increases that a bug will be found, with a 1-1/t probability, where 't' is the time spent on the code. It will be like a bell-curve for a given difficulty of bug. The 'difficulty' of bugs is a constant parameter, so the combined bug metric would show the integral of 1-d/t ('d': difficulty, 't': time), integrated over 'd' and 't', which would still roughly be a bell curve in practice.

Thus older kernels seeing fewer fixes is natural and expected and is not in itself a sign of less attention.

There's also another aspect: the Cc: stable tag does not typically limit how far a fix is getting ported back - that is decided by the -stable maintainers. They will generally port is back as far as it will still cherry-pick cleanly - and they'll notify the patch submitter if there's a conflict with older stable kernels.

But yes, the older a stable kernel is, the higher the chance that a bug is missed and is not backported - this is a classic trade-off.