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

On Mon, Jun 23, 2025 at 10:25:33AM +0200, David Hildenbrand wrote:
> On 20.06.25 21:03, Peter Xu wrote:
> 
> Hi Peter,

Hey David,

> 
> > Introduce a generic userfaultfd API for vm_operations_struct, so that one
> > vma, especially when as a module, can support userfaults without modifying
> 
> The sentence is confusing ("vma ... as a module").
> 
> Did you mean something like ".. so that a vma that is backed by a
> special-purpose in-memory filesystem like shmem or hugetlb can support
> userfaultfd without modifying the uffd core; this is required when the
> in-memory filesystem is built as a module."

I wanted to avoid mentioning of "in-memory file systems" here.

How about an updated commit like this?

  Currently, most of the userfaultfd features are implemented directly in the
  core mm.  It will invoke VMA specific functions whenever necessary.  So far
  it is fine because it almost only interacts with shmem and hugetlbfs.

  This patch introduces a generic userfaultfd API for vm_operations_struct,
  so that any type of file (including kernel modules that can be compiled
  separately from the kernel core) can support userfaults without modifying
  the core files.

  After this API applied, if a module wants to support userfaultfd, the
  module should only need to touch its own file and properly define
  vm_uffd_ops, instead of changing anything in core mm.

  ...

> 
> > the core files.  More importantly, when the module can be compiled out of
> > the kernel.
> > 
> > So, instead of having core mm referencing modules that may not ever exist,
> > we need to have modules opt-in on core mm hooks instead.
> > 
> > After this API applied, if a module wants to support userfaultfd, the
> > module should only need to touch its own file and properly define
> > vm_uffd_ops, instead of changing anything in core mm.
> 
> Talking about modules that much is a bit confusing. I think this is more
> about cleanly supporting in-memory filesystems, without the need to
> special-case each and every one of them; can be viewed a cleanup independent
> of the module requirement from guest_memfd.

Yes.  But if we don't need to support kernel modules actually we don't need
this.. IMHO it's so far really about cleanly support kernel modules, which
can even be out-of-tree (though that's not my purpose of the change..).

Please help check if above updated commit message would be better.

> 
> > 
> > Note that such API will not work for anonymous. Core mm will process
> > anonymous memory separately for userfault operations like before.
> > 
> > This patch only introduces the API alone so that we can start to move
> > existing users over but without breaking them.
> > 
> > Currently the uffd_copy() API is almost designed to be the simplistic with
> > minimum mm changes to move over to the API.
> > 
> 
> Is there a way to move part of the actual implementation (how this is all
> wired up) from patch #4 into this patch, to then only remove the old
> shmem/hugetlb hooks (that are effectively unused) in patch #4?

Not much I really removed on the hooks, but I was trying to reuse almost
existing functions.  Here hugetlb is almost untouched on hooks, then I
reused the shmem existing function for uffd_copy() rather than removing it
(I did need to remove the definition in the shmem header though becuse it's
not needed to be exported).

The major thing got removed in patch 4 was some random checks over uffd ops
and vma flags.  I intentionally made them all in patch 4 to make review
possible.  Otherwise it can be slightly awkward to reason what got removed
without knowing what is protecting those checks.

Thanks,

-- 
Peter Xu