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)
--
Cheers,
David
