From: Mike Rapoport <rppt@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Peter Xu <peterx@redhat.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>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Nikita Kalyazin <kalyazin@amazon.com>,
Michal Hocko <mhocko@suse.com>,
David Hildenbrand <david@redhat.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: Wed, 2 Jul 2025 21:16:31 +0300 [thread overview]
Message-ID: <aGV3fyZ0eGAt7Wag@kernel.org> (raw)
In-Reply-To: <CAJuCfpHN6vpDx+UNPEzJgZ_qD9USTJZ_+yZzQg2BpF_aRpufYw@mail.gmail.com>
On Tue, Jul 01, 2025 at 10:04:28AM -0700, Suren Baghdasaryan wrote:
> On Mon, Jun 30, 2025 at 3:16 AM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > It seems like we're assuming a _lot_ of mm understanding in the underlying
> > driver here.
> >
> > I'm not sure it's really normal to be handing around page table state and
> > folios etc. to a driver like this, this is really... worrying to me.
> >
> > This feels like you're trying to put mm functionality outside of mm?
>
> To second that, two things stick out for me here:
> 1. uffd_copy and uffd_get_folio seem to be at different abstraction
> levels. uffd_copy is almost the entire copy operation for VM_SHARED
> VMAs while uffd_get_folio is a small part of the continue operation.
> 2. shmem_mfill_atomic_pte which becomes uffd_copy for shmem in the
> last patch is quite a complex function which itself calls some IMO
> pretty internal functions like mfill_atomic_install_pte(). Expecting
> modules to implement such functionality seems like a stretch to me but
> maybe this is for some specialized modules which are written by mm
> experts only?
Largely shmem_mfill_atomic_pte() differs from anonymous memory version
(mfill_atomic_pte_copy()) by the way the allocated folio is accounted and
whether it's added to the page cache. So instead of uffd_copy(...) we might
add
int (*folio_alloc)(struct vm_area_struct *vma, unsigned long dst_addr);
void (*folio_release)(struct vm_area_struct *vma, struct folio *folio);
and then use them in mfill_atomic_pte_copy():
diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index bc473ad21202..6bad0dd70d3d 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -247,8 +247,11 @@ static int mfill_atomic_pte_copy(pmd_t *dst_pmd,
if (!*foliop) {
ret = -ENOMEM;
- folio = vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, dst_vma,
- dst_addr);
+ if (uffd_ops(dst_vma) && uffd_ops(dst_vma)->folio_alloc)
+ folio = uffd_ops(dst_vma)->folio_alloc(dst_vma, dst_addr);
+ else
+ folio = vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, dst_vma,
+ dst_addr);
if (!folio)
goto out;
@@ -307,6 +310,8 @@ static int mfill_atomic_pte_copy(pmd_t *dst_pmd,
return ret;
out_release:
folio_put(folio);
+ if (uffd_ops(dst_vma) && uffd_ops(dst_vma)->folio_release)
+ uffd_ops(dst_vma)->folio_release(dst_vma, folio);
goto out;
}
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-07-02 18:16 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
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 [this message]
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=aGV3fyZ0eGAt7Wag@kernel.org \
--to=rppt@kernel.org \
--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=peterx@redhat.com \
--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.