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

[han <vanbas.han@xxxxxxxxx>]

Hi, Keir!

Your patch works quite well. We have created and destroyed the VMX more than 
500 times, and everything goes OK! I suppose the patch could solve the race 
condition! You may put the correctness code about VBD and VNIF together and 
send it to the maillist. We could help you to test it!
I prefer the wait_event and wakeup approach, it is clearer and straightful just 
as you said! :-)
BTW: I'm out of office right now, so i can't send the patch back to you! That's also why I change to another mailbox to send this mail. 

Thanks a lot for your help!

_______________________________________________________
Best Regards,
hanzhu



Han, Zhu дµÀ:
> Best Regards, 
> hanzhu
> -----Original Message-----
> From: Han, Zhu 
> Sent: 2006$BG/(J5$B7n(J10$BF|(J 14:27
> To: Yu, Ke; 'xen-devel@xxxxxxxxxxxxxxxxxxx'
> Cc: Helix-vmm
> Subject: analyze for the P1 bug 593(xensource bug tracker)
>
> Hi, all!
> Our QA team submitted a bug 593 to xensource bug tracker one month ago and it 
> was boosted up to P1 several days ago! So I spend some time to trace this bug 
> this week! Below words is what I have found:
> 1) This bug is hard to been reproduced on most of the platforms we owns, 
> especially the UP box.  The platform on which we got the bug and could 
> reproduce the bug stably is Paxville, which owns 4 physical CPUs, and 2 cores, 
> 2 hyperthreads for each CPU.
> 2) This root cause of this problem is "losetup -d /dev/loop*" could fail at a rather low 
> probability. "losetup -d /dev/loop*" is invoked by /etc/xen/scripts/block when the script processes 
> remove action. If we exhausted all the loop devices, the VMX cannot be initialized properly. That's why XEND 
> complains "Error: Device creation failed for domain ****". However, if we remove the loop device 
> manually, everything goes OK!
> 3) "losetup -d /dev/loop" failed because kernel/drivers/block/loop.c return 
> EBUSY for the LOOP_CLR_FD ioctl operation. The probable cause for this action is some one 
> else didn't close the loop device when we try to delete it!
> 4) The program opens the loop device could be VBD device driver. It opens the 
> loop device in vbd_create() through open_by_devnum. It closes the handle for 
> the loop device in vbd_free which is called by a schedulable work item 
> free_blkif. Is it true? If so, the problem could be arised by the possible race 
> condition between the work item and the hotplug script! When the xenbus driver 
> is notified the front end device has been destroyed by the xenstore thread, it 
> will remove the backend device and related resources, and then notify the 
> hotplug subsystem the remove action! Because the code close the loop device's 
> handle and the script delete the loop device can run concurrently, the script 
> could fail when it try to delete the loop device!
>
> My question is:
> 1) Does this possible race condition exist?
> 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?
>
> Since I'm a really newbie to this field, any tips and comments will be 
> appreciated!
> Thanks a lot!
>
>
>
> Best Regards, 
> hanzhu
>   
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel