Re: [syzbot] [mm?] KCSAN: data-race in mprotect_fixup / try_to_migrate_one

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Wed, Feb 05, 2025 at 04:46:40PM +0100, Marco Elver wrote:
> On Wed, 5 Feb 2025 at 16:11, 'Lorenzo Stoakes' via syzkaller-bugs
> <syzkaller-bugs@googlegroups.com> wrote:
> >
> > On Wed, Feb 05, 2025 at 04:00:06PM +0100, Jann Horn wrote:
> > > On Wed, Feb 5, 2025 at 12:41 PM syzbot
> > > <syzbot+c2e5712cbb14c95d4847@syzkaller.appspotmail.com> wrote:
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:    d009de7d5428 Merge tag 'livepatching-for-6.14-rc2' of git:..
> > > > git tree:       upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=12b678a4580000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=9e757e3762bd630b
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=c2e5712cbb14c95d4847
> > > > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > > >
> > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > >
> > > > Downloadable assets:
> > > > disk image: https://storage.googleapis.com/syzbot-assets/9235000a1b88/disk-d009de7d.raw.xz
> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/098ef82f8ab3/vmlinux-d009de7d.xz
> > > > kernel image: https://storage.googleapis.com/syzbot-assets/4f51f5eb5782/bzImage-d009de7d.xz
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+c2e5712cbb14c95d4847@syzkaller.appspotmail.com
> > > >
> > > > ==================================================================
> > > > BUG: KCSAN: data-race in mprotect_fixup / try_to_migrate_one
> [...]
> > I hate that we have these landmines waiting for us. Be good to find a way
> > to explicitly annotate this, or at least comment somehow.
> >
> > But agreed, probably adding a READ_ONCE()/WRITE_ONCE() is appropriate at
> > least for the proximate thing.
> >
> > It's a wonder these things don't trigger more, except you need probably
> > very precise timing to do it...
>
> They do trigger, but we don't send all of them to LKML.
> When we first introduced KCSAN, the notion of "data race" was still
> poorly understood. At the time we decided to pre-review a number of
> them (but our time to do so has been going down :-/), or let willing
> maintainers deal with them directly. A number of articles followed,

We very much appreciate your efforts :)

We are definitely willing to see these in mm, and as you can see from the
discussion here, the interaction between the rmap locks and other locks is
complicated (see also the docs I wrote on them at [0]).

So it'd be really good to pick up on these kinds of races. Obviously if there
are spurious reports, better to filter those out, and again, your efforts at
doing so and enabling this are hugely appreicated!

[0]:https://origin.kernel.org/doc/html/latest/mm/process_addrs.html

> such as:
>  - https://lwn.net/Articles/816850/
>  - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/access-marking.txt
>

Thanks :)

> And I think much of the community has indeed been "Calibrating your
> fear of big bad optimizing compilers"
> [https://lwn.net/Articles/799218/]. :-)

I personally appreciate all the help I can get in calbirating said fear :P

>
> If you want to see more reports (you can try to search for ones
> relevant to you):
> https://syzkaller.appspot.com/upstream?manager=ci2-upstream-kcsan-gce
> (see "moderation")

Thanks!