diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2020-08-02 19:42:31 +0200 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2020-08-03 20:25:16 +0200 |
commit | f9bf352224d7d4612b55b8d0cd0eaa981a3246cf (patch) | |
tree | 7a4399f3ced4d752182a5fdc8a7a0d6d271647b6 /drivers/md/dm-writecache.c | |
parent | Merge tag 'filelock-v5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/... (diff) | |
download | linux-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