Sheng Yang wrote:
The free assigned device in the destroy path of VM, so as free irq. And we got
cancel_work_sync() in free irq which can sync with the execution of scheduled
work. And now before cancel_work_sync(), we disable the interrupt so that no
more schedule work happen again. So after cancel_work_sync(), everything(I
think it's irq handler and schedule work here) asynchronously should quiet
down.
Or I miss something?
Suppose the work_struct gets scheduled, but is delayed somewhere in the
scheduler. Some kill -9s the VM, and it starts getting destroyed.
cancel_work_sync() can no longer truly cancel the work, so it has to
schedule and wait for its completion.
So now we have kvm_assigned_dev_interrupt_work_handler() running in a
partially destroyed VM. It may work or not, but it's a fragile
situation (changing the order of destruction of components will likely
break things) and it's easy to avoid by keeping the reference count
elevated.
--
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
