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 12:03:01 +1000 Message-ID: <4C86EED5.1070807@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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1283468932.3092.3924.camel@ramone.somacoma.net> 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/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. J