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: <1e6fcebf-f74e-46ad-912b-d7df13527aea@redhat.com>
Date: Mon, 23 Jun 2025 10:25:33 +0200
From: David Hildenbrand <david@...hat.com>
To: Peter Xu <peterx@...hat.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Cc: 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 20.06.25 21:03, Peter Xu wrote:

Hi Peter,

> 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."

> 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.

> 
> 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?

-- 
Cheers,

David / dhildenb