From: Schspa Shi <schspa@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Ingo Molnar <mingo@kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-kernel@vger.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: Tue, 14 Feb 2023 10:31:58 +0800 [thread overview]
Message-ID: <m21qmkahoj.fsf@gmail.com> (raw)
In-Reply-To: <Y+pWzult7UDgoilC@hirez.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> writes:
> On Mon, Feb 06, 2023 at 07:51:16AM -0800, Luis Chamberlain wrote:
>
>> I think this seems to be the same issue that Schspa Shi reported / provided a
>> fix sugggestion for [0]. This lead me to ask if:
>>
>> a) incorrect usage of completion on stack could be generic and;
>> b) if we should instead have an API helper for that?
>>
>> Although he already implemented a suggestion for b) to answer a) we need
>> some SmPL constructs yet to be written by Schspa. The reason I asked for
>> b) is that if this is a regular pattern it begs for a) as this sort of
>> issue could be prevalent in other places. So the status of Schspa's work
>> was that he was going to work on the SmPL grammar to check how frequent
>> this incorrect patern could be found.
>
> Do I read correctly, from you above alphabet-soup, that someone is
> working on some static analysis for on-stack completions or something?
>
Yes, I was trying to do this.
> If so, perhaps the simplest rule would to be ensure there is an
> unconditional uninterruptible wait-for-completion() before going out of
> scope.
>
> This latter can be spelled like wait_for_completion() or
> wait_for_completion_state(TASK_UNINTERRUPTIBLE). More specifically,
> TASK_INTERRUPTIBLE and TASK_WAKEKILL must not be set in the state mask
> for the wait to be uninterruptible.
>
> If it cannot be proven, raise a warning and audit or somesuch.
This is a good suggestion. I have written a SmPL patch to complete this
check, and now I need to rule out the situation that the driver has
added an additional lock to protect it.
And I have found a lot of bad usage, should we consider adding a new
helper API to simplify the fix this?
Such as:
+
+void complete_on_stack(struct completion **x)
+{
+ struct completion *comp = xchg(*x, NULL);
+
+ if (comp)
+ complete(comp);
+}
+EXPORT_SYMBOL(complete_on_stack);
+
+int __sched wait_for_completion_state_on_stack(struct completion **x,
+ unsigned int state)
+{
+ struct completion *comp = *x;
+ int retval;
+
+ retval = wait_for_completion_state(comp, state);
+ if (retval) {
+ if (xchg(*x, NULL))
+ return retval;
+
+ /*
+ * complete_on_stack will call complete shortly.
+ */
+ wait_for_completion(comp);
+ }
+
+ return retval;
+}
+EXPORT_SYMBOL(wait_for_completion_state_on_stack);
Link: https://lore.kernel.org/all/20221115140233.21981-1-schspa@gmail.com/T/#mf6a41a7009bb47af1b15adf2b7b355e495f609c4
--
BRs
Schspa Shi
next prev parent reply other threads:[~2023-02-20 8:02 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 [this message]
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
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=m21qmkahoj.fsf@gmail.com \
--to=schspa@gmail.com \
--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=peterz@infradead.org \
--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.