archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <>
To: Andrew Morton <>,
Cc: Mike Rapoport <>,
	Mike Kravetz <>,
	Pavel Emelyanov <>
Subject: [PATCH 1/1] userfaultfd: non-cooperative: closing the uffd without triggering SIGBUS
Date: Wed, 23 Aug 2017 20:12:27 +0200	[thread overview]
Message-ID: <> (raw)

This is an enhancement to avoid a non cooperative userfaultfd manager
having to unregister all regions before it can close the uffd after
all userfaultfd activity completed.

The UFFDIO_UNREGISTER would serialize against the handle_userfault
by taking the mmap_sem for writing, but we can simply repeat the page
fault if we detect the uffd was closed and so the regular page fault
paths should takeover.

Acked-by: Mike Rapoport <>
Signed-off-by: Andrea Arcangeli <>
 fs/userfaultfd.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 272c21d8d532..186831c80a75 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -394,8 +394,26 @@ int handle_userfault(struct vm_fault *vmf, unsigned long reason)
 	 * in __get_user_pages if userfaultfd_release waits on the
 	 * caller of handle_userfault to release the mmap_sem.
-	if (unlikely(ACCESS_ONCE(ctx->released)))
+	if (unlikely(ACCESS_ONCE(ctx->released))) {
+		/*
+		 * Don't return VM_FAULT_SIGBUS in this case, so a non
+		 * cooperative manager can close the uffd after the
+		 * last UFFDIO_COPY, without risking to trigger an
+		 * involuntary SIGBUS if the process was starting the
+		 * userfaultfd while the userfaultfd was still armed
+		 * (but after the last UFFDIO_COPY). If the uffd
+		 * wasn't already closed when the userfault reached
+		 * this point, that would normally be solved by
+		 * userfaultfd_must_wait returning 'false'.
+		 *
+		 * If we were to return VM_FAULT_SIGBUS here, the non
+		 * cooperative manager would be instead forced to
+		 * always call UFFDIO_UNREGISTER before it can safely
+		 * close the uffd.
+		 */
 		goto out;
+	}
 	 * Check that we can return VM_FAULT_RETRY.

To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to  For more info on Linux MM,
see: .
Don't email: <a href=mailto:""> </a>

                 reply	other threads:[~2017-08-23 18:12 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).