Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 24 Jul 2002 10:17:03 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 24 Jul 2002 10:17:02 -0400 Received: from ns.virtualhost.dk ([195.184.98.160]:56716 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id ; Wed, 24 Jul 2002 10:16:58 -0400 Date: Wed, 24 Jul 2002 16:19:54 +0200 From: Jens Axboe To: martin@dalecki.de Cc: Bartlomiej Zolnierkiewicz , Adam Kropelin , linux-kernel@vger.kernel.org Subject: Re: cpqarray broken since 2.5.19 Message-ID: <20020724141954.GF5159@suse.de> References: <3D3EB576.1040601@evision.ag> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D3EB576.1040601@evision.ag> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 933 Lines: 25 On Wed, Jul 24 2002, Marcin Dalecki wrote: > > > > >Jens, the same is in cciss.c. > >Please remove locking from blk_stop_queue() (as you suggested) or intrduce > >unlocking in request_functions. > > > Bartek I think the removal is just for reassertion that the > locking is the problem. You can't remove it easly from > blk_stop_queue() unless you make it mandatory that blk_stop_queue > has to be run with the lock already held. Or in other words > basically -> Don't use blk_stop_queue() outside of ->request_fn. Of couse Bart is advocating just making sure that every caller of blk_stop_queue() _has_ the queue_lock before calling it, not removing the locking there. -- Jens Axboe - 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/