Re: [PATCH v3 1/4] KVM: guest_memfd: Gracefully handle xarray errors when binding a memslot

[Sean Christopherson]

On Wed, Sep 09, 2026, Ackerley Tng wrote:
> "David Hildenbrand (Arm)" <david@xxxxxxxxxx> writes:
> 
> >
> > [...snip...]
> >
> >> -	xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL);
> >> +	xar = xa_store_range(&f->bindings, start, end - 1, slot, GFP_KERNEL);
> >> +
> >> +	r = xa_is_err(xar) ? xa_err(xar) : 0;
> >
> >
> > r = xa_err(xar);
> >
> > Should be sufficient, right?
> >
> > mm/memremap.c:pagemap_range() uses that and just avoids the intermediate xar
> > value completely.
> >
> > r = xa_err(xa_store_range(...);
> >
> >> +	if (r) {
> >> +		xa_store_range(&f->bindings, start, end - 1, NULL, GFP_KERNEL);
> >> +		slot->gmem.file = NULL;
> >> +		slot->gmem.pgoff = 0;
> >> +		slot->flags &= ~KVM_MEMSLOT_GMEM_ONLY;
> 
> Was wondering if the changelog should explain why not move
> xa_store_range() before setting up these 3 fields that need undoing.

Ya, I'll add some context.  The TL;DR is "look at patch 3".

> IIUC the reason is that other parts of gmem code expect any slots in
> bindings to have a non-NULL gmem.file?

Not just gmem code, all of KVM.  The instant the binding is created, the memslot
becomes reachable.  Because KVM manages memslots through SRCU-protected pointers,
for all intents and purposes memslots must be immutable if they are reachable,
otherwise readers could see half-baked state, e.g. a memslot with a gmem file but
the wrong pgoff.