On 6/19/26 02:17, Ackerley Tng wrote: > "Vlastimil Babka (SUSE)" <[email protected]> writes: > >> On 5/23/26 02:17, Ackerley Tng via B4 Relay wrote: >>> From: Ackerley Tng <[email protected]> >>> >>> When converting memory to private in guest_memfd, it is necessary to ensure >>> that the pages are not currently being accessed by any other part of the >>> kernel or userspace to avoid any current user writing to guest private >>> memory. >>> >>> guest_memfd checks for unexpected refcounts to determine whether a page is >>> still in use. The only expected refcounts after unmapping the range >>> requested for conversion are those that are held by guest_memfd itself. >> >> Is it sufficient to only check, and not also freeze the refcount? (i.e. >> using folio_ref_freeze()), because without freezing, anything (e.g. >> compaction's pfn-based scanner) could do a speculative folio_try_get() and >> the checked refcount becomes stale. >> > > I believe there's no issue here, since the main thing here is to check > for long-term pins on the folio. Perhaps David can help me verify. :)
I think I raised this in the past as well: ideally, we'd be freezing the refcount, then, there is no need to worry about any concurrent access. However, we could really only get additional page references through PFN walkers (or speculative references), not through page tables or GUP pins, which is what we care about. So if we can tolerate a speculative bump+release of a folio reference, likely we're good. -- Cheers, David
