Re: [BUG] Yet another scsi_cmnd leak?

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

Mike Christie wrote:
> 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 

I did not mean command as in struct scsi_cmnd command. I think only the 
scsi_request or REQ_BLOCK_PC code sets the end_io or waiting fields so I 
really meant request or scsi_request.

> again if it's request has a end_io function or waiting completion.
>