Sean Christopherson <[email protected]> writes: > On Thu, Jun 18, 2026, Ackerley Tng wrote: >> When checking if a guest_memfd folio is safe for conversion, its refcount >> is examined. A folio may be present in a per-CPU lru_add fbatch, which >> temporarily increases its refcount. > > Under what circumstances does this happen,
It happened 100% of the time in selftests. Perhaps it's because in the selftests the pages are almost always freshly allocated and so the lru_add fbatch isn't full yet? (and that the host isn't super busy so lru_add fbatch doesn't get drained yet). I've not tested without this beyond selftests. I don't think we can depend on workloads to drain the lru_add fbatch? > and what alternatives are there for > userspace to work around the issue? The thing is, the refcounts don't come with a label of who added the refcount so we can't really return a different error for lru_add fbatch presence. All folios get added to the lru_add fbatch even if they're unevictable and eventually not participate in LRU. We could make userspace try fadvise(POSIX_FADV_DONTNEED)? I think that has other problems, and this kind of makes userspace have one more user to guess. Userspace already needs to check if the page is pinned for DMA, and if it's not pinned for DMA, userspace already needs to retry because of other possible kernel users...
