Al, On Wed, Oct 25, 2023 at 5:29 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Oct 20, 2023 at 12:10:38AM -0700, syzbot wrote: > > syzbot has bisected this issue to: > > > > commit 0abd1557e21c617bd13fc18f7725fc6363c05913 > > Author: Al Viro <viro@xxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxxxxxx > > 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. the following should do then, right? gl = rcu_dereference_check(ip->i_gl, !(mask & MAY_NOT_BLOCK)); > 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); That's what commit 0abd1557e21c6 does already so there's nothing to fix, right? > 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)... I don't understand. What would lockdep complain about here? Thanks, Andreas