From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: possible use-after-free in 2.5.44 scsi changes Date: Sat, 26 Oct 2002 11:29:43 +0200 Sender: linux-scsi-owner@vger.kernel.org Message-ID: <20021026092943.GB14976@suse.de> References: <200210252223.g9PMN9a17551@eng2.beaverton.ibm.com> <200210260013.g9Q0DP105454@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <200210260013.g9Q0DP105454@localhost.localdomain> List-Id: linux-scsi@vger.kernel.org To: James Bottomley Cc: Badari Pulavarty , Andrew Morton , "linux-scsi@vger.kernel.org" , "Martin J. Bligh" , Doug Ledford On Fri, Oct 25 2002, James Bottomley wrote: > pbadari@us.ibm.com said: > > I Just tried the patch. No Luck. I get same panic as before... I am > > using qla2x00src-v6.03.00b6 driver on qla2200 fc controllers. > > Well, yours may be a qla bug. > > However, I've tracked down my hang problem: If a command is pushed back into > the block queue as a REQ_SPECIAL using the blk_insert_request() API, it never > has REQ_CMD cleared. Eventually it comes back into scsi_request_fn() with > both REQ_CMD and REQ_SPECIAL set. This causes the I/O to be initialised again. > > The fix is to clear REQ_CMD in blk_insert_request(). Irk no, you cannot just clear valid information! This is _not_ a fix, it's a hack. Use a different flag, or maybe use REQ_DONTPREP or similar. -- Jens Axboe