> > --- kvm.orig/virt/kvm/kvm_main.c
> > +++ kvm/virt/kvm/kvm_main.c
> > @@ -1303,7 +1303,7 @@ static int kvm_vcpu_release(struct inode
> > return 0;
> > }
> >
> > -static const struct file_operations kvm_vcpu_fops = {
> > +static struct file_operations kvm_vcpu_fops = {
> > .release = kvm_vcpu_release,
> > .unlocked_ioctl = kvm_vcpu_ioctl,
> > .compat_ioctl = kvm_vcpu_ioctl,
> > @@ -1318,6 +1318,7 @@ static int create_vcpu_fd(struct kvm_vcp
> > int fd = anon_inode_getfd("kvm-vcpu", &kvm_vcpu_fops, vcpu, 0);
> > if (fd < 0)
> > kvm_put_kvm(vcpu->kvm);
> > + __module_get(kvm_vcpu_fops.owner);
> > return fd;
> > }
> >
> > @@ -2061,6 +2062,7 @@ int kvm_init(void *opaque, unsigned int
> > }
> >
> > kvm_chardev_ops.owner = module;
> > + kvm_vcpu_fops.owner = module;
> >
> > r = misc_register(&kvm_dev);
> > if (r) {
> >
>
> Messing with module counts is slightly ugly. How about having a vm fd
> fget() the /dev/kvm fd() instead?
I personally find fget (and fput) slightly more ugly than handling the module
reference count. Especially if the problem is module unloading...the module
refcount looks so natural.
I am also a bit worried by fget/fput, since we would call fput in the release
function - which is part of the module. Wouldnt that open another very small
race?
In addition, we would need variables containing the fd and the file pointer
for /dev/kvm, since fget/fput need some parameters, no? (Is there an easy way
to get the fd from the struct file *filp? Searching current->files, seems to
be the only method I know)
To me, the fget approach looks more complicated and less safe.
Christian
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
