Kernel quality control, or the lack thereof

Posted Dec 30, 2018 11:22 UTC (Sun) by GoodMirek (guest, #101902)
In reply to: Kernel quality control, or the lack thereof by anton
Parent article: Kernel quality control, or the lack thereof

There are safety nets triggered only in cases impossible to reach via software means, but possible to happen in case of HW failure.
I saw that multiple times while working on embedded systems.

E.g.:
explosiveness=255;
if explosiveness !=255 then assert;

In theory, it should never assert. In reality, it is desirable to minimize a risk that 'explosiveness' variable is stored in a failed memory cell, prior that cell is used for indication of explosiveness of any kind.

Or this case:
if <green> then
explosiveness=0;
else
explosiveness=255;
if (explosiveness!=0 and explosiveness!=255) then assert;

It is very rare to trigger and almost impossible to test such assertions, but when I saw them triggered in reality, even once in a lifetime, I appreciated their merit.

Kernel quality control, or the lack thereof

Posted Dec 30, 2018 15:44 UTC (Sun) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Assuming that timing considerations permitted it, one approach would be to run the code in a simulator that provided fault-injection for memory. That said, to your point, you would have to inject the fault rather carefully to trigger that particular set of assertions.

But if the point was in fact to warn about unreliable memory, mightn't this sort of fault injection nevertheless be quite useful?