| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] analyze for the P1 bug 593(xensource bug tracker)
On 10 May 2006, at 07:26, Han, Zhu wrote:
My question is:
1) Does this possible race condition exist?
It certainly sounds plausible to me!
2) Why does the code closing the loop device been put to another out of
code workitem instead of finishing all work directly in
blkback_remove()? Any operation in free_blkif() could be blocked? Which
one?
Several are unsafe in interrupt context, for example:
* unbind_from_irqhandler calls free_irq which can do procfs work
* vbd_free calls blkdev_put which takes a semaphore and probably does
a whole load of blocking operations
* free_vm_area calls remove_vm_area which acquires a rw spinlock which
is not interrupt safe
Correctness dictates that we should be withholding the upcall to user
space until the deferred operations are complete. Perhaps you could try
doing a wait_for_completion() in blkback_remove, immediately after the
blkif_put(). This would then block until kicked by free_blkif().
I may try to put some code together myself if I have time. I suspect
netback has a similar issue also (although of course the remove
operation tends to be non-critical for net devices, so it won't usually
matter!).
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home