From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH] blkfront: Move blkif_interrupt into a tasklet. Date: Wed, 08 Sep 2010 16:37:02 +1000 Message-ID: <4C872F0E.5010809@goop.org> References: <1282546470-5547-1-git-send-email-daniel.stodden@citrix.com> <1282546470-5547-2-git-send-email-daniel.stodden@citrix.com> <4C802934.2000305@goop.org> <1283468932.3092.3924.camel@ramone.somacoma.net> <4C86EED5.1070807@goop.org> <1283912499.3138.170.camel@agari.van.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1283912499.3138.170.camel@agari.van.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Daniel Stodden Cc: Xen , Tom Kopec List-Id: xen-devel@lists.xenproject.org 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