On Tue, Jan 17, 2023 at 6:44 PM Matthew Wilcox [off-list ref] wrote:

On Tue, Jan 17, 2023 at 05:06:57PM -0800, Suren Baghdasaryan wrote:

quoted

On Tue, Jan 17, 2023 at 7:47 AM Michal Hocko [off-list ref] wrote:

quoted

On Mon 09-01-23 12:53:23, Suren Baghdasaryan wrote:

quoted

Introduce lock_vma_under_rcu function to lookup and lock a VMA during
page fault handling. When VMA is not found, can't be locked or changes
after being locked, the function returns NULL. The lookup is performed
under RCU protection to prevent the found VMA from being destroyed before
the VMA lock is acquired. VMA lock statistics are updated according to
the results.
For now only anonymous VMAs can be searched this way. In other cases the
function returns NULL.

Could you describe why only anonymous vmas are handled at this stage and
what (roughly) has to be done to support other vmas? lock_vma_under_rcu
doesn't seem to have any anonymous vma specific requirements AFAICS.

TBH I haven't spent too much time looking into file-backed page faults
yet but a couple of tasks I can think of are:
- Ensure that all vma->vm_ops->fault() handlers do not rely on
mmap_lock being read-locked;

I think this way lies madness.  There are just too many device drivers
that implement ->fault.  My plan is to call the ->map_pages() method
under RCU without even read-locking the VMA.  If that doesn't satisfy
the fault, then drop all the way back to taking the mmap_sem for read
before calling into ->fault.

Sounds reasonable to me but I guess the devil is in the details...