Re: synchronize_rcu in munmap?

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Feb 08, 2021 at 01:26:43PM +0000, Matthew Wilcox wrote:
> TLDR: I think we're going to need to call synchronize_rcu() in munmap(),
> and I know this can be quite expensive.  Is this a reasonable price to
> pay for avoiding taking the mmap_sem for page faults?

In my experience we have been ripping out synchronize_rcu() in places
that intersect with userspace, it can be very slow and if something
does more than one iteration things get bad.

Based on that mmunmap seems like a poor place to put synchronize_rcu()

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

Aren't the presense/absence of the page table levels themselves
managed under the page table locks? I thought that unused levels were
wiped in some lazy fasion after the TLB flush based on being empty? 

There is a state graph of allowed page entry transitions under the
read side of the mmap sem, and allocated -> freed table is not
allowed (freed -> allocated is OK though, IIRC).

I think this has nothing to do with the mmap_sem acting as a VMA lock,
it feels like some extra behavior.

Jason