Re: [QUESTION] anon_vma lock in khugepaged

[Dev Jain]

On 28/11/24 11:56 am, Dev Jain wrote:
> Hi, I was looking at khugepaged code and I cannot figure out what will the problem be
> if we take the mmap lock in read mode. Shouldn't just taking the PMD lock, then PTL,
> then unlocking PTL, then unlocking PMD, solve any races with page table walkers?

Similar questions:

1. Why do we need anon_vma_lock_write() in collapse_huge_page()? AFAIK we need to walk anon_vma's either
   when we are forking or when we are unmapping a folio and need to find all VMAs mapping it; the former path takes the
   mmap_write_lock() and so we have no problem, and for the latter, if we just had anon_vma_lock_read(), then it
   may happen that kswapd isolates folio from LRU, and traverses rmap and swaps the folio out and khugepaged fails in
   folio_isolate_lru(), but then that is not a fatal problem but just a performance degradation due to a race (wherein
   the entire code is racy anyways). What am I missing?

2. In what all scenarios does rmap come into play? Fork, swapping out, any other I am missing?

3. Please confirm the correctness: In stark contrast to page migration, we do not need to do rmap walk and nuke all
   PTEs referencing the folio, because for anon non-shmem folios, the only way the folio can be shared is forking,
   and, if that is the case, folio_put() will not release the folio in __collapse_huge_page_copy_succeeded() -> free_page_and_swap_cache(),
   so the old folio is still there and child processes can read from it. Page migration requires that we are able
   to deallocate the old folios.