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

Re: [Xen-devel] [PATCH] libxl: don't set backend state to 5 when trying to unplug a device

2012/1/13 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Fri, 2012-01-13 at 13:10 +0000, Roger Pau Monnà wrote:
>> 2012/1/13 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
>> > On Fri, 2012-01-13 at 11:57 +0000, Roger Pau Monne wrote:
>> >> # HG changeset patch
>> >> # User Roger Pau Monne <roger.pau@xxxxxxxxxxxxx>
>> >> # Date 1326454785 -3600
>> >> # Node ID 887a3229fd7a50c04981e29709bc7210dafef38f
>> >> # Parent Â5b2676ac13218951698c49fa0350f2ac48220f3d
>> >> libxl: don't set backend state to 5 when trying to unplug a device
>> >>
>> >> libxl__device_remove was setting backend state to 5, which could
>> >> create a race condition, since the previous check for state != 4 and
>> >> setting state to 5 was not done inside of the same transaction, so the
>> >> kernel could change the state to 6 in the space between the check for
>> >> state != 4 and setting state to 5.
>> >>
>> >> I might be wrong, but since I don't think setting backend state to 5
>> >> helps in any way when disconnecting a device
>> >
>> > It's the exact thing which makes the disconnect happen at all, isn't it?
>> What makes the disconnect happen on NetBSD al least is removing the
>> frontend or setting the frontend state to 6, but this doesn't do
>> anything at all (it might be different on Linux though).
> Linux certainly uses state 5 (AKA XenbusStateClosing) in the state
> machine in at least netfront+back, blkfront+back pcifront+back and
> fbfront (fbback is not an in kernel driver).
> e.g. when netfront sees netback go to closing then it will shut itself
> down, see drivers/net/xen-netfront.c:netback_changed
>> Can someone confirm that this is actually useful on Linux?
> I think really any changes in these areas should be backed up with
> empirical experiments on a variety of system types (both front and
> back), otherwise we are basing things on supposition and heresay about
> how things are supposed to/do work. No one really knows for sure
> (witness the number of times we've all gone round on this).

Ok, I'm doing a new patch that enclosures everything inside a
transaction, and I will test it both on NetBSD and Linux. However, I
have a doubt, can we assume that a transaction that only performs a
read will always succeed (xs_transaction_end will never return < 0)?

Xen-devel mailing list



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