Re: xbd detachment

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

David Young wrote:
> On Tue, Jul 28, 2009 at 06:31:31PM +0200, Manuel Bouyer wrote:
>> On Sat, Jul 25, 2009 at 03:50:39PM -0500, David Young wrote:
>>>>> Should this routine follow some other protocol in order to close down
>>>>> and revoke the grant_ref_t?
>>>> Hardly, revocation will end in panic() (you cannot free a grant table  
>>>> entry while there is a read/write lock acquired by the other end on the  
>>>> referenced page).
>>> What I mean is that xbd_xenbus_detach() may not use the correct
>>> protocol, and that is why the transfer/write/read status does not
>>> clear.  For example, what if xbd(4) indicates to the dom0 that it is
>>> finished with the ring, and then queues a transfer on the ring due to a
>>> programming mistake?
>>>
>>> It seems to me that xbd_xenbus_detach() may not be used very much, if at
>>> all.  Moreover, if it has ever been used before, then I think that the
>>> Dom0, not the DomU, had initiated the device's detachment.  That may, in
>>> fact, make a difference, even if it should not.
>> Actually it does. xbd_xenbus_detach() is called by the xenbus handler
>> though config_detach(); at this point the backed has switched to
>> XenbusStateClosing then XenbusStateClosed.
>> For a locally-initiated detach, the frontend need to switch to
>> XenbusStateClosing, then wait for the backend to switch to XenbusStateClosing
>> then XenbusStateClosed. This will cause config_detach() to be called
>> a second time. 
>>
>> Would the (untested) attached patch help ?
> 
> Thanks, that patch was enormously helpful.
> 
> I got it to mostly work with one minor change, except that
> config_detach(,DETACH_FORCE) panicked: config_detach() really does not
> like for a driver's detachment routine to return != 0 if the detachment
> was forced.  So I made it so xbd_xenbus_detach(,DETACH_FORCE) waits for
> the detach to complete, while xbd_xenbus_detach(,!DETACH_FORCE) exits
> with EALREADY.  That seems to work fine.
> 
> See the attached patch.  Ok to commit?
> 
> Included in my patch are some changes to the other xbd driver, whose
> sources are in xen/xbd.c.  Is that driver only applicable to Xen 2?  I
> still need to test that patch....

Working on Xen2 is a waste of time unless you are fixing bugs for
netbsd-5. Xen2 is going to get removed for NetBSD 6.

Christoph