From: Matthew Wilcox <willy@infradead.org>
To: David Mozes <david.mozes@silk.us>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Darren Hart <dvhart@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: futex/call -to plist_for_each_entry_safe with head=NULL
Date: Sun, 13 Jun 2021 21:04:18 +0100 [thread overview]
Message-ID: <YMZkwsa4yQ/SsMW/@casper.infradead.org> (raw)
In-Reply-To: <AM6PR04MB563958D1E2CA011493F4BCC8F1329@AM6PR04MB5639.eurprd04.prod.outlook.com>
On Sun, Jun 13, 2021 at 12:24:52PM +0000, David Mozes wrote:
> Hi *,
> Under a very high load of io traffic, we got the below BUG trace.
> We can see that:
> plist_for_each_entry_safe(this, next, &hb1->chain, list) {
> if (match_futex (&this->key, &key1))
>
> were called with hb1 = NULL at futex_wake_up function.
> And there is no protection on the code regarding such a scenario.
>
> The NULL can be geting from:
> hb1 = hash_futex(&key1);
>
> How can we protect against such a situation?
Can you reproduce it without loading proprietary modules?
Your analysis doesn't quite make sense:
hb1 = hash_futex(&key1);
hb2 = hash_futex(&key2);
retry_private:
double_lock_hb(hb1, hb2);
If hb1 were NULL, then the oops would come earlier, in double_lock_hb().
> RIP: 0010:do_futex+0xdf/0xa90
>
> 0xffffffff81138eff is in do_futex (kernel/futex.c:1748).
> 1743 put_futex_key(&key1);
> 1744 cond_resched();
> 1745 goto retry;
> 1746 }
> 1747
> 1748 plist_for_each_entry_safe(this, next, &hb1->chain, list) {
> 1749 if (match_futex (&this->key, &key1)) {
> 1750 if (this->pi_state || this->rt_waiter) {
> 1751 ret = -EINVAL;
> 1752 goto out_unlock;
> (gdb)
>
>
>
> plist_for_each_entry_safe(this, next, &hb1->chain, list) {
> if (match_futex (&this->key, &key1)) {
>
>
>
>
> This happened in kernel 4.19.149 running on Azure vm
>
>
> Thx
> David
> Reply
> Forward
> MO
>
next parent reply other threads:[~2021-06-13 20:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AM6PR04MB563958D1E2CA011493F4BCC8F1329@AM6PR04MB5639.eurprd04.prod.outlook.com>
2021-06-13 20:04 ` Matthew Wilcox [this message]
2021-06-14 11:12 ` futex/call -to plist_for_each_entry_safe with head=NULL David Mozes
2021-06-15 15:03 ` Thomas Gleixner
2021-06-16 15:42 ` David Mozes
2021-06-20 16:04 ` David Mozes
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=YMZkwsa4yQ/SsMW/@casper.infradead.org \
--to=willy@infradead.org \
--cc=david.mozes@silk.us \
--cc=dvhart@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).