On Tue, Nov 4, 2025 at 1:27 AM Yan Zhao yan.y.zhao@intel.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.