Re: block-detatch on 2.6.23.8 guest == WARNING: at block/ll_rw_blk.c:1579 blk_remove_plug()

[Jeremy Fitzhardinge <jeremy@goop.org>]

Christopher S. Aker wrote:
> Dom0:
> root@dallas38:~# xm block-detach xencaker 51744
> root@dallas38:~#
>
> DomU:
> WARNING: at block/ll_rw_blk.c:1579 blk_remove_plug()
>  [<c035bed6>] blk_remove_plug+0x66/0x70
>  [<c035bf58>] blk_stop_queue+0x8/0x20
>  [<c039e429>] blkfront_closing+0x39/0x80
>  [<c039ed77>] backend_changed+0x337/0x410
>  [<c0161c7b>] kfree+0x7b/0xb0
>  [<c037b987>] xenbus_gather+0x77/0xa0
>  [<c037a4d3>] xenbus_read_driver_state+0x33/0x50
>  [<c037cde2>] otherend_changed+0x92/0xa0
>  [<c037bbab>] xenwatch_thread+0x6b/0x130
>  [<c0132e90>] autoremove_wake_function+0x0/0x50
>  [<c037bb40>] xenwatch_thread+0x0/0x130
>  [<c0132cb4>] kthread+0x74/0x80
>  [<c0132c40>] kthread+0x0/0x80
>  [<c01073e7>] kernel_thread_helper+0x7/0x10

This is a bit mysterious.  The call path looks like it unambiguously
disables interrupts:  blkfront_closing() does
"spin_lock_irqsave(&blkif_io_lock, flags);" and
then shortly after calls blk_stop_queue -> blk_remove_plug.  The only
possibility I see is that maybe del_gendisk is enabling them or
something.  I'll try to repro this, but in the meantime could you add:

	spin_lock_irqsave(&blkif_io_lock, flags);

+	WARN_ON(!irqs_disabled());

	del_gendisk(info->gd);

+	WARN_ON(!irqs_disabled());

	/* No more blkif_request(). */
	blk_stop_queue(info->rq);


to drivers/block/xen-blkfront.c:blkfront_closing() and see if one or
both triggers?

Thanks,
    J