Re: [BUG] Yet another scsi_cmnd leak?

[Mike Christie <michaelc@cs.wisc.edu>]

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.