From: Al Viro <viro@zeniv.linux.org.uk>
To: syzbot <syzbot+3e5130844b0c0e2b4948@syzkaller.appspotmail.com>
Cc: gfs2@lists.linux.dev, syzkaller-bugs@googlegroups.com,
linux-kernel@vger.kernel.org, cluster-devel@redhat.com,
linux-fsdevel@vger.kernel.org, postmaster@duagon.onmicrosoft.com
Subject: Re: [Cluster-devel] [syzbot] [gfs2?] WARNING: suspicious RCU usage in gfs2_permission
Date: Wed, 25 Oct 2023 04:21:33 +0100 [thread overview]
Message-ID: <20231025032133.GA1247614@ZenIV> (raw)
In-Reply-To: <000000000000c92c0d06082091ee@google.com>
On Fri, Oct 20, 2023 at 12:10:38AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 0abd1557e21c617bd13fc18f7725fc6363c05913
> Author: Al Viro <viro@zeniv.linux.org.uk>
> Date: Mon Oct 2 02:33:44 2023 +0000
>
> gfs2: fix an oops in gfs2_permission
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10b21c33680000
> start commit: 2dac75696c6d Add linux-next specific files for 20231018
> git tree: linux-next
> final oops: https://syzkaller.appspot.com/x/report.txt?x=12b21c33680000
> console output: https://syzkaller.appspot.com/x/log.txt?x=14b21c33680000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6f8545e1ef7a2b66
> dashboard link: https://syzkaller.appspot.com/bug?extid=3e5130844b0c0e2b4948
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101c8d09680000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11a07475680000
>
> Reported-by: syzbot+3e5130844b0c0e2b4948@syzkaller.appspotmail.com
> Fixes: 0abd1557e21c ("gfs2: fix an oops in gfs2_permission")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Complaints about rcu_dereference() outside of rcu_read_lock().
We could replace that line with
if (mask & MAY_NOT_BLOCK)
gl = rcu_dereference(ip->i_gl);
else
gl = ip->i_gl;
or by any equivalent way to tell lockdep it ought to STFU.
BTW, the amount of rcu_dereference_protected(..., true) is somewhat depressing...
Probably need to turn
ip->i_gl = NULL;
in the end of gfs2_evict_inode() into rcu_assign_pointer(ip->i_gl, NULL);
and transpose it with the previous line -
gfs2_glock_put_eventually(ip->i_gl);
I don't think it really matters in this case, though - destruction of the object
it used to point to is delayed in all cases. Matter of taste (and lockdep
false positives)...
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: syzbot <syzbot+3e5130844b0c0e2b4948@syzkaller.appspotmail.com>
Cc: agruenba@redhat.com, cluster-devel@redhat.com,
gfs2@lists.linux.dev, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, postmaster@duagon.onmicrosoft.com,
rpeterso@redhat.com, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [gfs2?] WARNING: suspicious RCU usage in gfs2_permission
Date: Wed, 25 Oct 2023 04:21:33 +0100 [thread overview]
Message-ID: <20231025032133.GA1247614@ZenIV> (raw)
In-Reply-To: <000000000000c92c0d06082091ee@google.com>
On Fri, Oct 20, 2023 at 12:10:38AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 0abd1557e21c617bd13fc18f7725fc6363c05913
> Author: Al Viro <viro@zeniv.linux.org.uk>
> Date: Mon Oct 2 02:33:44 2023 +0000
>
> gfs2: fix an oops in gfs2_permission
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10b21c33680000
> start commit: 2dac75696c6d Add linux-next specific files for 20231018
> git tree: linux-next
> final oops: https://syzkaller.appspot.com/x/report.txt?x=12b21c33680000
> console output: https://syzkaller.appspot.com/x/log.txt?x=14b21c33680000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6f8545e1ef7a2b66
> dashboard link: https://syzkaller.appspot.com/bug?extid=3e5130844b0c0e2b4948
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101c8d09680000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11a07475680000
>
> Reported-by: syzbot+3e5130844b0c0e2b4948@syzkaller.appspotmail.com
> Fixes: 0abd1557e21c ("gfs2: fix an oops in gfs2_permission")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Complaints about rcu_dereference() outside of rcu_read_lock().
We could replace that line with
if (mask & MAY_NOT_BLOCK)
gl = rcu_dereference(ip->i_gl);
else
gl = ip->i_gl;
or by any equivalent way to tell lockdep it ought to STFU.
BTW, the amount of rcu_dereference_protected(..., true) is somewhat depressing...
Probably need to turn
ip->i_gl = NULL;
in the end of gfs2_evict_inode() into rcu_assign_pointer(ip->i_gl, NULL);
and transpose it with the previous line -
gfs2_glock_put_eventually(ip->i_gl);
I don't think it really matters in this case, though - destruction of the object
it used to point to is delayed in all cases. Matter of taste (and lockdep
false positives)...
next prev parent reply other threads:[~2023-10-25 3:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 18:18 [syzbot] [gfs2?] WARNING: suspicious RCU usage in gfs2_permission syzbot
2023-10-18 14:28 ` syzbot
2023-10-20 7:10 ` syzbot
2023-10-25 3:21 ` Al Viro [this message]
2023-10-25 3:21 ` Al Viro
2023-10-30 21:05 ` [Cluster-devel] " Andreas Gruenbacher
2023-10-30 21:05 ` Andreas Gruenbacher
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=20231025032133.GA1247614@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=cluster-devel@redhat.com \
--cc=gfs2@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=postmaster@duagon.onmicrosoft.com \
--cc=syzbot+3e5130844b0c0e2b4948@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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.