lkml.org 
[lkml]   [2022]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 06/10] exit: Implement kthread_exit
    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

    \
     
     \ /
      Last update: 2022-01-10 16:06    [W:4.473 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site