Re: [PATCH mm-unstable v18 06/14] mm/khugepaged: generalize collapse_huge_page for mTHP collapse

On 2026/6/1 16:15, David Hildenbrand (Arm) wrote:

On 6/1/26 09:49, Lance Yang wrote:

quoted

On 2026/6/1 14:54, David Hildenbrand (Arm) wrote:

quoted

On 6/1/26 05:28, Lance Yang wrote:

quoted

Ah, fair point.

I was mostly worried about arch hooks that walk vma->vm_mm again, rather
than only using the pte pointer passed in. For example, mips does:

Right, a re-walk would be the real problem.

quoted

    update_mmu_cache_range()
      -> __update_tlb()
        -> pgd_offset(vma->vm_mm, address)
        -> pte_offset_map(...)

and __update_tlb() has this assumption:

         /*
          * update_mmu_cache() is called between pte_offset_map_lock()
          * and pte_unmap_unlock(), so we can assume that ptep is not
          * NULL here: and what should be done below if it were NULL?
          */

So if khugepaged happens to run with current->active_mm == vma->vm_mm
here, could __update_tlb() hit the none PMD, get NULL from
pte_offset_map(), and then dereference it?

Likely yes -- that MIPS code is horrible. And the comment in MIPS code
even spells that out. :(

Do you know about other code like that, or is MIPS the only one doing a
re-walk and crossing fingers?

I had Codex do the boring grep-work through the arch update_mmu_cache*
code :D

MIPS doesn't seem to be the only code doing a re-walk, but it is the
only one I found that appears to assume the PMD/PTE walk cannot fail,
without checking whether the PMD is none ...

Okay, but likely the other code that tries to handle it is also problematic.

Best to make sure the page table is already installed when updating the entries.

Neat, makes sense to me :D

That way the page talbe is back in place before any arch hook gets to look at it :)