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

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


  • To: Gerd Hoffmann <kraxel@xxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Thu, 24 Jul 2008 15:23:57 +0100
  • Cc:
  • Delivery-date: Thu, 24 Jul 2008 07:24:24 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcjtmOhnJvlp6FmMEd224QAX8io7RQ==
  • Thread-topic: [Xen-devel] [BUG] race condition in blkfront (probably other frontends too).

On 24/7/08 15:15, "Gerd Hoffmann" <kraxel@xxxxxxxxxx> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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