This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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

<Prev in Thread] Current Thread [Next in Thread>