linux-kernel - Re: [RFC PATCH v2 38/51] KVM: guest_memfd: Split allocator pages for guest

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: <diqz34cejehy.fsf@ackerleytng-ctop.c.googlers.com>
Date: Thu, 05 Jun 2025 10:16:09 -0700
From: Ackerley Tng <ackerleytng@...gle.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>
Cc: "palmer@...belt.com" <palmer@...belt.com>, "pvorel@...e.cz" <pvorel@...e.cz>, 
	"catalin.marinas@....com" <catalin.marinas@....com>, "Miao, Jun" <jun.miao@...el.com>, 
	"Shutemov, Kirill" <kirill.shutemov@...el.com>, "pdurrant@...zon.co.uk" <pdurrant@...zon.co.uk>, 
	"steven.price@....com" <steven.price@....com>, "peterx@...hat.com" <peterx@...hat.com>, 
	"vbabka@...e.cz" <vbabka@...e.cz>, "jack@...e.cz" <jack@...e.cz>, 
	"amoorthy@...gle.com" <amoorthy@...gle.com>, "maz@...nel.org" <maz@...nel.org>, 
	"keirf@...gle.com" <keirf@...gle.com>, "vkuznets@...hat.com" <vkuznets@...hat.com>, 
	"quic_eberman@...cinc.com" <quic_eberman@...cinc.com>, 
	"mail@...iej.szmigiero.name" <mail@...iej.szmigiero.name>, "hughd@...gle.com" <hughd@...gle.com>, 
	"anthony.yznaga@...cle.com" <anthony.yznaga@...cle.com>, "Wang, Wei W" <wei.w.wang@...el.com>, 
	"Du, Fan" <fan.du@...el.com>, 
	"Wieczor-Retman, Maciej" <maciej.wieczor-retman@...el.com>, 
	"quic_svaddagi@...cinc.com" <quic_svaddagi@...cinc.com>, "Hansen, Dave" <dave.hansen@...el.com>, 
	"ajones@...tanamicro.com" <ajones@...tanamicro.com>, 
	"paul.walmsley@...ive.com" <paul.walmsley@...ive.com>, "nsaenz@...zon.es" <nsaenz@...zon.es>, "aik@....com" <aik@....com>, 
	"usama.arif@...edance.com" <usama.arif@...edance.com>, 
	"quic_mnalajal@...cinc.com" <quic_mnalajal@...cinc.com>, "fvdl@...gle.com" <fvdl@...gle.com>, 
	"rppt@...nel.org" <rppt@...nel.org>, "quic_cvanscha@...cinc.com" <quic_cvanscha@...cinc.com>, 
	"bfoster@...hat.com" <bfoster@...hat.com>, "willy@...radead.org" <willy@...radead.org>, 
	"anup@...infault.org" <anup@...infault.org>, "thomas.lendacky@....com" <thomas.lendacky@....com>, 
	"tabba@...gle.com" <tabba@...gle.com>, "mic@...ikod.net" <mic@...ikod.net>, 
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>, 
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "Zhao, Yan Y" <yan.y.zhao@...el.com>, 
	"binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "muchun.song@...ux.dev" <muchun.song@...ux.dev>, 
	"Li, Zhiquan1" <zhiquan1.li@...el.com>, "rientjes@...gle.com" <rientjes@...gle.com>, 
	"mpe@...erman.id.au" <mpe@...erman.id.au>, "Aktas, Erdem" <erdemaktas@...gle.com>, 
	"david@...hat.com" <david@...hat.com>, "jgg@...pe.ca" <jgg@...pe.ca>, 
	"Annapurve, Vishal" <vannapurve@...gle.com>, "Xu, Haibo1" <haibo1.xu@...el.com>, 
	"jhubbard@...dia.com" <jhubbard@...dia.com>, "Yamahata, Isaku" <isaku.yamahata@...el.com>, 
	"jthoughton@...gle.com" <jthoughton@...gle.com>, "will@...nel.org" <will@...nel.org>, 
	"steven.sistare@...cle.com" <steven.sistare@...cle.com>, "jarkko@...nel.org" <jarkko@...nel.org>, 
	"quic_pheragu@...cinc.com" <quic_pheragu@...cinc.com>, "chenhuacai@...nel.org" <chenhuacai@...nel.org>, 
	"Huang, Kai" <kai.huang@...el.com>, "shuah@...nel.org" <shuah@...nel.org>, 
	"dwmw@...zon.co.uk" <dwmw@...zon.co.uk>, "pankaj.gupta@....com" <pankaj.gupta@....com>, 
	"Peng, Chao P" <chao.p.peng@...el.com>, "nikunj@....com" <nikunj@....com>, 
	"Graf, Alexander" <graf@...zon.com>, "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>, 
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "yuzenghui@...wei.com" <yuzenghui@...wei.com>, 
	"jroedel@...e.de" <jroedel@...e.de>, "suzuki.poulose@....com" <suzuki.poulose@....com>, 
	"jgowans@...zon.com" <jgowans@...zon.com>, "Xu, Yilun" <yilun.xu@...el.com>, 
	"liam.merwick@...cle.com" <liam.merwick@...cle.com>, "michael.roth@....com" <michael.roth@....com>, 
	"quic_tsoni@...cinc.com" <quic_tsoni@...cinc.com>, 
	"richard.weiyang@...il.com" <richard.weiyang@...il.com>, "Weiny, Ira" <ira.weiny@...el.com>, 
	"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>, "Li, Xiaoyao" <xiaoyao.li@...el.com>, 
	"qperret@...gle.com" <qperret@...gle.com>, 
	"kent.overstreet@...ux.dev" <kent.overstreet@...ux.dev>, "dmatlack@...gle.com" <dmatlack@...gle.com>, 
	"james.morse@....com" <james.morse@....com>, "brauner@...nel.org" <brauner@...nel.org>, 
	"pgonda@...gle.com" <pgonda@...gle.com>, "quic_pderrin@...cinc.com" <quic_pderrin@...cinc.com>, 
	"hch@...radead.org" <hch@...radead.org>, "roypat@...zon.co.uk" <roypat@...zon.co.uk>, 
	"seanjc@...gle.com" <seanjc@...gle.com>
