Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Fri, 11 Mar 2022 13:12:16 +0100
From:   Petr Mladek <pmladek@suse.com>
To:     "Eric W. Biederman" <ebiederm@xmission.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
        Kees Cook <keescook@chromium.org>,
        Marco Elver <elver@google.com>, Jens Axboe <axboe@kernel.dk>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kthread: Make it clear that create_kthread() might be
 terminated by any fatal signal
Message-ID: <Yis8oPagDlPNQM0y@alley>
References: <20220310093455.15176-1-pmladek@suse.com>
 <871qz9brp7.fsf@email.froward.int.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <871qz9brp7.fsf@email.froward.int.ebiederm.org>
Precedence: bulk

On Thu 2022-03-10 12:14:28, Eric W. Biederman wrote:
> Petr Mladek <pmladek@suse.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@xmission.com>

Thanks.

I am going to send v2 next week to give time more potential
reviewers.

Best Regards,
Petr