[lkml]   [2020]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] userfaultfd: Address race after fault.
Hi Andrea,
Thanks for the quick reply. That's great to hear that Peter has been
working on those improvements. I didn't try the entire patchset but I
did confirm that patch 13, not surprisingly, also resolves that issue
on at least on x86:

Given that seems pretty low risk and it definitely resolves a pretty
big issue for the non-cooperative userfaultfd case, any chance it
could be landed ahead of the rest of the series?


On Fri, Feb 14, 2020 at 6:20 PM Andrea Arcangeli <> wrote:
> Hello,
> this and other enhancements have already implemented by Peter (CC'ed)
> and in the right way, by altering the retry logic in the page fault
> code. This is a requirement for other kind of usages too, notably the
> UFFD_WRITEPROTECT ioctl after which multiple consecutive faults can
> happen and must be handled.
> IIRC Kirill asked at last LSF-MM uffd-wp talk if there's any
> particular reason the fault couldn't be retried currently. I had no
> sure answer other than there's apparently no strong reason why
> VM_FAULT_RETRY is only allowed 1 time currently, so there should be no
> issue in lifting that artificial restriction.
> I'm running with this patchset applied in my systems since Nov with no
> regression at all. I got sidetracked by various other issues, so
> unfortunately I didn' post a proper reviewed-by on the last submit yet
> (pending), but I did at least test it and it was rock solid so far.
> Can you test and verify it too if it solves your use case?
> Also note the complete uffd-WP support submit also from Peter:
> Thanks,
> Andrea

 \ /
  Last update: 2020-02-15 15:30    [W:0.071 / U:4.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site