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 <[email protected]>
> > Closes:
> > https://lore.kernel.org/all/[email protected]
> > Fixes: ae431059e75d ("KVM: guest_memfd: Remove bindings on memslot deletion
> > when gmem is dying")
> > Signed-off-by: Shivank Garg <[email protected]>
> > ---
>
> 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/[email protected]
I'll drop it from this series for next posting.
Similar for selftest fixes:
https://lore.kernel.org/kvm/[email protected]
Thanks,
Shivank
