Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262468AbVDGNWb (ORCPT ); Thu, 7 Apr 2005 09:22:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262464AbVDGNWa (ORCPT ); Thu, 7 Apr 2005 09:22:30 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:25473 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S262462AbVDGNWN (ORCPT ); Thu, 7 Apr 2005 09:22:13 -0400 Date: Thu, 7 Apr 2005 14:22:05 +0100 From: Christoph Hellwig To: James Bottomley Cc: Jens Axboe , Chris Rankin , Linux Kernel , SCSI Mailing List Subject: Re: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler Message-ID: <20050407132205.GA16517@infradead.org> Mail-Followup-To: Christoph Hellwig , James Bottomley , Jens Axboe , Chris Rankin , Linux Kernel , SCSI Mailing List References: <20050329115405.97559.qmail@web52909.mail.yahoo.com> <20050329120311.GO16636@suse.de> <1112804840.5476.16.camel@mulgrave> <20050406175838.GC15165@suse.de> <1112811607.5555.15.camel@mulgrave> <20050406190838.GE15165@suse.de> <1112821799.5850.19.camel@mulgrave> <20050407064934.GJ15165@suse.de> <1112879919.5842.3.camel@mulgrave> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112879919.5842.3.camel@mulgrave> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1710 Lines: 35 On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote: > On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote: > > On Wed, Apr 06 2005, James Bottomley wrote: > > > My proposal is to correct this by moving the data back to the correct > > > object, and make any object using it hold a reference, so this would > > > make the provider of the block request_fn hold a reference to the queue > > > and initialise the queue lock pointer with the lock currently in the > > > queue. Drivers that still use a global lock would be unaffected. This > > > > But this is the current requirement, as long as you use the queue you > > must hold a reference to it. > > Exactly! that's why I think this solution must work independently of > subsystem. > > > What do you think of the attached, then? Allow NULL lock to be passed > > in, in which case we use the queue private lock (that no one should ever > > ever touch). It looks a little confusing that > > sdev->request_queue->queue_lock now protects some sdev structures, if > > you want we can retain ->sdev_lock but as a pointer to the queue lock > > instead. > > Looks good. How about the attached modification? It makes sdev_lock a > pointer that uses the queue lock which we null out when we release it > (not that I don't trust SCSI or anything ;-) Do we really need the sdev_lock pointer? There's just a single place where we're using it and the code would be much more clear if it had just one name. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/