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
