Re: synchronize_rcu in munmap?

[Matthew Wilcox <willy@infradead.org>]

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.