Kernel quality control, or the lack thereof

Posted Jan 5, 2019 18:06 UTC (Sat) by joseph.h.garvin (guest, #64486)
In reply to: Kernel quality control, or the lack thereof by PaulMcKenney
Parent article: Kernel quality control, or the lack thereof

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.