Amit Shah wrote:
I see from the call chain kvm_put_kvm->...->kvm_arch_destroy_vm, no locks are
taken to actually destroy the vm. We can't be in ioctls, sure. But shouldn't
the mutex be taken to ensure there's nothing else going on while destroying?
Locks are useless to guard against something happening concurrent with
destruction, since we're about to destroy the lock.
At least with the workqueue model, we could be called asynchronously in kernel
context and I would have held the mutex and about to inject interrupts while
everything is being wiped off underneath. However, the workqueue model tries
its best to schedule the work on the same CPU, though we can't use that
guarantee to ensure things will be fine.
---
So I had to get a ref to the current vm till we had any pending work scheduled.
I think that's the right thing to do.
I think I put in comments in the code, but sadly most of my comments we
stripped out before the merge.
Pity.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
