On Sat, Nov 13, 2021 at 10:14 AM Alexander Popov <alex.popov@xxxxxxxxx> wrote:
>
> Killing the process that hit a kernel warning complies with the Fail-Fast
> principle [1].
The thing is a WARNING.
It's not even clear that the warning has anything to do with the
process that triggered it. It could happen in an interrupt, or in some
async context (kernel threads, whatever), or the warning could just be
something that is detected by a different user than the thing that
actually caused the warning to become an issue.
If you want to reboot the machine on a kernel warning, you get that
fail-fast thing you want. There are two situations:
- kernel testing (pretty much universally done in a virtual machine,
or simply just checking 'dmesg' afterwards)
- hyperscalers like google etc that just want to take any suspect
machines offline asap
But sending a signal to a random process is just voodoo programming,
and as likely to cause other very odd failures as anything else.
I really don't see the point of that signal.
I'm happy to be proven wrong, but that will require some major
installation actually using it first and having a lot of strong
arguments to counter-act the above.
Seriously, WARN_ON() can happen in situations where sending a signal
may be a REALLY BAD idea, never mind the issue that it's not even
clear who the signal should be sent to.
Yes, yes, your patches have some random "safety guards", in that it
won't send the signal to a PF_KTHREAD or the global init process. But
those safety guards literally make my argument for me: sending a
signal to whoever randomly triggered a warning is simply _wrong_.
Adding random "don't do it in this case" doesn't make it right, it
only shows that "yes, it happens to the wrong person, and here's a
hack to avoid generating obvious problems".
Honestly, if the intent is to not have to parse the dmesg output, then
I think it would be much better to introduce a new /proc file to read
the kernel tainting state, and then some test manager process could be
able to poll() that file or something. Not sending a signal to random
targets, but have a much more explicit model.
That said, I'm not convinced that "just read the kernel message log"
is in any way wrong either.
Linus
