[BUG] race condition in blkfront (probably other frontends too).

[BUG] race condition in blkfront (probably other frontends too).

[Gerd Hoffmann]

  Hi folks,

I've just seen it with the block frontend, but most likely the other
frontend drivers are affected too.  The blkfront drivers goes into
initialized state (in blkfront_probe), and *after* that xenbus_dev_probe
sets a watch on the state node of the device.  That leaves a race window
open for the backend going into connected state before the watch is
active.  If that happens the frontend doesn't notice the backend is
ready and never ever goes into connected state ...

cheers,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

Re: [BUG] race condition in blkfront (probably other frontends too).

[Keir Fraser]

On 24/7/08 15:15, "Gerd Hoffmann" <kraxel@redhat.com> wrote:

> I've just seen it with the block frontend, but most likely the other
> frontend drivers are affected too.  The blkfront drivers goes into
> initialized state (in blkfront_probe), and *after* that xenbus_dev_probe
> sets a watch on the state node of the device.  That leaves a race window
> open for the backend going into connected state before the watch is
> active.  If that happens the frontend doesn't notice the backend is
> ready and never ever goes into connected state ...

xenstored fires a watch immediately when it is registered. That should deal
with this particular race. Unless the watch gets discarded at the top of
otherend_changed() for some reason? I think you need to delve into this
issue a bit more, I'm afraid.

 -- Keir

Re: [BUG] race condition in blkfront (probably other frontends too).

[Gerd Hoffmann]

Keir Fraser wrote:
> xenstored fires a watch immediately when it is registered. That should deal
> with this particular race.

Oh, ok, I wasn't aware it does that.
/me goes fixing my code ...

thanks,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/