On Tue, Nov 4, 2025 at 1:27 AM Yan Zhao <[email protected]> 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.
