WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] blkfront: Move blkif_interrupt into a tasklet.

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] blkfront: Move blkif_interrupt into a tasklet.
From: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Date: Thu, 02 Sep 2010 16:08:52 -0700
Cc: Xen <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tom Kopec <tek@xxxxxxx>
Delivery-date: Thu, 02 Sep 2010 16:09:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C802934.2000305@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix VMD
References: <1282546470-5547-1-git-send-email-daniel.stodden@xxxxxxxxxx> <1282546470-5547-2-git-send-email-daniel.stodden@xxxxxxxxxx> <4C802934.2000305@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2010-09-02 at 18:46 -0400, Jeremy Fitzhardinge wrote:
> On 08/22/2010 11:54 PM, Daniel Stodden wrote:
> > Response processing doesn't really belong into hard irq context.
> >
> > Another potential problem this avoids is that switching interrupt cpu
> > affinity in Xen domains can presently lead to event loss, if
> > RING_FINAL_CHECK is run from hard irq context.
> 
> I just got this warning from a 32-bit pv domain.  I think it may relate
> to this change.  The warning is

We clearly spin_lock_irqsave all through the blkif_do_interrupt frame.

It follows that something underneath quite unconditionally chose to
reenable them again (?)

Either: Can you add a bunch of similar WARN_ONs along that path?

Or: This lock is quite coarse-grained. The lock only matters for queue
access, and we know irqs are reenabled, so no need for flags. In fact we
only need to spin_lock_irq around the __blk_end_ calls and
kick_pending_.

But I don't immediately see what's to blame, so I'd be curious.

Daniel


> void blk_start_queue(struct request_queue *q)
> {
>       WARN_ON(!irqs_disabled());


> Oddly, I only saw this pair once at boot, and after that the system
> seemed fine...
> 
> [    4.376451] ------------[ cut here ]------------
> [    4.377415] WARNING: at /home/jeremy/git/linux/block/blk-core.c:337 
> blk_start_queue+0x20/0x36()
> [    4.377415] Modules linked in: xfs exportfs xen_blkfront [last unloaded: 
> scsi_wait_scan]
> [    4.377415] Pid: 0, comm: swapper Not tainted 2.6.32.21 #32
> [    4.377415] Call Trace:
> [    4.377415]  [<c1039f74>] warn_slowpath_common+0x65/0x7c
> [    4.377415]  [<c11b3ae1>] ? blk_start_queue+0x20/0x36
> [    4.377415]  [<c1039f98>] warn_slowpath_null+0xd/0x10
> [    4.377415]  [<c11b3ae1>] blk_start_queue+0x20/0x36
> [    4.377415]  [<edc74712>] kick_pending_request_queues+0x1c/0x2a 
> [xen_blkfront]
> [    4.377415]  [<edc74ec4>] blkif_do_interrupt+0x176/0x189 [xen_blkfront]
> [    4.377415]  [<c103e063>] tasklet_action+0x63/0xa8
> [    4.377415]  [<c103f2d5>] __do_softirq+0xac/0x152
> [    4.377415]  [<c103f3ac>] do_softirq+0x31/0x3c
> [    4.377415]  [<c103f484>] irq_exit+0x29/0x5c
> [    4.377415]  [<c121a1b6>] xen_evtchn_do_upcall+0x29/0x34
> [    4.377415]  [<c100a027>] xen_do_upcall+0x7/0xc
> [    4.377415]  [<c10023a7>] ? hypercall_page+0x3a7/0x1005
> [    4.377415]  [<c10065a9>] ? xen_safe_halt+0x12/0x1f
> [    4.377415]  [<c10042cb>] xen_idle+0x27/0x38
> [    4.377415]  [<c100877e>] cpu_idle+0x49/0x63
> [    4.377415]  [<c14a6427>] rest_init+0x53/0x55
> [    4.377415]  [<c179c814>] start_kernel+0x2d4/0x2d9
> [    4.377415]  [<c179c0a8>] i386_start_kernel+0x97/0x9e
> [    4.377415]  [<c179f478>] xen_start_kernel+0x576/0x57e
> [    4.377415] ---[ end trace 0bfb98f0ed515cdb ]---
> [    4.377415] ------------[ cut here ]------------
> [    4.377415] WARNING: at /home/jeremy/git/linux/block/blk-core.c:245 
> blk_remove_plug+0x20/0x7e()
> [    4.377415] Modules linked in: xfs exportfs xen_blkfront [last unloaded: 
> scsi_wait_scan]
> [    4.377415] Pid: 0, comm: swapper Tainted: G        W  2.6.32.21 #32
> [    4.377415] Call Trace:
> [    4.377415]  [<c1039f74>] warn_slowpath_common+0x65/0x7c
> [    4.377415]  [<c11b3961>] ? blk_remove_plug+0x20/0x7e
> [    4.377415]  [<c1039f98>] warn_slowpath_null+0xd/0x10
> [    4.377415]  [<c11b3961>] blk_remove_plug+0x20/0x7e
> [    4.377415]  [<c11b39ca>] __blk_run_queue+0xb/0x5e
> [    4.377415]  [<c11b3af4>] blk_start_queue+0x33/0x36
> [    4.377415]  [<edc74712>] kick_pending_request_queues+0x1c/0x2a 
> [xen_blkfront]
> [    4.377415]  [<edc74ec4>] blkif_do_interrupt+0x176/0x189 [xen_blkfront]
> [    4.377415]  [<c103e063>] tasklet_action+0x63/0xa8
> [    4.377415]  [<c103f2d5>] __do_softirq+0xac/0x152
> [    4.377415]  [<c103f3ac>] do_softirq+0x31/0x3c
> [    4.377415]  [<c103f484>] irq_exit+0x29/0x5c
> [    4.377415]  [<c121a1b6>] xen_evtchn_do_upcall+0x29/0x34
> [    4.377415]  [<c100a027>] xen_do_upcall+0x7/0xc
> [    4.377415]  [<c10023a7>] ? hypercall_page+0x3a7/0x1005
> [    4.377415]  [<c10065a9>] ? xen_safe_halt+0x12/0x1f
> [    4.377415]  [<c10042cb>] xen_idle+0x27/0x38
> [    4.377415]  [<c100877e>] cpu_idle+0x49/0x63
> [    4.377415]  [<c14a6427>] rest_init+0x53/0x55
> [    4.377415]  [<c179c814>] start_kernel+0x2d4/0x2d9
> [    4.377415]  [<c179c0a8>] i386_start_kernel+0x97/0x9e
> [    4.377415]  [<c179f478>] xen_start_kernel+0x576/0x57e
> [    4.377415] ---[ end trace 0bfb98f0ed515cdc ]---
> 
>       J
> 



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