linux-kernel - Re: [PATCH v3 1/4] mm: Introduce vm_uffd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6csw4pmymno4kdtlbzd74posr3dekamq4zkje2mfkmbg5q7xbx@y3o323tbm7h3>
Date: Tue, 7 Oct 2025 14:46:46 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Peter Xu <peterx@...hat.com>
Cc: David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        James Houghton <jthoughton@...gle.com>,
        Nikita Kalyazin <kalyazin@...zon.com>,
        Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
        Ujwal Kundur <ujwal.kundur@...il.com>, Mike Rapoport <rppt@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>, Michal Hocko <mhocko@...e.com>,
        Muchun Song <muchun.song@...ux.dev>,
        Oscar Salvador <osalvador@...e.de>, Hugh Dickins <hughd@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [PATCH v3 1/4] mm: Introduce vm_uffd_ops API

* Peter Xu <peterx@...hat.com> [251007 12:47]:

...

> > > 
> > > This way is_vm_hugetlb_page() never really needs to be used because the
> > > function pointer already makes that distinction.
> > > 
> > > Right now, we have checks for hugetlb through other functions that "pass
> > > off to appropriate routine", and we end up translating the
> > > ioctl_supports into the function call eventually, anyways.
> > 
> > Right, it would be great to get rid of that. I recall I asked for such a
> > cleanup in RFC (or was it v1).
> 
> I didn't send RFC, likely you meant this reply in v1?
> 
> https://lore.kernel.org/all/0126fa5f-b5aa-4a17-80d6-d428105e45c7@redhat.com/
> 
>         I agree that another special-purpose file (like implemented by
>         guest_memfd) would need that. But if we could get rid of
>         "hugetlb"/"shmem" special-casing in userfaultfd, it would be a
>         rasonable independent cleanup.
> 
> Get rid of hugetlbfs is still not my goal as of in this series.

My example picked hugetlbfs because it is the most special of the types
of memory we have (so very special).  If the interface works for
hugetlbfs, then the rest will use a subset of the features and be happy.

IOW, doing the hard thing first makes what follows easy.  Doing the easy
thing first may mean rewriting the easy thing once you arrive at the
more difficult part.

> 
> OTOH, I generalized shmem and removed shmem.h header from userfaultfd, but
> that was prior versions when with uffd_copy() and it was rejected.
> 
> What should I do now to move this series forward?  Could anyone provide a
> solid answer?

My understanding is that we need an interface for memory types so they
are modularised, with the short term goal of solving the faulting
support for guest_memfd and the long term goal of code cleanup, or at
least don't make things worse.

I think we all agree on that?

I propose that we need to add the minimum amount of uffd_ops to support
guest_memfd's specialness without creating an interface that makes
things worse.

It is very difficult to see a reason to pass in two variables (modes and
ioctls) to dispatch to the correct function in a struct that could
simply point to the function in the first place.  If we can avoid that,
then it would be good.

Looking at the example you pointed to here [1], It appears the minimal
viable product would need to implement this:

uffd_ops = {
        .get_folio = <>,
        .minor_fault = <>,
        .atomic_fill_continue = <>,
}

Then shmem and hugetlb can define these and end up calling them in
today's spaghetti, but we are free to append more uffd_ops to reduce the
spaghetti later.

If using new #defines to clears up translations of features/modes and
ioctl codes, then please do that.  These should be removable once the
uffd_ops grows to support all necessary calls.

If there are places where you need to consult the modes/ioctls and a
translation does not work, then you could add something to uffd_ops that
is NULL for guest_memfd and use it to determine if the code path is
valid.  But this code should already exist for the other memory types.

What does everyone think?

[1]. https://lore.kernel.org/all/114133f5-0282-463d-9d65-3143aa658806@amazon.com/