I dislike these kind of random tests. You hit a rare error but it can be very hard to debug because the triggering is random and coupled to timing issues which can be very hard to reproduce. I also dislike this because it makes changes to the actual running kernel. It is not a black box test.
The solution I prefer is unit testing. You take your subsystem, isolate it by stubbing all calls and make a test suite to run in user space. This test program should explicitly handle all the border cases. You can use a coverage scope to see you hit a high fraction of the code with your test. And it should do it deterministic.
This gives some huge benifites to development:
You get a must faster development cycle because you don't have to recompile and run boot the kernel for each change, only your subsystem and test program. You can easily debug it in gdb.
To do this you have to have loosely coupled subsystems. Therefore, when you start forcing yourself to work this way, you automatically get a better architecture.
You feel safe about changing a system because you know a lot of the bugs you might introduce will be caught by the test suite. Thus you avoid "coding in fear" which always produce bad code.
So here it is my suggestion:
Make a test directory in the kernel source. Put all kind of unit test suites in there. All kernel patches should parse all tests. A patch to the kernel also contains changes to the tests as they are developed along with the kernel code.
I made such a "TestRTMutex" to code on the rt-mutex. It worked really well. I could do at least some SMP coding without having actual SMP hardware. Unfortunately, it isn't maintained along with the kernel code and is thus not useable now.
At work I decided to do this unit-testing on a project. My boss was a bit worried why it took so long to make the code, but when I merged it into our application there was almost no errors, because almost every line of code was tested in detail.
If unit tests were to get established within the kernel, you will see the number of "oops, that was a mistake" released get much, much smaller. You have tests for many error paths in the code. You still need an integration test of course, but there is no need for injecting faults into a running kernel. That is much better done in unit tests in user-space.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds