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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-01-15 at 09:07 +0100, Roger Pau Monnà wrote:
> 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).

xend relies on udev running the scripts based on the kernel firing the
events, so I don't think xend can fix it, at least not without quite a
big change, I don't know how the xend maintainers would view that.

Does blkback fire the uevent before it has moved to state 2 though --
sounds a bit iffy to me. Perhaps there is an underlying kernel bug here?

Ian.


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