All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	David Hildenbrand <david@redhat.com>,
	Nikita Kalyazin <kalyazin@amazon.com>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Vlastimil Babka <vbabka@suse.cz>,
	Muchun Song <muchun.song@linux.dev>,
	Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	James Houghton <jthoughton@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Oscar Salvador <osalvador@suse.de>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Ujwal Kundur <ujwal.kundur@gmail.com>
Subject: Re: [PATCH v2 1/4] mm: Introduce vm_uffd_ops API
Date: Fri, 19 Sep 2025 11:12:19 -0400	[thread overview]
Message-ID: <aM1y02xaEUkjOIsW@x1.local> (raw)
In-Reply-To: <33dc85e3-f3ac-4179-bf1d-821135fe3c42@lucifer.local>

On Fri, Sep 19, 2025 at 03:34:39PM +0100, Lorenzo Stoakes wrote:
> Peter -
> 
> I've been staying out of this discussion as I'm about to go to Kernel
> Recipes and then off on a (well-needed!) holiday, and I simply lack the
> bandwidth right now.
> 
> But I think we should all calm down a little here :)
> 
> Liam and I (more so Liam recently for above reasons) have pushed back
> because we have both personally experienced the consequences of giving
> drivers too much flexibility wrt core mm functionality.
> 
> This is the sole reason we have done so.
> 
> We are both eager to find a way forward that is constructive and works well
> for everybody involved. We WANT this series to land.
> 
> So I think perhaps we should take a step back and identify clearly what the
> issues are and how we might best address them.
> 
> I spoke to Mike off-list who suggested perhaps things aren't quite
> egregious as they seem with uffd_get_folio() so perhaps this is a means of
> moving forward.
> 
> But I think in broad terms - let's identify what the sensible options are,
> and then drill down into whichever one we agree is best to move forwards
> with.
> 
> Again, apologies for not being able to be more involved here,
> workload/other engagements dictate that I am unable to be.

That's totally fine, Lorenzo.  I appreciate your help on figuring things
out.

I do agree the discussion actually went nowhere.

I think so far the "issues" is very much clear, about exporting
uffd_get_folio(), as you correctly pointed out and I'm glad you discussed
with Mike.

My point is that hook is totally fine, and we need that exactly because we
want to keep ->fault() semantic clean.

Just to mention, if this series cannot land, I prefer landing Nikita's very
old version (a).  That'll make mm fault() ugly, I pointed that out, but if
all the people prefer that and all the people like to sign-off with it, I'm
OK from userfaultfd perspective.  I don't make judgement there.

Then this series can drop uffd_get_folio() and keep the rest in one way or
another, describing memory type attributes only, and need to cooperate only
a driver with a ->fault() that works for the new flag.  But then this
series will be a pure cleanup.  I'll likely then put this series aside as
it stops blocking things, and I also have a queue to flush myself elsewhere.

I wished we can just go with this series with uffd_get_folio() only.  Feel
free to discuss with more people, and let me know how this series should
move on.

Thanks a lot,

