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] [day] [month] [year] [list]

Message-ID: <aOV6ttA17Pt2S8xO@x1.local>
Date: Tue, 7 Oct 2025 16:40:22 -0400
From: Peter Xu <peterx@...hat.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
	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

On Tue, Oct 07, 2025 at 04:25:48PM -0400, Liam R. Howlett wrote:
> > Would it look better to you if I drop uffd_modes_supported, deducing it
> > from uffd_ioctls_supported?
> > 
> > I believe that's what David mentioned very initially here:
> > 
> > https://lore.kernel.org/r/f1da3505-f17f-4829-80c1-696b1d99057d@redhat.com
> > 
> > I'd rather go with the two fields, but if we're trying to introduce another
> > feature sets almost only for vm_uffd_ops, I'd prefer keeping it simple, and
> > deduce the modes from ioctls.
> > 
> > Is that ok for you?  So it'll have (1) get_folio(), (2) supported_ioctls.
> > That's all.
> 
> This is still middleware - a translation of flags passed in to figure
> out what function to call.  I don't think this is the best path forward
> as it means we have to complicate the layer for every user we add while
> we are already providing the most flexible return of a folio.
> 
> This will end up making things worse, IMO.
> 
> Think, for example, we add hugetlbfs_v2 - every place we have
> "if (is_hugetlbfs())" will now need an "else if(is_hugetlbfsv2())" to
> accommodate something that probably has the same uffd_ops as hugetlbfs
> v1.
> 
> Why would we do this instead of actually making your uffd_ops a complete
> API, or at least a subset of the API that supports guest-memfd?

It will be the complete API with (1) and (2) on minor fault.

When one proposes hugetlbfsv2, it should make sure it will work with the
API that only has (1)+(2).  Some uffd paths may need touch up (e.g. on
detecting VMA sizes), but it'll never be "if (is_hugetlbfsv2())".

That's IMHO one of the major purposes of having hugetlbfsv2 after all,
which is to start using the common MM apis, including the one we're going
to introduce here.

Thanks,

-- 
Peter Xu