Kernel quality control, or the lack thereof

Posted Dec 11, 2018 14:11 UTC (Tue) by PaulMcKenney (✭ supporter ✭, #9624)
In reply to: Kernel quality control, or the lack thereof by marcH
Parent article: Kernel quality control, or the lack thereof

I have seen 80% used with some decent results. But it really depends on the code and its user base. 100% of your commonly executed code really does need to be covered. But of course the more users your code has, the larger the fraction of your code is commonly executed.

If only (say) 30% of your code is tested, you very likely need to substantially increase your coverage. If (say) 90% of your code is tested, there is a good chance that there is some better use of your time than getting to 91%. But for any rule of thumb like these, there will be a great many exceptions, for example, the safety-critical code mentioned earlier.

Hey, you asked! :-)

Kernel quality control, or the lack thereof

Posted Dec 11, 2018 20:53 UTC (Tue) by marcH (subscriber, #57642) [Link]

> Hey, you asked! :-)

Sincere thanks!

Kernel quality control, or the lack thereof

Posted Jan 5, 2019 18:06 UTC (Sat) by joseph.h.garvin (guest, #64486) [Link] (1 responses)

I think you have things backwards. If there is a bug in commonly executed code it's going to be exposed even if there isn't a test. It's the infrequently executed code that tends to contain bugs (e.g. handling error conditions). Testing the frequently executed code still has value in that it can prevent problems from reaching customers, but bugs in frequently executed code will tend to be discovered very quickly. In a sense what the entire point of tests is is to make it so some code paths are more frequently executed.

Kernel quality control, or the lack thereof

Posted Jan 5, 2019 22:29 UTC (Sat) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Especially in my part of the Linux kernel, there is great value in preventing problems from reaching the -tip tree, let alone Linus's tree, let alone distributions, let alone customers. This great value stems from the fact that RCU bugs tend to be a bit difficult to reproduce and track down. It is therefore quite important to test the common cases.

Nevertheless, your last sentence is spot on. It is precisely because rcutorture forces rare code paths and rare race conditions to execute more frequently that the number of RCU bugs reaching customers is kept down to a dull roar.