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.
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
