Re: synchronize_rcu in munmap?

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Feb 09, 2021 at 06:19:35PM +0100, Laurent Dufour wrote:
> Le 09/02/2021 à 15:29, Matthew Wilcox a écrit :
> > On Mon, Feb 08, 2021 at 01:26:43PM +0000, Matthew Wilcox wrote:
> > > Next problem: /proc/$pid/smaps calls walk_page_vma() which starts out by
> > > saying:
> > >          mmap_assert_locked(walk.mm);
> > > which made me realise that smaps is also going to walk the page tables.
> > > So the page tables have to be pinned by the existence of the VMA.
> > > Which means the page tables must be freed by the same RCU callback that
> > > frees the VMA.  But doing that means that a task which calls mmap();
> > > munmap(); mmap(); must avoid allocating the same address for the second
> > > mmap (until the RCU grace period has elapsed), otherwise threads on
> > > other CPUs may see the stale PTEs instead of the new ones.
> > > 
> > > Solution 1: Move the page table freeing into the RCU callback, call
> > > synchronize_rcu() in munmap().
> > > 
> > > Solution 2: Refcount the VMA and free the page tables on refcount
> > > dropping to zero.  This doesn't actually work because the stale PTE
> > > problem still exists.
> > > 
> > > Solution 3: When unmapping a VMA, instead of erasing the VMA from the
> > > maple tree, put a "dead" entry in its place.  Once the RCU freeing and the
> > > TLB shootdown has happened, erase the entry and it can then be allocated.
> > > If we do that MAP_FIXED will have to synchronize_rcu() if it overlaps
> > > a dead entry.
> > 
> > Solution 4: RCU free the page table pages and teach pagewalk.c to
> > be RCU-safe.  That means that it will have to use rcu_dereference()
> > or READ_ONCE to dereference (eg) pmdp, but also allows GUP-fast to run
> > under the rcu read lock instead of disabling interrupts.
> 
> I might be wrong but my understanding is that the RCU window could not be
> closed on a CPU where IRQs are disabled. So in a first step GUP-fast might
> continue to disable interrupts to get safe walking the page directories.

Yes, this is right. PPC already uses RCU for the TLB flush and the
GUP-fast trick is safe against that.

The comments for PPC say the downside of RCU is having to do an
allocation in paths that really don't want to fail on memory
exhaustion

The pagewalk.c needs to call its ops in a sleepable context, otherwise
it could just use the normal page table locks.. Not sure RCU could be
fit into here?

Jason