From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Christie Subject: Re: [BUG] Yet another scsi_cmnd leak? Date: Thu, 29 Sep 2005 15:28:42 -0500 Message-ID: <433C4E7A.7010205@cs.wisc.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from sabe.cs.wisc.edu ([128.105.6.20]:35743 "EHLO sabe.cs.wisc.edu") by vger.kernel.org with ESMTP id S964885AbVI2U2v (ORCPT ); Thu, 29 Sep 2005 16:28:51 -0400 In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Alan Stern Cc: James Bottomley , SCSI development list Alan Stern wrote: > James: > > This report is based on 2.6.14-rc2-git6. The code in your scsi-misc-2.6 > git tree is somewhat different (and I don't know which is more current), > but it still contains the same bug. > > > In scsi_prep_fn, a request can get deferred if scsi_init_io fails to > allocate an sg table. When this happens, the scsi_cmnd isn't released and > the request is not marked DONTPREP. > > Then when scsi_prep_fn is called again, the request may be killed for > a number of reasons. The code branches to the kill: label near the end of > the routine, which returns BLKPREP_KILL. > > Isn't it true that when this happens, the scsi_cmnd allocated during the > original prep will never be released? > > It appears that scsi_prep_fn is undecided about whether or not the request > is allowed to have a scsi_cmnd already. The jumps to kill: seem to assume > that it isn't, but the code for allocating a new scsi_cmnd tests for an > existing one first. > The gotos used to be just a return BLKPREP* and were added so I did not have to write DID_NO_CONNECT or unplug multiple times :) I think you are right and we need to further unwind what a previous prep had done becuase when we return with BLKPREP_KILL we only hear about this command again if it's request has a end_io function or waiting completion.