On Mon, Jun 22, 2026, Binbin Wu wrote:
> On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
>
> [...]
>
> >
> > +static u64 kvm_gmem_get_attributes(struct inode *inode, pgoff_t index)
> > +{
> > + struct maple_tree *mt = &GMEM_I(inode)->attributes;
> > + void *entry = mtree_load(mt, index);
> > +
> > + return WARN_ON_ONCE(!entry) ? 0 : xa_to_value(entry);
>
> If the entry is unexpectedly missing, returning 0 means the attribute would
> be treated as shared. And then in kvm_gmem_fault_user_mapping(), it would
> allow the userspace to fault in the folio.
>
> Should gmem deny such edge case?
After several bugs this year where a WARN_ON_ONCE() fired, but was entirely
insufficient to prevent true badness, I'm definitely senstive to making the
"bad"
behavior as harmless as possible.
However, in this case I think we're just hosed. If KVM treats the memory as
private, KVM will incorrectly do prepare(), incorrectly allow populate(), and
will caused missed invalidations (though I suppose __kvm_gmem_set_attributes()
"only" lies to userspace in that case).
That said, assuming SHARED is definitely odd for cases where guest_memfd *can't*
hold shared memory. Ditto for assuming PRIVATE. What if we instead fall back
to
the "init" state, e.g.?
static u64 kvm_gmem_get_attributes(struct inode *inode, pgoff_t index)
{
struct maple_tree *mt = &GMEM_I(inode)->attributes;
void *entry = mtree_load(mt, index);
if (WARN_ON_ONCE(!entry)) {
bool shared = GMEM_I(inode)->flags &
GUEST_MEMFD_FLAG_INIT_SHARED;
return shared ? 0 : KVM_MEMORY_ATTRIBUTE_PRIVATE;
}
return xa_to_value(entry);
}
