From: Peter Xu <[email protected]>
To: Nadav Amit <[email protected]>
Cc: [email protected], Nadav Amit <[email protected]>,
Jens Axboe <[email protected]>,
Andrea Arcangeli <[email protected]>,
Alexander Viro <[email protected]>,
[email protected], [email protected],
[email protected]
Subject: Re: [RFC PATCH 03/13] selftests/vm/userfaultfd: wake after copy failure
Date: Mon, 21 Dec 2020 14:28:46 -0500 [thread overview]
Message-ID: <20201221192846.GH6640@xz-x1> (raw)
In-Reply-To: <[email protected]>
On Sat, Nov 28, 2020 at 04:45:38PM -0800, Nadav Amit wrote:
> From: Nadav Amit <[email protected]>
>
> When userfaultfd copy-ioctl fails since the PTE already exists, an
> -EEXIST error is returned and the faulting thread is not woken. The
> current userfaultfd test does not wake the faulting thread in such case.
> The assumption is presumably that another thread set the PTE through
> copy/wp ioctl and would wake the faulting thread or that alternatively
> the fault handler would realize there is no need to "must_wait" and
> continue. This is not necessarily true.
>
> There is an assumption that the "must_wait" tests in handle_userfault()
> are sufficient to provide definitive answer whether the offending PTE is
> populated or not. However, userfaultfd_must_wait() test is lockless.
> Consequently, concurrent calls to ptep_modify_prot_start(), for
> instance, can clear the PTE and can cause userfaultfd_must_wait()
> to wrongly assume it is not populated and a wait is needed.
Yes userfaultfd_must_wait() is lockless, however my understanding is that we'll
enqueue before reading the page table, which seems to me that we'll always get
notified even the race happens. Should apply to either UFFDIO_WRITEPROTECT or
UFFDIO_COPY, iiuc, as long as we follow the order of (1) modify pgtable (2)
wake sleeping threads. Then it also means that when must_wait() returned true,
it should always get waked up when fault resolved.
Taking UFFDIO_COPY as example, even if UFFDIO_COPY happen right before
must_wait() calls:
worker thread uffd thread
------------- -----------
handle_userfault
spin_lock(fault_pending_wqh)
enqueue()
set_current_state(INTERRUPTIBLE)
spin_unlock(fault_pending_wqh)
must_wait()
lockless walk page table
UFFDIO_COPY
fill in the hole
wake up threads
(this will wake up worker thread too?)
schedule()
(which may return immediately?)
While here fault_pending_wqh is lock protected. I just feel like there's some
other reason to cause the thread to stall. Or did I miss something?
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2020-12-21 19:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-29 0:45 [RFC PATCH 00/13] fs/userfaultfd: support iouring and polling Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 01/13] fs/userfaultfd: fix wrong error code on WP & !VM_MAYWRITE Nadav Amit
2020-12-01 21:22 ` Mike Kravetz
2020-12-21 19:01 ` Peter Xu
2020-11-29 0:45 ` [RFC PATCH 02/13] fs/userfaultfd: fix wrong file usage with iouring Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 03/13] selftests/vm/userfaultfd: wake after copy failure Nadav Amit
2020-12-21 19:28 ` Peter Xu [this message]
2020-12-21 19:51 ` Nadav Amit
2020-12-21 20:52 ` Peter Xu
2020-12-21 20:54 ` Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 04/13] fs/userfaultfd: simplify locks in userfaultfd_ctx_read Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 05/13] fs/userfaultfd: introduce UFFD_FEATURE_POLL Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 06/13] iov_iter: support atomic copy_page_from_iter_iovec() Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 07/13] fs/userfaultfd: support read_iter to use io_uring Nadav Amit
2020-11-30 18:20 ` Jens Axboe
2020-11-30 19:23 ` Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 08/13] fs/userfaultfd: complete reads asynchronously Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 09/13] fs/userfaultfd: use iov_iter for copy/zero Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 10/13] fs/userfaultfd: add write_iter() interface Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 11/13] fs/userfaultfd: complete write asynchronously Nadav Amit
2020-12-02 7:12 ` Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 12/13] fs/userfaultfd: kmem-cache for wait-queue objects Nadav Amit
2020-11-30 19:51 ` Nadav Amit
2020-11-29 0:45 ` [RFC PATCH 13/13] selftests/vm/userfaultfd: iouring and polling tests Nadav Amit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201221192846.GH6640@xz-x1 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox