Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

[David Hildenbrand]

On 06.04.23 16:04, Peter Zijlstra wrote:
> On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote:
> >
> > > > To actually hit this path you're doing something really dodgy.
> > >
> > > Apparently khugepaged is using the same infrastructure:
> > >
> > > $ grep tlb_remove_table khugepaged.c
> > > 	tlb_remove_table_sync_one();
> > > 	tlb_remove_table_sync_one();
> > >
> > > So just enabling khugepaged will hit that path.
> >
> > Urgh, WTF..
> >
> > Let me go read that stuff :/
>
> At the very least the one on collapse_and_free_pmd() could easily become
> a call_rcu() based free.
>
> I'm not sure I'm following what collapse_huge_page() does just yet.

It wants to replace a leaf page table by a THP (Transparent Huge Page 
mapped by a PMD). So we want to rip out a leaf page table while other 
code (GUP-fast) might still be walking it. In contrast to freeing the 
page table, we put it into a list where it can be reuse when having to 
PTE-map a THP again.

Now, similar to after freeing the page table, someone else could reuse 
that page table and modify it.

If we have GUP-fast walking the page table while that is happening, 
we're in trouble. So we have to make sure GUP-fast is done before 
enqueuing the now-free page table.

That's why the tlb_remove_table_sync_one() was recently added (by Jann 
IIRC).

--
Thanks,

David / dhildenb