Re: [Xen-devel] analyze for the P1 bug 593(xensource bug tracker)

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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