From: Peter Xu <peterx@redhat.com>
To: James Houghton <jthoughton@google.com>
Cc: "David P. Reed" <dpreed@deepplum.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Axel Rasmussen <axelrasmussen@google.com>
Subject: Re: PROBLEM: userfaultfd REGISTER minor mode on MAP_PRIVATE range fails
Date: Tue, 16 Sep 2025 10:48:08 -0400 [thread overview]
Message-ID: <aMl4qLyNovWHhty9@x1.local> (raw)
In-Reply-To: <CADrL8HX78-oh0k2qAgqPvNVAhi4ESYvjRsScPGR2P2Dts13Bfw@mail.gmail.com>
On Mon, Sep 15, 2025 at 05:31:51PM -0700, James Houghton wrote:
> I still don't have a solid grasp of what your use case is.
David, are you trying to provide a synchronous trap for an anon swapin
event? Say, you want to be able to stop a thread from swapping in anything
from disk (or swap cache), do something, and UFFDIO_CONTINUE to kick it off
again?
That might make some sense when trying to match what MINOR mode means
v.s. the mm's minor faults, but some explanation of why you wanted to do
that would be helpful. I agree with James that it was at least not the
intention when userfaultfd MINOR trap was introduced.
The other thing to mention is, AFAIU userfaultfd's major use case is not
through a fork(), even though it should work.. In many cases, userfaultfd
is used within a process, with a dedicated thread resolving faults. When
it's used across processes, fork() should work but UFFD_FEATURE_EVENT_FORK
is required, or otherwise via SCM_RIGHTS. For the latter, the tracee needs
to not only share the uffd object, but tell the tracer explicitly about the
memory layout, because those addresses in the events will be reported in
tracee's mm address space.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2025-09-16 14:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 20:13 David P. Reed
2025-09-15 20:24 ` James Houghton
2025-09-15 22:58 ` David P. Reed
2025-09-16 0:31 ` James Houghton
2025-09-16 14:48 ` Peter Xu [this message]
2025-09-16 15:52 ` David P. Reed
2025-09-16 16:13 ` Peter Xu
2025-09-16 17:09 ` David P. Reed
2025-09-26 22:16 ` Peter Xu
2025-09-16 17:27 ` David P. Reed
2025-09-16 18:35 ` Axel Rasmussen
2025-09-16 19:10 ` James Houghton
2025-09-16 19:47 ` David P. Reed
2025-09-16 22:04 ` Axel Rasmussen
2025-09-26 22:00 ` Peter Xu
2025-09-16 19:52 ` David P. Reed
2025-09-17 16:13 ` Axel Rasmussen
2025-09-19 18:29 ` David P. Reed
2025-09-25 19:20 ` Axel Rasmussen
2025-09-27 18:45 ` David P. Reed
2025-09-29 5:30 ` James Houghton
2025-09-29 19:44 ` David P. Reed
2025-09-29 20:30 ` Peter Xu
2025-10-01 22:16 ` Axel Rasmussen
2025-10-17 21:07 ` David P. Reed
2025-09-16 15:37 ` David P. Reed
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=aMl4qLyNovWHhty9@x1.local \
--to=peterx@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=dpreed@deepplum.com \
--cc=jthoughton@google.com \
--cc=linux-mm@kvack.org \
/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