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: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] blkfront: Move blkif_interrupt into a tasklet.
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 08 Sep 2010 16:37:02 +1000
Cc: Xen <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tom Kopec <tek@xxxxxxx>
Delivery-date: Tue, 07 Sep 2010 23:37:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1283912499.3138.170.camel@xxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <1282546470-5547-1-git-send-email-daniel.stodden@xxxxxxxxxx> <1282546470-5547-2-git-send-email-daniel.stodden@xxxxxxxxxx> <4C802934.2000305@xxxxxxxx> <1283468932.3092.3924.camel@xxxxxxxxxxxxxxxxxxx> <4C86EED5.1070807@xxxxxxxx> <1283912499.3138.170.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2
 On 09/08/2010 12:21 PM, Daniel Stodden wrote:
> On Tue, 2010-09-07 at 22:03 -0400, Jeremy Fitzhardinge wrote:
>> On 09/03/2010 09:08 AM, Daniel Stodden wrote:
>>> 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.
>> It looks like __blk_end_request_all(req, error); (line 743) is returning
>> with interrupts enabled sometimes (not consistently).  I had a quick
>> look through the code, but I couldn't see where it touches the interrupt
>> state at all.
> Oha. Was this found on 2.6.32 or later?

Yeah, xen/next-2.6.32.

    J

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