[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [BUG,PATCH] race in xen-block-hotplug



On 15/01/14 08:28, Philipp Hahn wrote:
> Hello,
> 
> we encountered a strange race condition in tools/hotplug/Linux/block,
> which only shows very rarely and only once for the first domain started
> after the host server is started. The complete details are in our
> Bugzilla at <https://forge.univention.org/bugzilla/show_bug.cgi?id=20481>.
> 
> In our case its Xen-4.1.3 (yes I know it's ancient, but the code is
> still the same in current Xen-git) and it only happens for file-backed
> files (in our case a ISO-image as CD-ROM).
> 
>>        # Avoid a race with the remove if the path has been deleted, or
>> ÂÂÂÂ# otherwise changed from "InitWait" state e.g. due to a timeout
>>         xenbus_state=$(xenstore_read_default "$XENBUS_PATH/state" 'unknown')
>>         if [ "$xenbus_state" != '2' ]
>>         then
>>           release_lock "block"
>>           fatal "Path closed or removed during hotplug add: $XENBUS_PATH 
>> state: $xenbus_state"
>>         fi
> 
> The problem is that sometimes the other end (kernel/qemu?) is too slow
> and the device is still in in state 1=Initializing. If that happens, the
> domU stat is aborted and destroyed.
> If the same VM is then started again, it works flawlessly.

This problem only manifests itself with xend and xl from Xen versions <
4.2, since 4.2 onwards libxl waits for the backend to switch to state 2
before launching hotplug scripts.

I would like to avoid having this kind of infinite loop in the block
hotplug script, is there anyway this can be fixed in xend? (which is the
only toolstack that has this problem in upstream versions).

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.