On 15/09/21 16:11, Kirill A. Shutemov wrote:
Would introducing memfd_unregister_guest() fix this?
I considered this, but it get complex quickly.
At what point it gets called? On KVM memslot destroy?
What if multiple KVM slot share the same memfd? Add refcount into memfd on
how many times the owner registered the memfd?
You will always have multiple KVM slots sharing the same memfd, because
memslots are SRCU-protected. So there will be multiple generations of
memslots around and unregistering must be delayed to after
synchronize_srcu (around the call to kvm_arch_commit_memory_region).
So KVM could just call memfd_{,un}register_guest as many times as it
calls fdget/fput. Looking at your test device, it would be like the
following pseudo-patch:
case GUEST_MEM_REGISTER: {
struct fd memfd = fdget(arg);
memfd_file = memfd.file;
return memfd_register_guest(memfd_file->f_inode, file,
&guest_ops, &guest_mem_ops);
}
case GUEST_MEM_UNREGISTER: {
if (!memfd_file)
return -EINVAL;
+ memfd_unregister_guest(memfd_file->f_inode, file);
fput(memfd_file);
memfd_file = NULL;
guest_mem_ops = NULL;
return 0;
and shmem_unregister_guest would be something like
struct shmem_inode_info *info = SHMEM_I(inode);
if (WARN_ON_ONCE(info->guest_owner != owner))
return;
if (--info->guest_usage_count)
return;
info->guest_owner = NULL;
info->guest_ops = NULL;
Paolo
It would leave us in strange state: memfd refcount owners (struct KVM) and
KVM memslot pins the struct file. Weird refcount exchnage program.
