Message-ID: <CAGtprH9cajbGWrU9PAZWNKMeKJ9DyhoV=nEYk_DnYnR8Fyapww@mail.gmail.com>
Date: Tue, 4 Nov 2025 07:29:14 -0800
From: Vishal Annapurve <vannapurve@...gle.com>
To: Yan Zhao <yan.y.zhao@...el.com>
Cc: Ackerley Tng <ackerleytng@...gle.com>, cgroups@...r.kernel.org, kvm@...r.kernel.org, 
	linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-mm@...ck.org, linux-trace-kernel@...r.kernel.org, x86@...nel.org, 
	akpm@...ux-foundation.org, binbin.wu@...ux.intel.com, bp@...en8.de, 
	brauner@...nel.org, chao.p.peng@...el.com, chenhuacai@...nel.org, 
	corbet@....net, dave.hansen@...el.com, dave.hansen@...ux.intel.com, 
	david@...hat.com, dmatlack@...gle.com, erdemaktas@...gle.com, 
	fan.du@...el.com, fvdl@...gle.com, haibo1.xu@...el.com, hannes@...xchg.org, 
	hch@...radead.org, hpa@...or.com, hughd@...gle.com, ira.weiny@...el.com, 
	isaku.yamahata@...el.com, jack@...e.cz, james.morse@....com, 
	jarkko@...nel.org, jgg@...pe.ca, jgowans@...zon.com, jhubbard@...dia.com, 
	jroedel@...e.de, jthoughton@...gle.com, jun.miao@...el.com, 
	kai.huang@...el.com, keirf@...gle.com, kent.overstreet@...ux.dev, 
	liam.merwick@...cle.com, maciej.wieczor-retman@...el.com, 
	mail@...iej.szmigiero.name, maobibo@...ngson.cn, 
	mathieu.desnoyers@...icios.com, maz@...nel.org, mhiramat@...nel.org, 
	mhocko@...nel.org, mic@...ikod.net, michael.roth@....com, mingo@...hat.com, 
	mlevitsk@...hat.com, mpe@...erman.id.au, muchun.song@...ux.dev, 
	nikunj@....com, nsaenz@...zon.es, oliver.upton@...ux.dev, palmer@...belt.com, 
	pankaj.gupta@....com, paul.walmsley@...ive.com, pbonzini@...hat.com, 
	peterx@...hat.com, pgonda@...gle.com, prsampat@....com, pvorel@...e.cz, 
	qperret@...gle.com, richard.weiyang@...il.com, rick.p.edgecombe@...el.com, 
	rientjes@...gle.com, rostedt@...dmis.org, roypat@...zon.co.uk, 
	rppt@...nel.org, seanjc@...gle.com, shakeel.butt@...ux.dev, shuah@...nel.org, 
	steven.price@....com, steven.sistare@...cle.com, suzuki.poulose@....com, 
	tabba@...gle.com, tglx@...utronix.de, thomas.lendacky@....com, vbabka@...e.cz, 
	viro@...iv.linux.org.uk, vkuznets@...hat.com, wei.w.wang@...el.com, 
	will@...nel.org, willy@...radead.org, wyihan@...gle.com, xiaoyao.li@...el.com, 
	yilun.xu@...el.com, yuzenghui@...wei.com, zhiquan1.li@...el.com
Subject: Re: [RFC PATCH v1 11/37] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES

On Tue, Nov 4, 2025 at 1:27 AM Yan Zhao <yan.y.zhao@...el.com> wrote:
>
> On Fri, Oct 17, 2025 at 01:11:52PM -0700, Ackerley Tng wrote:
> > For shared to private conversions, if refcounts on any of the folios
> > within the range are elevated, fail the conversion with -EAGAIN.
> >
> > At the point of shared to private conversion, all folios in range are
> > also unmapped. The filemap_invalidate_lock() is held, so no faulting
> > can occur. Hence, from that point on, only transient refcounts can be
> > taken on the folios associated with that guest_memfd.
> >
> > Hence, it is safe to do the conversion from shared to private.
> >
> > After conversion is complete, refcounts may become elevated, but that
> > is fine since users of transient refcounts don't actually access
> > memory.
> >
> > For private to shared conversions, there are no refcount checks. any
> > transient refcounts are expected to drop their refcounts soon. The
> > conversion process will spin waiting for these transient refcounts to
> > go away.
> Where's the code to spin?

When dealing with 4k pages, I think we don't need to spin waiting for
transient refcounts to drop, that logic will be needed when dealing
with huge folios in order to restructure them while handling
conversion. So the specific part can be safely dropped from the commit
message.

Powered by blists - more mailing lists