Re: [PATCH v3 2/3] mm: implement and use vma_has_anon_rmap(), silence KCSAN

[David Hildenbrand (Arm)]

On 9/17/26 21:47, Lorenzo Stoakes (ARM) wrote:
> Provide a function to abstract the common task of checking whether
> a VMA has an anonymous reverse mapping associated with it.
> 
> If the VMA is attached, a VMA or mmap lock must be held when calling this
> function.
> 
> For an attached, anonymous, VMA:
> 
>           Transition          |              VMA/mmap Lock state
>  -----------------------------|-------------------------------------------
>    No anon rmap to anon rmap  | Write lock/read lock + mm->page_table_lock
>    Anon rmap to no anon rmap  | Write lock
> 
> vma_has_anon_rmap() 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.
> 
> A VMA obtains an anonymous reverse mapping when first faulted or forked
> and it is removed when it is freed.
> 
> 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.
> 
> Update the core VMA merge/split, rmap, mremap, KSM, fork,
> khugepaged and fault preparation callers which test vma->anon_vma directly
> to use vma_has_anon_rmap() instead.
> 
> Finally, update comments that reference anon_vma to reference the anon rmap
> instead.
> 
> Since the lockless read in reusable_anon_vma() is doing more than checking
> whether the VMA has anon rmap - it is returning the anon_vma to be used on
> fault - do not alter it.
> 
> 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,
> so simply add a comment to explain why it's necessary.
> 
> 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/
> Reviewed-by: Pedro Falcato <pfalcato@xxxxxxx>
> Reviewed-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> ---

Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

-- 
Cheers,

David