> The SCSI core has a problem with leakage of scsi_cmnd structs. It occurs > when a request is requeued; the request keeps its associated scsi_cmnd so > that the core doesn't need to assign a new one. However, the routines > that read the device queue sometimes delete entries without bothering to > free the associated scsi_cmnd. Among other things, this bug manifests as > error-handler processes remaining alive when a hot-pluggable device is > unplugged in the middle of executing a command. > > This patch (as559) fixes the problem by calling scsi_put_command and > scsi_release_buffers at the appropriate times. It also reorganizes a > couple of bits of code, adding a new subroutine to find the scsi_cmnd > associated with a requeued request. Nate Dailey also had a patch for this, a reply to which is incomplete still in my drafts folder. The bottom line is that I don't think any modifications to the prep_fn() are necessary. It's guarded by REQ_DONTPREP, so is never called again if we actually manage to prepare a command fully. The returns from it are: BLKPREP_DEFER: Requeue the command for re-preparation (no resources should be allocated) BLKPREP_KILL: destroy the command (no resources should be allocated) BLKPREP_OK: Command is prepared, resources are allocated, REQ_DONTPREP is set to prevent any additional prep_fn() call. So in the DEFER or KILL case, all you need to worry about is resources you may have allocated in the current prep_fn() invocation. It seems to me that we do release these correctly, unless I'm missing something? The second problem is a bug (also spotted by Nate). However, what I think we should be doing in this case is calling __scsi_done with DID_NO_CONNECT which should clean up correctly and also send the error indications back up the stack to the correct sources (that's what we do in scsi_dispatch_cmd() for this problem). James - : 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
