Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
MIME-Version: 1.0
References: <0000000000000c44b0060760bd00@google.com> <000000000000c92c0d06082091ee@google.com>
 <20231025032133.GA1247614@ZenIV>
In-Reply-To: <20231025032133.GA1247614@ZenIV>
From:   Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon, 30 Oct 2023 22:05:00 +0100
Message-ID: <CAHc6FU4Zd0szGBzZBx212K4MgjFJAEMwD1jbTraw0ihMG14Z2w@mail.gmail.com>
Subject: Re: [syzbot] [gfs2?] WARNING: suspicious RCU usage in gfs2_permission
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     syzbot <syzbot+3e5130844b0c0e2b4948@syzkaller.appspotmail.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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Al,

On Wed, Oct 25, 2023 at 5:29=E2=80=AFAM Al Viro <viro@zeniv.linux.org.uk> w=
rote:
> 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=3D10b21c33=
680000
> > start commit:   2dac75696c6d Add linux-next specific files for 20231018
> > git tree:       linux-next
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=3D12b21c33=
680000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=3D14b21c33680=
000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=3D6f8545e1ef7=
a2b66
> > dashboard link: https://syzkaller.appspot.com/bug?extid=3D3e5130844b0c0=
e2b4948
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=3D101c8d096=
80000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=3D11a07475680=
000
> >
> > 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#bise=
ction
>
> Complaints about rcu_dereference() outside of rcu_read_lock().
>
> We could replace that line with
>         if (mask & MAY_NOT_BLOCK)
>                 gl =3D rcu_dereference(ip->i_gl);
>         else
>                 gl =3D ip->i_gl;
> or by any equivalent way to tell lockdep it ought to STFU.

the following should do then, right?

    gl =3D rcu_dereference_check(ip->i_gl, !(mask & MAY_NOT_BLOCK));

> BTW, the amount of rcu_dereference_protected(..., true) is somewhat depre=
ssing...
>
> Probably need to turn
>                 ip->i_gl =3D 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, ri=
ght?

> 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 lockde=
p
> false positives)...

I don't understand. What would lockdep complain about here?

Thanks,
Andreas