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

[Lance Yang <lance.yang@linux.dev>]

On Thu, Sep 17, 2026 at 08:47:42PM +0100, 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@gmail.com>
>Closes: https://lore.kernel.org/all/20260829100034.423064-1-trintaeoitogc@gmail.com/
>Closes: https://lore.kernel.org/all/20260909115723.528501-1-trintaeoitogc@gmail.com/
>Reviewed-by: Pedro Falcato <pfalcato@suse.de>
>Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
>Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
>---

Nothing jumped out at me,

Reviewed-by: Lance Yang <lance.yang@linux.dev>