From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933271Ab1JRQ3p (ORCPT ); Tue, 18 Oct 2011 12:29:45 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:33782 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932353Ab1JRQ3o (ORCPT ); Tue, 18 Oct 2011 12:29:44 -0400 Subject: Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue()) From: James Bottomley To: Heiko Carstens Cc: "Jun'ichi Nomura" , Steffen Maier , "linux-scsi@vger.kernel.org" , Jens Axboe , Hannes Reinecke , Linux Kernel , Alan Stern , Thadeu Lima de Souza Cascardo , "Taraka R. Bodireddy" , "Seshagiri N. Ippili" , "Manvanthara B. Puttashankar" In-Reply-To: <20111018154542.GB3869@osiris.boeblingen.de.ibm.com> References: <1317183038.17578.9.camel@dabdike.hansenpartnership.com> <4E832A55.30709@kernel.dk> <1317219074.19034.4.camel@dabdike.hansenpartnership.com> <4E832BD2.50409@kernel.dk> <4E96E2FF.6070601@linux.vnet.ibm.com> <1318608184.3018.42.camel@dabdike.int.hansenpartnership.com> <4E9BEB68.1050707@ce.jp.nec.com> <1318860403.4794.12.camel@dabdike.int.hansenpartnership.com> <4E9D7FA8.9000000@ce.jp.nec.com> <20111018154542.GB3869@osiris.boeblingen.de.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 18 Oct 2011 11:29:40 -0500 Message-ID: <1318955380.5169.15.camel@dabdike.int.hansenpartnership.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2011-10-18 at 17:45 +0200, Heiko Carstens wrote: > On Tue, Oct 18, 2011 at 10:31:20PM +0900, Jun'ichi Nomura wrote: > > On 10/17/11 23:06, James Bottomley wrote: > > > On Mon, 2011-10-17 at 17:46 +0900, Jun'ichi Nomura wrote: > > >> On 10/15/11 01:03, James Bottomley wrote: > > >>> On Thu, 2011-10-13 at 15:09 +0200, Steffen Maier wrote: > > >>>> Initially, we encountered use-after-free bugs in > > >>>> scsi_print_command / scsi_dispatch_cmd > > >>>> http://marc.info/?l=linux-scsi&m=130824013229933&w=2 > > >> > > >> It is interesting that both this and the older report > > >> got oopsed in scsi_log_send(), while there are other > > >> dereferences of 'cmd' around scsi_dispatch_cmd(). > > >> Are there any reason they are special? Just by accident? > > > > > > Right, that's why it looks like the command area got freed rather than > > > the command pointer was bogus (6b is a poison free pattern). Perhaps if > > > the reporter could pin down the failing source line, we'd know better > > > what was going on? > > > > Yeah, that might be useful. > > The struct scsi_cmnd that was passed to scsi_log_send() was already freed > (contents completely 6b6b6b...). > Since SLUB debugging was turned on we can see that it was freed from > __scsi_put_command(). Not too much of a surprise. But it does tell us the put must be racing with dispatch, since dereferencing the command to find the device worked higher up in scsi_dispatch_cmd(). There is one way to invalidate the theory that we cloned something with an attached command, and that's to put BUG_ON(rq->special) in blk_insert_cloned_request(). I think we're careful about clearing it, so it should work (perhaps a warn on just in case). James