[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Yis8oPagDlPNQM0y@alley>
Date: Fri, 11 Mar 2022 13:12:16 +0100
From: Petr Mladek <pmladek@...e.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Kees Cook <keescook@...omium.org>,
Marco Elver <elver@...gle.com>, Jens Axboe <axboe@...nel.dk>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kthread: Make it clear that create_kthread() might be
terminated by any fatal signal
On Thu 2022-03-10 12:14:28, Eric W. Biederman wrote:
> Petr Mladek <pmladek@...e.com> writes:
>
> > The comments in kernel/kthread.c create a feeling that only SIGKILL
> > is able to break create_kthread().
> ^^^^^^^^^^^^^^^^ __kthread_create_on_node
>
> Signals can't affect create_kthread in any was as it is only called by
> kthreadd. It is __kthread_create_on_node which gets interrupted by
> fatal signals.
Great catch! I wanted to use the public API. I missed that
create_kthread() is used by the "kthreadd" side.
Heh, there actually is "kthread_create()" macro that substitutes
kthread_create_on_node().
> > In reality, wait_for_completion_killable() might be killed by any
> > fatal signal that does not have a custom handler:
> >
> > Update the comments in kernel/kthread.c to make this more obvious.
>
> Except for the minor nit in the change description.
> Reviewed-by: "Eric W. Biederman" <ebiederm@...ssion.com>
Thanks.
I am going to send v2 next week to give time more potential
reviewers.
Best Regards,
Petr
Powered by blists - more mailing lists