Re: [PATCH v3 1/9] KVM: guest_memfd: take the invalidate lock when unbinding a dying file

["Garg, Shivank" <shivankg@amd.com>]

On Thu, 2026-09-10 at 11:58 +0200, David Hildenbrand (Arm) wrote:
> On 8/5/26 08:40, Shivank Garg wrote:
> > kvm_gmem_unbind() skips mapping->invalidate_lock when the guest_memfd
> > file is already dying. All other paths that modify f->bindings hold
> > that lock.
> > 
> > kvm_gmem_invalidate_{start,end}() checks f->bindings independently to
> > decide whether to begin or end KVM MMU invalidations. So, the bindings
> > must remain stable between the two calls. If a binding is removed in that
> > window, start increments mmu_invalidate_in_progress but end does not
> > decrement it. Example, unbind race with memory failure:
> > 
> >   CPU 0: memory failure               CPU 1: memslot delete
> >   ----------------------------------  ---------------------------
> >                                       (guest_memfd file is dying)
> >   kvm_gmem_error_folio()
> >     kvm_gmem_invalidate_start()
> >       finds binding
> >       mmu_invalidate_in_progress++
> >                                       kvm_gmem_unbind()
> >                                         get_file_active() fails
> >                                         store NULL in bindings
> >     kvm_gmem_invalidate_end()
> >       no binding found
> >       counter stays elevated
> > 
> > mmu_invalidate_retry() then returns 1 forever, so guest page faults
> > retry without ever installing a mapping and the guest hangs.
> > 
> > Take the invalidate lock in the dying-file path too. This prevents unbind
> > from removing a binding and leaking mmu_invalidate_in_progress. This is
> > safe because any caller that reaches this path holds slots_lock, so
> > kvm_gmem_release() cannot nullify the slots->gmem.file, until
> > kvm_gmem_unbind() finishes.
> > 
> > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > Closes: https://lore.kernel.org/all/20260728092027.225CF1F000E9@smtp.kernel.org
> > Fixes: ae431059e75d ("KVM: guest_memfd: Remove bindings on memslot deletion when gmem is dying")
> > Signed-off-by: Shivank Garg <shivankg@amd.com>
> > ---
> 
> This was sent independently in the meantime, correct? (or was it included in
> this series, IOW what's the expected patch flow)

Yes,
I split it out of this series because it was independent fix and should not
wait on guest_memfd folio migration.
https://lore.kernel.org/kvm/20260901-gmem-unbind-fix-v2-1-12febe1d2216@amd.com
I'll drop it from this series for next posting.

Similar for selftest fixes:
https://lore.kernel.org/kvm/20260907-gmem-selftests-fix-v3-0-7a4be5c1cc8a@amd.com


Thanks,
Shivank