-- 
Peter Xu



  reply	other threads:[~2025-09-19 15:12 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-27 15:46 [PATCH v2 0/4] mm/userfaultfd: modulize memory types Peter Xu
2025-06-27 15:46 ` [PATCH v2 1/4] mm: Introduce vm_uffd_ops API Peter Xu
2025-06-29  8:50   ` Mike Rapoport
2025-07-02 19:30     ` Peter Xu
2025-06-30 10:15   ` Lorenzo Stoakes
2025-07-01 17:04     ` Suren Baghdasaryan
2025-07-02 15:40       ` Liam R. Howlett
2025-07-02 15:56       ` Lorenzo Stoakes
2025-07-02 17:08         ` Nikita Kalyazin
2025-07-02 17:39           ` Mike Rapoport
2025-07-02 19:46             ` Peter Xu
2025-07-03 17:48               ` Mike Rapoport
2025-07-04  9:34                 ` David Hildenbrand
2025-07-04 14:59                   ` Peter Xu
2025-07-04 19:39                     ` Liam R. Howlett
2025-09-01 16:01                       ` Nikita Kalyazin
2025-09-08 16:53                         ` Liam R. Howlett
2025-09-16 20:05                           ` Peter Xu
2025-09-17 15:29                             ` Liam R. Howlett
2025-09-17  9:25                           ` Mike Rapoport
2025-09-17 16:53                             ` Liam R. Howlett
2025-09-18  8:37                               ` Mike Rapoport
2025-09-18 16:47                                 ` Liam R. Howlett
2025-09-18 17:15                                   ` Nikita Kalyazin
2025-09-18 17:45                                     ` Lorenzo Stoakes
2025-09-18 17:53                                       ` David Hildenbrand
2025-09-18 18:20                                         ` Peter Xu
2025-09-18 19:43                                           ` Liam R. Howlett
2025-09-18 21:07                                             ` Peter Xu
2025-09-19  1:50                                               ` Liam R. Howlett
2025-09-19 14:16                                                 ` Peter Xu
2025-09-19 14:34                                                   ` Lorenzo Stoakes
2025-09-19 15:12                                                     ` Peter Xu [this message]
2025-09-19 19:38                                                   ` Liam R. Howlett
2025-09-22 16:33                                                     ` Peter Xu
2025-09-22 17:20                                           ` David Hildenbrand
2025-09-22 18:03                                             ` Peter Xu
2025-09-18 17:54                                     ` Liam R. Howlett
2025-09-18 18:05                                   ` Mike Rapoport
2025-09-18 18:32                                     ` Liam R. Howlett
2025-09-18 19:32                                       ` Peter Xu
2025-09-19  9:05                                       ` Mike Rapoport
2025-09-16 19:55                       ` Peter Xu
2025-09-19 17:22                         ` Liam R. Howlett
2025-09-22 16:38                           ` Peter Xu
2025-07-02 21:24           ` Liam R. Howlett
2025-07-02 21:36             ` Peter Xu
2025-07-03  2:00               ` Liam R. Howlett
2025-07-03 15:24                 ` Peter Xu
2025-07-03 16:15                   ` Lorenzo Stoakes
2025-07-03 17:39                   ` Liam R. Howlett
2025-07-02 20:24         ` Peter Xu
2025-07-03 16:32           ` Lorenzo Stoakes
2025-07-02 18:16       ` Mike Rapoport
2025-07-02 20:22         ` Peter Xu
2025-07-03 15:01           ` Suren Baghdasaryan
2025-07-03 15:45             ` Peter Xu
2025-07-03 16:01               ` Lorenzo Stoakes
2025-06-27 15:46 ` [PATCH v2 2/4] mm/shmem: Support " Peter Xu
2025-06-29  8:51   ` Mike Rapoport
2025-06-27 15:46 ` [PATCH v2 3/4] mm/hugetlb: " Peter Xu
2025-06-29  8:52   ` Mike Rapoport
2025-06-27 15:46 ` [PATCH v2 4/4] mm: Apply vm_uffd_ops API to core mm Peter Xu
2025-06-29  8:55   ` Mike Rapoport
2025-07-02 20:38     ` Peter Xu
2025-06-30 10:29 ` [PATCH v2 0/4] mm/userfaultfd: modulize memory types Lorenzo Stoakes
2025-07-01  0:15   ` Andrew Morton
2025-07-02 20:36   ` Peter Xu
2025-07-03 15:55     ` Lorenzo Stoakes
2025-07-03 16:26       ` Peter Xu
2025-07-03 16:44         ` Lorenzo Stoakes

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=aM1y02xaEUkjOIsW@x1.local \
    --to=peterx@redhat.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=jthoughton@google.com \
    --cc=kalyazin@amazon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=ujwal.kundur@gmail.com \
    --cc=vbabka@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.