From:   "Eric W. Biederman" <ebiederm@xmission.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Alexey Gladkov <legion@kernel.org>,
        Kyle Huey <me@kylehuey.com>, Oleg Nesterov <oleg@redhat.com>,
        Kees Cook <keescook@chromium.org>,
        Heiko Carstens <hca@linux.ibm.com>,
        Vasily Gorbik <gor@linux.ibm.com>,
        Christian Borntraeger <borntraeger@de.ibm.com>,
        Alexander Gordeev <agordeev@linux.ibm.com>,
        Martin Schwidefsky <schwidefsky@de.ibm.com>
References: <87a6ha4zsd.fsf@email.froward.int.ebiederm.org>
        <20211208202532.16409-6-ebiederm@xmission.com>
        <YdelKq9U86/dHPcm@zeniv-ca.linux.org.uk>
        <87mtk6xegz.fsf@email.froward.int.ebiederm.org>
        <YdpWHgJBwEF/21hR@zeniv-ca.linux.org.uk>
Date:   Mon, 10 Jan 2022 09:05:22 -0600
In-Reply-To: <YdpWHgJBwEF/21hR@zeniv-ca.linux.org.uk> (Al Viro's message of
        "Sun, 9 Jan 2022 03:27:26 +0000")
Message-ID: <87a6g3y6kt.fsf@email.froward.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH 06/10] exit: Implement kthread_exit
Precedence: bulk

Al Viro <viro@zeniv.linux.org.uk> writes:

> On Sat, Jan 08, 2022 at 12:35:40PM -0600, Eric W. Biederman wrote:
>
>> There are kernel threads started by modules that do:
>> 	complete(...);
>>         return 0;
>> 
>> That should be at a minimum calling complete_and_exit.  Possibly should
>> be restructured to use kthread_stop().
>> 
>> Some of those users of the now removed thread_exit() in staging are
>> among the offenders.
>> 
>> However thread_exit() was implemented as:
>> 	#define thread_exit() complete_and_exit(NULL, 0)
>> 
>> Which does nothing with a completion, it was just a really funny way to
>> spell "do_exit(0)".
>
> Yes.  And there's a plenty of cargo-culting in that area.
>  
>> While I agree digging through all of the kernel threads and finding the
>> ones that should be calling complete_and_exit is a fine idea.  It is
>> a concern independent of these patches.
>
> BTW, could somebody explain how could this
> /*
>  * Prevent the kthread exits directly, and make sure when kthread_stop()
>  * is called to stop a kthread, it is still alive. If a kthread might be
>  * stopped by CACHE_SET_IO_DISABLE bit set, wait_for_kthread_stop() is
>  * necessary before the kthread returns.
>  */
> static inline void wait_for_kthread_stop(void)
> { 
>         while (!kthread_should_stop()) {
>                 set_current_state(TASK_INTERRUPTIBLE);
>                 schedule();
>         }
> } 
>
> in drivers/md/bcache/bcache.h possibly avoid losing wakeups?
>
> AFAICS, it can be called while in TASK_RUNNING.  Suppose kthread_stop()
> gets called just after the check for kthread_should_stop().  Our thread
> is still in TASK_RUNNING; kthread_stop() sets the flag for the next
> kthread_should_stop() to observe and does wake_up_process() to our
> thread.  Which does nothing.  Now our thread goes into TASK_INTERRUPTIBLE
> and calls schedule().  Sure, as soon as it gets woken up it'll call
> kthread_should_stop(), get true from it and that's it.  What's going
> to wake it up, though?
>
> The same goes for e.g. fs/btrfs/disk-io.c:cleaner_kthread():
>                 if (kthread_should_stop())
>                         return 0;
>                 if (!again) {
>                         set_current_state(TASK_INTERRUPTIBLE);
>                         schedule();
>                         __set_current_state(TASK_RUNNING);
>                 }
> can't be right.  Similar fun exists in e.g. fs/jfs, etc.
>
> Am I missing something?

Those examples look as suspect to me as they do to you.

Eric