Re: [PATCH v2] mm: implement and use vma_anon_tracked(), silence KCSAN

[Lorenzo Stoakes (ARM)]

On Thu, Sep 17, 2026 at 11:45:12AM +0200, David Hildenbrand (Arm) wrote:
> On 9/14/26 17:21, Lorenzo Stoakes (ARM) wrote:
> > On Thu, Sep 10, 2026 at 02:50:25PM +0100, Kiryl Shutsemau wrote:
> >> On Thu, Sep 10, 2026 at 02:18:35PM +0100, Lorenzo Stoakes (ARM) wrote:
> >>> Provide a function to abstract the common task of checking whether
> >>> a VMA is faulted in or not.
> >>>
> >>> A VMA or mmap lock must be held when calling this function. For an attached
> >>> VMA the transitions between unfaulted/faulted state are:
> >>>
> >>>        Transition        |              VMA/mmap Lock state
> >>>  ------------------------|-----------------------------------------------
> >>>    unfaulted to faulted  | write lock OR read lock + mm->page_table_lock
> >>>    faulted to unfaulted  | write lock
> >>>
> >>> So vma_anon_tracked() never provides a false positive (the lock precludes
> >>> it), but if only a read lock is held, a negative result must be re-checked
> >>> with mm->page_table_lock held.
> >>>
> >>> Detached VMAs cannot be concurrently manipulated as they are removed from
> >>> the maple tree so require no guarantees.
> >>>
> >>> Use data_race() to silence KCSAN about non-existent data races between
> >>> concurrent vma->anon_vma read/write on optimistic fault tests.
> >>>
> >>> Also while here, const-ify vma_is_attached(), vma_assert_stabilised() and
> >>> dependants.
> >>
> >> If you end up respinning anyway, this would be a natural separate
> >> prep patch.
> >
> > Yup will do, Pedro also asked for this!
> >
> >>
> >>> Finally, update the core VMA merge/split, rmap, mremap, KSM and fault
> >>> preparation callers which test vma->anon_vma directly to use
> >>> vma_anon_tracked() instead.
> >>>
> >>> Note that the lockless read in reusable_anon_vma() is doing more than
> >>> checking whether the VMA is faulted - it is returning the anon_vma to be
> >>> used on fault, so this check is not altered.
> >>>
> >>> There is one odd one out - file_backed_vma_is_retractable() - which holds
> >>> neither a VMA nor mmap lock and is stabilised by the file rmap lock only.
> >>>
> >>> Therefore just add a comment to explain why the direct vma->anon_vma check
> >>> is required.
> >>>
> >>> Reported-by: Guilherme Giacomo Simoes <trintaeoitogc@xxxxxxxxx>
> >>> Closes: https://lore.kernel.org/all/20260829100034.423064-1-trintaeoitogc@xxxxxxxxx/
> >>> Closes: https://lore.kernel.org/all/20260909115723.528501-1-trintaeoitogc@xxxxxxxxx/
> >>> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> >>> ---
> >>> v2:
> >>> - Renamed vma_is_faulted() to vma_anon_tracked() as per David.
> >>
> >> I don't particularly like vma_anon_tracked(), but naming is hard...
> >
> > Yeah it was a compromise because David and I disagreed on naming (again ;)
> >
> > I think vma_has_anon_rmap() is a better compromise?
>
> Yeah let's go for that.

Ack will do thanks!

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo