linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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
> 
> 




  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