[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6f327776-e22b-410e-a2ed-1b90c7ec76e5@lucifer.local>
Date: Mon, 23 Sep 2024 14:59:00 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Marco Elver <elver@...gle.com>
Cc: syzbot <syzbot+e01fa33e67abb0b3b3bb@...kaller.appspotmail.com>,
Liam.Howlett@...cle.com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
syzkaller-bugs@...glegroups.com, vbabka@...e.cz
Subject: Re: [syzbot] [mm?] KCSAN: data-race in mas_wr_store_entry /
mtree_range_walk
On Mon, Sep 23, 2024 at 01:57:55PM GMT, Marco Elver wrote:
> On Mon, 23 Sept 2024 at 11:44, 'Lorenzo Stoakes' via syzkaller-bugs
> <syzkaller-bugs@...glegroups.com> wrote:
> >
> > On Mon, Sep 23, 2024 at 02:04:23AM GMT, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: 88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1237ec27980000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=e6702f5f2b8ed242
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=e01fa33e67abb0b3b3bb
> > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > >
> >
> > Thanks for the report, investigating.
> >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > I suspect given this is so timing-specific, a reproducer might be difficult.
>
> FWIW, syzbot currently does not try to find reproducers for KCSAN,
> because it's too non-deterministic.
Thanks, yes makes sense.
>
> The best strategy would be for a developer who has an intuition for
> what might be going on to create a stress-test to reproduce.
As per analysis in thread, I don't think this is really an issue, as one of the
racing threads is code explicitly designed to accept and deal with races.
We do obviously probably need an annotation, but unless it becomes urgent,
will defer this until Liam's return to check and assess.
Obviously if we see more reports I can dive back in!
>
> > This suggests we are failing to acquire an RCU lock on mmap() (though we
> > have the write mmap lock).
> >
> > Maybe we missed an RCU lock at some point, but I'm a little baffled as to
> > what could have changed in recent series to adjust this.
> >
> > I will dig into this and see what's going on.
>
> Thanks!
Powered by blists - more mailing lists