All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Ingo Molnar <mingo@kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	linux-kernel@vger.kernel.org, mcgrof@kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	syzkaller-bugs@googlegroups.com,
	syzbot <syzbot+6cd18e123583550cf469@syzkaller.appspotmail.com>,
	Hillf Danton <hdanton@sina.com>
Subject: Re: [syzbot] WARNING: locking bug in umh_complete
Date: Mon, 13 Feb 2023 16:34:33 +0100	[thread overview]
Message-ID: <Y+pYiUfKp32hbIEI@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <caa13441-5f95-b7d6-dd5d-1cf49e709714@I-love.SAKURA.ne.jp>

On Sat, Feb 04, 2023 at 09:48:39AM +0900, Tetsuo Handa wrote:
> Please fold below diff,

Find final version below -- typing hard I suppose..

> provided that wait_for_completion_state(TASK_FREEZABLE)
> does not return when the current thread was frozen. (If
> wait_for_completion_state(TASK_FREEZABLE) returns when the current thread was
> frozen, we will fail to execute the

FREEZABLE should be transparent; that is it will only return when an
actual wakeup was missed, otherwise it will remain asleep.

Specifically, the FROZEN thing relies on wait loops to be resillient
against spurious wakeups. Consider do_wait_for_common(), the action() :=
schedule_timeout() might 'suriously' return after thawing, but it will
re-validate the actual completion condition and go back to sleep if it
hasn't happened yet.

OTOH, if the completeion condition has happened (right before the
completer itself was frozen for example, but after the waiter was
already frozen), then the 'spurious' wakeup on thaw is exactly what was
needed, the completion condition is satisfied and the wait terminated.

---
Subject: freezer,umh: Fix call_usermode_helper_exec() vs SIGKILL
From: Peter Zijlstra <peterz@infradead.org>
Date: Fri, 3 Feb 2023 15:31:11 +0100

Tetsuo-San noted that commit f5d39b020809 ("freezer,sched: Rewrite
core freezer logic") broke call_usermodehelper_exec() for the KILLABLE
case.

Specifically it was missed that the second, unconditional,
wait_for_completion() was not optional and ensures the on-stack
completion is unused before going out-of-scope.

Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
Reported-by: syzbot+6cd18e123583550cf469@syzkaller.appspotmail.com
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Debugged-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/Y90ar35uKQoUrLEK@hirez.programming.kicks-ass.net
---
 kernel/umh.c |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -438,21 +438,27 @@ int call_usermodehelper_exec(struct subp
 	if (wait == UMH_NO_WAIT)	/* task has freed sub_info */
 		goto unlock;
 
-	if (wait & UMH_KILLABLE)
-		state |= TASK_KILLABLE;
-
 	if (wait & UMH_FREEZABLE)
 		state |= TASK_FREEZABLE;
 
-	retval = wait_for_completion_state(&done, state);
-	if (!retval)
-		goto wait_done;
-
 	if (wait & UMH_KILLABLE) {
+		retval = wait_for_completion_state(&done, state | TASK_KILLABLE);
+		if (!retval)
+			goto wait_done;
+
 		/* umh_complete() will see NULL and free sub_info */
 		if (xchg(&sub_info->complete, NULL))
 			goto unlock;
+
+		/*
+		 * fallthrough; in case of -ERESTARTSYS now do uninterruptible
+		 * wait_for_completion_state(). Since umh_complete() shall call
+		 * complete() in a moment if xchg() above returned NULL, this
+		 * uninterruptible wait_for_completion_state() will not block
+		 * SIGKILL'ed processes for long.
+		 */
 	}
+	wait_for_completion_state(&done, state);
 
 wait_done:
 	retval = sub_info->retval;

  parent reply	other threads:[~2023-02-13 15:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230127014137.4906-1-hdanton@sina.com>
2023-02-03 10:22 ` [syzbot] WARNING: locking bug in umh_complete Tetsuo Handa
2023-02-03 10:48   ` Tetsuo Handa
2023-02-03 12:19     ` Peter Zijlstra
2023-02-03 12:30       ` Peter Zijlstra
2023-02-03 12:59         ` Tetsuo Handa
2023-02-03 14:31           ` Peter Zijlstra
2023-02-04  0:48             ` Tetsuo Handa
2023-02-06 15:51               ` Luis Chamberlain
2023-02-13 15:14                 ` Peter Zijlstra
2023-02-13 15:27                 ` Peter Zijlstra
2023-02-14  2:31                   ` Schspa Shi
2023-02-21 21:54                     ` Luis Chamberlain
2023-02-22  9:34                     ` Peter Zijlstra
2023-02-27  7:57                       ` Schspa Shi
2023-02-13 15:34               ` Peter Zijlstra [this message]
2023-02-14 11:16                 ` Tetsuo Handa
2023-02-15 10:33             ` [tip: sched/urgent] freezer,umh: Fix call_usermode_helper_exec() vs SIGKILL tip-bot2 for Peter Zijlstra
2023-02-03 12:00   ` [syzbot] WARNING: locking bug in umh_complete Peter Zijlstra
2023-01-26 22:27 syzbot

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=Y+pYiUfKp32hbIEI@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=hdanton@sina.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mingo@kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=rafael.j.wysocki@intel.com \
    --cc=syzbot+6cd18e123583550cf469@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    /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.