Subject: Re: [RFC PATCH v2 38/51] KVM: guest_memfd: Split allocator pages for
 guest_memfd use

"Edgecombe, Rick P" <rick.p.edgecombe@...el.com> writes:

> On Wed, 2025-05-14 at 16:42 -0700, Ackerley Tng wrote:
>> +
>> +static pgoff_t kvm_gmem_compute_invalidate_bound(struct inode *inode,
>> +						 pgoff_t bound, bool start)
>> +{
>> +	size_t nr_pages;
>> +	void *priv;
>> +
>> +	if (!kvm_gmem_has_custom_allocator(inode))
>
> General comment - It's a bit unfortunate how kvm_gmem_has_custom_allocator() is
> checked all over the place across this series. There are only two allocators
> after this, right? So one is implemented with callbacks presumably designed to
> fit other allocators, and one has special case logic in guest_memfd.c.
>
> Did you consider designing struct guestmem_allocator_operations so that it could
> encapsulate the special logic for both the existing and new
> allocators?

I did, yes. I believe it is definitely possible to make standard 4K
pages become another allocator too.

I would love to clean this up. Not sure if that will be a new series
after this one, or part of this one though.

> If it
> didn't work well, could we expect that a next allocator would actually fit
> struct guestmem_allocator_operations?
>

This was definitely designed to support allocators beyond
guestmem_hugetlb, though I won't promise that it will be a perfect fit
for future allocators. This is internal to the kernel and this interface
can be updated for future allocators though.

>> +		return bound;
>> +
>> +	priv = kvm_gmem_allocator_private(inode);
>> +	nr_pages = kvm_gmem_allocator_ops(inode)->nr_pages_in_folio(priv);
>> +
>> +	if (start)
>> +		return round_down(bound, nr_pages);
>> +	else
>> +		return round_up(bound, nr_pages);
>> +}
>> +
>> +static pgoff_t kvm_gmem_compute_invalidate_start(struct inode *inode,
>> +						 pgoff_t bound)
>> +{
>> +	return kvm_gmem_compute_invalidate_bound(inode, bound, true);
>> +}
>> +
>> +static pgoff_t kvm_gmem_compute_invalidate_end(struct inode *inode,
>> +					       pgoff_t bound)
>> +{
>> +	return kvm_gmem_compute_invalidate_bound(inode, bound, false);
>> +}
>> +