[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wg+UMNYrR59Z31MhxMzdUEiZMQ1RF9jQvAb6HGBO5EyEA@mail.gmail.com>
Date: Sat, 13 Nov 2021 11:58:13 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Alexander Popov <alex.popov@...ux.com>
Cc: Jonathan Corbet <corbet@....net>, Paul McKenney <paulmck@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>, Joerg Roedel <jroedel@...e.de>,
Maciej Rozycki <macro@...am.me.uk>, Muchun Song <songmuchun@...edance.com>,
Viresh Kumar <viresh.kumar@...aro.org>, Robin Murphy <robin.murphy@....com>,
Randy Dunlap <rdunlap@...radead.org>, Lu Baolu <baolu.lu@...ux.intel.com>,
Petr Mladek <pmladek@...e.com>, Kees Cook <keescook@...omium.org>,
Luis Chamberlain <mcgrof@...nel.org>, Wei Liu <wl@....org>, John Ogness <john.ogness@...utronix.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Alexey Kardashevskiy <aik@...abs.ru>,
Christophe Leroy <christophe.leroy@...roup.eu>, Jann Horn <jannh@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Mark Rutland <mark.rutland@....com>,
Andy Lutomirski <luto@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>,
Steven Rostedt <rostedt@...dmis.org>, Will Deacon <will@...nel.org>, Ard Biesheuvel <ardb@...nel.org>,
Laura Abbott <labbott@...nel.org>, David S Miller <davem@...emloft.net>, Borislav Petkov <bp@...en8.de>,
Arnd Bergmann <arnd@...db.de>, Andrew Scull <ascull@...gle.com>, Marc Zyngier <maz@...nel.org>,
Jessica Yu <jeyu@...nel.org>, Iurii Zaikin <yzaikin@...gle.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>, Wang Qing <wangqing@...o.com>,
Mel Gorman <mgorman@...e.de>, Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
Andrew Klychkov <andrew.a.klychkov@...il.com>,
Mathieu Chouquet-Stringer <me@...hieu.digital>, Daniel Borkmann <daniel@...earbox.net>, Stephen Kitt <steve@....org>,
Stephen Boyd <sboyd@...nel.org>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Mike Rapoport <rppt@...nel.org>, Bjorn Andersson <bjorn.andersson@...aro.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, linux-hardening@...r.kernel.org,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, linux-arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>, notify@...nel.org, main@...ts.elisa.tech,
safety-architecture@...ts.elisa.tech, devel@...ts.elisa.tech,
Shuah Khan <shuah@...nel.org>, Lukas Bulwahn <lukas.bulwahn@...il.com>
Subject: Re: [PATCH v2 0/2] Introduce the pkill_on_warn parameter
On Sat, Nov 13, 2021 at 10:14 AM Alexander Popov <alex.popov@...ux.com> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
