From: "David P. Reed" <dpreed@deepplum.com>
To: "Peter Xu" <peterx@redhat.com>
Cc: "James Houghton" <jthoughton@google.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 11:52:18 -0400 (EDT) [thread overview]
Message-ID: <1758037938.96199037@apps.rackspace.com> (raw)
In-Reply-To: <aMl4qLyNovWHhty9@x1.local>
On Tuesday, September 16, 2025 10:48, "Peter Xu" <peterx@redhat.com> said:
> 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?
synchronous would be better. But what I want to do is at least get notifications of swapin events (including the case when the page is in swap cache). Also, using UFFDIO_COPY can be useful for the swap in case might make sense (but rarely, because there's no way to access the data that was swapped out).
>
> 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.
I suspected that - however, notice that the rejection of registering minor mode is what I was reporting. It's oddly coded as if ordinary (4K) pages that are MAP_PRIVATE are the problem - no comment in the line of code I quoted explains why.
>
> 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.
Yeah, the documentation tends to suggest that the file descriptor should be shared via a Linux Socket. But the case of a fork() should work. (the examples use O_CLOEXEC, but of course that isn't "close on fork").
>
> Thanks,
>
> --
> Peter Xu
>
>
next prev parent reply other threads:[~2025-09-16 15:52 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
2025-09-16 15:52 ` David P. Reed [this message]
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=1758037938.96199037@apps.rackspace.com \
--to=dpreed@deepplum.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=jthoughton@google.com \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
/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