|
Message-ID: <20211001122348.GB965@pathway.suse.cz> Date: Fri, 1 Oct 2021 14:23:48 +0200 From: Petr Mladek <pmladek@...e.com> To: Alexander Popov <alex.popov@...ux.com> Cc: "Paul E. McKenney" <paulmck@...nel.org>, Jonathan Corbet <corbet@....net>, 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>, 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.deacon@....com>, David S Miller <davem@...emloft.net>, Borislav Petkov <bp@...en8.de>, kernel-hardening@...ts.openwall.com, linux-hardening@...r.kernel.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, notify@...nel.org, Linus Torvalds <torvalds@...ux-foundation.org>, Dmitry Vyukov <dvyukov@...gle.com> Subject: Re: [PATCH] Introduce the pkill_on_warn boot parameter On Thu 2021-09-30 18:05:54, Alexander Popov wrote: > On 30.09.2021 12:15, Petr Mladek wrote: > > On Wed 2021-09-29 12:49:24, Paul E. McKenney wrote: > >> On Wed, Sep 29, 2021 at 10:01:33PM +0300, Alexander Popov wrote: > >>> This patch was tested using CONFIG_LKDTM. > >>> The kernel kills a process that performs this: > >>> echo WARNING > /sys/kernel/debug/provoke-crash/DIRECT > >>> > >>> If you are fine with this approach, I will prepare a patch adding the > >>> pkill_on_warn sysctl. > >> > >> I suspect that you need a list of kthreads for which you are better > >> off just invoking panic(). RCU's various kthreads, for but one set > >> of examples. > > > > I wonder if kernel could survive killing of any kthread. I have never > > seen a code that would check whether a kthread was killed and > > restart it. > > The do_group_exit() function calls do_exit() from kernel/exit.c, which is also > called during a kernel oops. This function cares about a lot of special cases > depending on the current task_struct. Is it fine? IMHO, the bigger problem is that nobody will start the kthreads again. As a result, some kernel functionality will not longer work. User space threads are different. The user/admin typically have a chance to start them again. We might get inspiration in OOM killer. It never kills kthreads and the init process, see oom_unkillable_task(). It would be better to panic() when WARN() is called from a kthread or the init process. Best Regards, Petr
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.