What to do in response to a kernel warning

The fundamental problem here is a desire for compartmentalization that simply does not exist.

It seems there are many different kinds of warn()s that can be triggered in different ways at different times. Some might happen in an interrupt handler, others might be the result of a filesystem or driver problem, and then some other might be the result of something actually triggered by userspace. So not only are warn()s not tagged by probable cause, but tagging them with that may be impossible.

Warn()s also occur in the shared security boundary of "all of kernel space." There is not theoretical limit to what state might be contaminated. It might be limited to only what is currently being processed. It might affect the whole subsystem. Or it could lead to corruption to anything else the kernel is doing and possibly take the whole system down. So not only are warn()s not tagged with their probably effects, but it's quite possibly impossible to do so.

Without knowing what caused a warn, and what effects it might have, it is impossible to take any decision more fine-grained than "do nothing" or "reset the system." You can't reliably kill the culprit or avoid the conditions that caused it. You can't reliably determine the affected area and pick an appropriate mitigation (flushing a buffer, killing a process, killing a subsystem, or indeed shutting down a totally-compromised system).

What the kernel devs desire is a system like minix, where the various subsystems are isolated enough that anything bad happening in one is reasonably assured to not have affected the others, and where the components are fine grained enough that one experiencing a problem can be automatically killed without too much cost. This is fundamentally impossible outside of a microkernel.

I'm not saying that minix or other microkernels are better, but I am saying that what people desire is just not an option with the design choices that linux has made.