Re: [PATCH] mm/gup: factor out LRU cache draining for folio into lru_cache_drain_for_folio()

[Andrew Morton]

On Thu, 06 Aug 2026 20:09:06 +0200 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:

> KVM with guest_memfd wants to remove any folio references due to LRU
> caches, as it really must only allow to convert folios from shared to
> private when there are no unexpected folio references (e.g., from GUP
> references).
> 
> So, to drive the refcount down, it needs a way to flush the LRU caches.
> Let's factor out what we have in lru_cache_drain_for_folio(). Document
> it, and also mention that concurrent folio (un)mapping might, in theory,
> miss detecting LRU cache references. Keep obtaining the expected refcount
> twice to minimize the possibility. For the current and future user that
> should work, and we don't really have a better alternative: we could
> detect if the mapcount changed, but it would still be racy and add more
> complexity with questionable benefit.
> 
> Maybe there is a chance to avoid the draining entirely in the future,
> by avoiding extra references from the LRU cache: Hugh thinks there might
> be a way. But for the time being, this handling is unfortunately
> required.
> 
> Make folio_may_be_lru_cached() accept a const pointer so
> lru_cache_drain_for_folio() can accept a const pointer as well.
> 

Thanks, I'll put this straight into mm-unstable next to your [1].

> This is based on the fix [1] that is already on its way upstream.
> 
> guest_memfd will need this for the work they are now targeting for
> 7.4. I expect the guest_memfd user to add a KVM-only export of the
> symbol.
> 
> So either we get this into 7.3-rc1 as well, or Ackerley can carry the
> patch as his stuff goes upstream through the x86 KVM tree.

I expect both [1] and this patch will be in the second week of merge
window batch.

> [1] https://lore.kernel.org/r/20260731-check_and_migrate_movable_folios-v1-1-e0002d7b791e@xxxxxxxxxx 
> [2] https://lore.kernel.org/r/20260728-gmem-inplace-conversion-v9-14-35f9aec2aed2@xxxxxxxxxx