summaryrefslogtreecommitdiffstats
path: root/drivers/md/dm-writecache.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2020-08-02 19:42:31 +0200
committerLinus Torvalds <torvalds@linux-foundation.org>2020-08-03 20:25:16 +0200
commitf9bf352224d7d4612b55b8d0cd0eaa981a3246cf (patch)
tree7a4399f3ced4d752182a5fdc8a7a0d6d271647b6 /drivers/md/dm-writecache.c
parentMerge tag 'filelock-v5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/... (diff)
downloadlinux-f9bf352224d7d4612b55b8d0cd0eaa981a3246cf.tar.xz
linux-f9bf352224d7d4612b55b8d0cd0eaa981a3246cf.zip
userfaultfd: simplify fault handling
Instead of waiting in a loop for the userfaultfd condition to become true, just wait once and return VM_FAULT_RETRY. We've already dropped the mmap lock, we know we can't really successfully handle the fault at this point and the caller will have to retry anyway. So there's no point in making the wait any more complicated than it needs to be - just schedule away. And once you don't have that complexity with explicit looping, you can also just lose all the 'userfaultfd_signal_pending()' complexity, because once we've set the correct process sleeping state, and don't loop, the act of scheduling itself will be checking if there are any pending signals before going to sleep. We can also drop the VM_FAULT_MAJOR games, since we'll be treating all retried faults as major soon anyway (series to regularize and share more of fault handling across architectures in a separate series by Peter Xu, and in the meantime we won't worry about the possible minor - I'll be here all week, try the veal - accounting difference). Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Peter Xu <peterx@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/md/dm-writecache.c')
0 files changed, 0 insertions, 0 deletions