Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when expanding vma during mremap

[David Hildenbrand]

On 24.05.25 18:45, Oleg Nesterov wrote:
> I am very glad that mm experts are already looking into this problem ;)
> I can't help, today I don't understand mm/vma.c even remotely. But let
> me ask a couple of stupid questions.
>
> > However, the
> > upcomming move_page_tables step, which use set_pte_at to remap the vma2
> > uprobe anon page to the merged vma, will over map the old uprobe anon
> > page in the merged vma, and lead the old uprobe anon page to be orphan.
>
> To be honest, I can't even understand this part due to my ignorance.
> What does "the old uprobe anon page to be orphan" actually mean?
> How can the unnecessary uprobe_mmap() lead to an "unbalanced"
> inc_mm_counter(MM_ANONPAGES) ? Or what else can explain the
> "BUG: Bad rss-counter state" from check_mm() ? Or there are more problems?

Essentially, we end up mapping an anonymous page (when install the 
uprobe) after preparing the new VMA, but before moving over the pages 
from the old VMA.

So when we then move over the pages from the old VMA, we overwrite the 
PTE mapping an anonymous page (due to uprobe).

As we simply overwrite the PTE that is mapping an anonymous page, we run 
into inconsistency later: RSS counter mismatch, memory leak, etc.

We should never be installing an anonymous page (due to uprobe) into a 
VMA during mremap() before moving over the pages from the old VMA.

--
Cheers,

David / dhildenb