Re: xen-blkfront: BUG_ON(info->nr_rings)

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Mar 11, 2021 at 09:01:51AM +0000, Paul Durrant wrote:
> On 10/03/2021 14:58, Jason Andryuk wrote:
> > Hi,
> > 
> > I was running a loop of `xl block-attach ; xl block-detach` and I
> > triggered a BUG in xen-blkfront, drivers/block/xen-blkfront.c:1917
> > This is BUG_ON(info->nr_rings) in negotiate_mq called by blkback_changed.
> > 
> > I'm using Linux 5.4.103 and blktap3 on Xen 4.12 (OpenXT), though I
> > don't think that matters.  The backtrace and some preceding logs (from
> > the reproducer) are below.
> > 
> > I just repro-ed with this:
> > path=<backend path/state>
> > xenstore-write $path 5 ; xenstore-write $path 4
> > 
> > info->nr_rings is still set because of the unexpected transition
> > XenbusStateClosing -> XenbusStateConnected:
> > dom7: [ 2866.574853] vbd vbd-51728: blkfront:blkback_changed to state 5.
> > dom7: [ 2866.578385] vbd vbd-51728: blkfront:blkback_changed to state 4.
> > 
> > I'm not totally sure how to handle this.  The XenbusStateConnected
> > event should be creating a new blkfront device, but instead it's seen
> > by the old one which hasn't been cleaned up yet.

IIRC xenbus state changes (like you perform above) never trigger the
creation or destruction of devices on the bus. See
xenbus_otherend_changed.

xl block-detach however should indeed remove the device. We should add
an option to `xl block-detach -w` to wait for the device to actually
be removed before returning (or exit with a timeout).

> > 
> 
> Sounds like blkfront needs to be fixed. Once it is in state 5 the only state
> it should go to should be 6. From there it can cycle back to 4.

Indeed, there's likely some logic to be improved in blkfront so it
doesn't get messed up so badly on state changes by blkback.

I'm happy to review patch for both blkfront and libxl/xl in order to
make this better :).

Thanks, Roger.