From: "Eric W. Biederman" <ebiederm@xmission.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, "Toke Høiland-Jørgensen" <toke@redhat.com>,
"Kalle Valo" <kvalo@kernel.org>,
"Johannes Berg" <johannes@sipsolutions.net>
Subject: Re: [PATCH v2] signal: break out of wait loops on kthread_stop()
Date: Mon, 27 Jun 2022 14:16:08 -0500 [thread overview]
Message-ID: <877d51udc7.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20220627145716.641185-1-Jason@zx2c4.com> (Jason A. Donenfeld's message of "Mon, 27 Jun 2022 16:57:16 +0200")
"Jason A. Donenfeld" <Jason@zx2c4.com> writes:
> I was recently surprised to learn that msleep_interruptible(),
> wait_for_completion_interruptible_timeout(), and related functions
> simply hung when I called kthread_stop() on kthreads using them. The
> solution to fixing the case with msleep_interruptible() was more simply
> to move to schedule_timeout_interruptible(). Why?
>
> The reason is that msleep_interruptible(), and many functions just like
> it, has a loop like this:
>
> while (timeout && !signal_pending(current))
> timeout = schedule_timeout_interruptible(timeout);
>
> The call to kthread_stop() woke up the thread, so schedule_timeout_
> interruptible() returned early, but because signal_pending() returned
> true, it went back into another timeout, which was never woken up.
>
> This wait loop pattern is common to various pieces of code, and I
> suspect that subtle misuse in a kthread that caused a deadlock in the
> code I looked at last week is also found elsewhere.
>
> So this commit causes signal_pending() to return true when
> kthread_stop() is called. This is already what's done for
> TIF_NOTIFY_SIGNAL, for these same purposes of breaking out of wait
> loops, so a similar KTHREAD_SHOULD_STOP check isn't too much
> different.
Semantically this makes a lot of sense.
Bloating up signal_pending which is mainly called in non-kthread
contexts is undesirable.
Instead could you modify kthread_stop to call set_notify_signal().
That is exactly what set_notify_signal is there for. When you don't
actually have a signal but you want to break out of an interruptible
loop. My last round of work in the area decoupled set_notify_signal
from any other semantics.
It would be nice to get everything down so that we only need to test
TIF_NOTIFY_SIGNAL in signal_pending. Unfortunately to do that I need
to do something with task_sigpending, and it hasn't been important
enough to weed through all of those details yet.
Eric
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Cc: Toke Høiland-Jørgensen <toke@redhat.com>
> Cc: Kalle Valo <kvalo@kernel.org>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> include/linux/kthread.h | 1 +
> include/linux/sched/signal.h | 9 +++++++++
> kernel/kthread.c | 8 ++++++++
> 3 files changed, 18 insertions(+)
>
> diff --git a/include/linux/kthread.h b/include/linux/kthread.h
> index 30e5bec81d2b..7061dde23237 100644
> --- a/include/linux/kthread.h
> +++ b/include/linux/kthread.h
> @@ -87,6 +87,7 @@ void kthread_bind(struct task_struct *k, unsigned int cpu);
> void kthread_bind_mask(struct task_struct *k, const struct cpumask *mask);
> int kthread_stop(struct task_struct *k);
> bool kthread_should_stop(void);
> +bool __kthread_should_stop(struct task_struct *k);
> bool kthread_should_park(void);
> bool __kthread_should_park(struct task_struct *k);
> bool kthread_freezable_should_stop(bool *was_frozen);
> diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
> index cafbe03eed01..08700c65b806 100644
> --- a/include/linux/sched/signal.h
> +++ b/include/linux/sched/signal.h
> @@ -11,6 +11,7 @@
> #include <linux/refcount.h>
> #include <linux/posix-timers.h>
> #include <linux/mm_types.h>
> +#include <linux/kthread.h>
> #include <asm/ptrace.h>
>
> /*
> @@ -397,6 +398,14 @@ static inline int signal_pending(struct task_struct *p)
> */
> if (unlikely(test_tsk_thread_flag(p, TIF_NOTIFY_SIGNAL)))
> return 1;
> +
> + /*
> + * Likewise, KTHREAD_SHOULD_STOP isn't really a signal, but it also
> + * requires the same behavior, lest wait loops go forever.
> + */
> + if (unlikely(__kthread_should_stop(p)))
> + return 1;
> +
> return task_sigpending(p);
> }
>
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index 3c677918d8f2..80f6ba323060 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -145,6 +145,14 @@ void free_kthread_struct(struct task_struct *k)
> kfree(kthread);
> }
>
> +bool __kthread_should_stop(struct task_struct *k)
> +{
> + struct kthread *kthread = __to_kthread(k);
> +
> + return kthread && test_bit(KTHREAD_SHOULD_STOP, &kthread->flags);
> +}
> +EXPORT_SYMBOL_GPL(__kthread_should_stop);
> +
> /**
> * kthread_should_stop - should this kthread return now?
> *
next prev parent reply other threads:[~2022-06-27 19:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 12:00 [PATCH] signal: break out of wait loops on kthread_stop() Jason A. Donenfeld
2022-06-27 13:27 ` Peter Zijlstra
2022-06-27 14:54 ` Jason A. Donenfeld
2022-06-27 14:57 ` [PATCH v2] " Jason A. Donenfeld
2022-06-27 19:16 ` Eric W. Biederman [this message]
2022-06-28 15:59 ` Jason A. Donenfeld
2022-06-28 16:14 ` [PATCH v3] " Jason A. Donenfeld
2022-07-04 12:22 ` Jason A. Donenfeld
2022-07-11 17:53 ` Jason A. Donenfeld
2022-07-11 18:57 ` Eric W. Biederman
2022-07-11 20:18 ` Jason A. Donenfeld
2022-07-11 20:21 ` [PATCH v4] " Jason A. Donenfeld
2022-07-11 22:05 ` Eric W. Biederman
2022-07-11 23:21 ` [PATCH v5] " Jason A. Donenfeld
2022-07-12 0:00 ` Eric W. Biederman
2022-07-12 0:18 ` Jason A. Donenfeld
2022-07-11 22:04 ` [PATCH v3] " Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877d51udc7.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=Jason@zx2c4.com \
--cc=johannes@sipsolutions.net \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=toke@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.