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

[Jann Horn <jannh@google.com>]

On Wed, Feb 5, 2025 at 4:47 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> * Jann Horn <jannh@google.com> [250205 10:00]:
> > The comments in the VMA flags code incorrectly assume that no
> > concurrency is possible here; and I think the comment in
> > mprotect_fixup() about protection by the mmap_lock has also been kinda
> > wrong since the beginning of git history.
> >
> > The VM_LOCKED check in the migration code was added by Hugh in commit
> > b74355078b655, but that's just one example syzbot stumbled over; we
> > have similar racy vm_flags reads through the rmap on other paths like:
> >
> > unmap_mapping_range_tree -> unmap_mapping_range_vma ->
> > zap_page_range_single -> unmap_single_vma -> unmap_page_range -> ...
> > -> zap_pte_range -> zap_present_ptes -> vm_normal_page
>
> I think we need a list of vm_area_struct parts that are OK to access
> without the read/write/vma lock.  It seems flags is not one of those as
> it could be racy.

We do have this big table in these nice docs that Lorenzo spent quite
some effort on:
https://kernel.org/doc/html/latest/mm/process_addrs.html#vma-fields

Though that does not currently call out this possible concurrency of vm_flags.