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.
-
: 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
