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

[Peter Zijlstra]

On Thu, Apr 06, 2023 at 04:42:02PM +0200, David Hildenbrand wrote:
> 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. 

Right, I got that far.

> 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.

Yeah, this is the bit I couldn't find, that code is a bit of a maze.

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

So ideally we'll RCU free the page instead of sticking it on that list.