Re: synchronize_rcu in munmap?

[Laurent Dufour <ldufour@linux.ibm.com>]

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.