Read the followup by pagexec [LWN.net]

Read the followup by pagexec

Posted Jun 12, 2011 9:07 UTC (Sun) by mingo (subscriber, #31122)
In reply to: Read the followup by pagexec by Julie
Parent article: Quotes of the week

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.

to post comments

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.