linux-kernel - Re: [PATCH 06/10] exit: Implement kthread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 9 Jan 2022 03:27:26 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexey Gladkov <legion@...nel.org>,
        Kyle Huey <me@...ehuey.com>, Oleg Nesterov <oleg@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCH 06/10] exit: Implement kthread_exit

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?