KVM: set owner of cpu and vm file operations
authorChristian Borntraeger <borntraeger@de.ibm.com>
Mon, 23 Mar 2009 20:51:30 +0000 (17:51 -0300)
committerGreg Kroah-Hartman <gregkh@suse.de>
Sat, 2 May 2009 17:57:09 +0000 (10:57 -0700)
commit622d662934afe335af62dd8a0e9e64a39e8372dc
tree684fb5c82c087ce15868c20d61861aaa43cf35b6
parent11cccb1f39e3607ea776b512c2258229cbaf855b
KVM: set owner of cpu and vm file operations

(cherry picked from 3d3aab1b973b01bd2a1aa46307e94a1380b1d802)

There is a race between a "close of the file descriptors" and module
unload in the kvm module.

You can easily trigger this problem by applying this debug patch:
>--- kvm.orig/virt/kvm/kvm_main.c
>+++ kvm/virt/kvm/kvm_main.c
>@@ -648,10 +648,14 @@ void kvm_free_physmem(struct kvm *kvm)
>                kvm_free_physmem_slot(&kvm->memslots[i], NULL);
> }
>
>+#include <linux/delay.h>
> static void kvm_destroy_vm(struct kvm *kvm)
> {
>        struct mm_struct *mm = kvm->mm;
>
>+       printk("off1\n");
>+       msleep(5000);
>+       printk("off2\n");
>        spin_lock(&kvm_lock);
>        list_del(&kvm->vm_list);
>        spin_unlock(&kvm_lock);

and killing the userspace, followed by an rmmod.

The problem is that kvm_destroy_vm can run while the module count
is 0. That means, you can remove the module while kvm_destroy_vm
is running. But kvm_destroy_vm is part of the module text. This
causes a kerneloops. The race exists without the msleep but is much
harder to trigger.

This patch requires the fix for anon_inodes (anon_inodes: use fops->owner
for module refcount).
With this patch, we can set the owner of all anonymous KVM inodes file
operations. The VFS will then control the KVM module refcount as long as there
is an open file. kvm_destroy_vm will be called by the release function of the
last closed file - before the VFS drops the module refcount.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
virt/kvm/kvm_main.c