Doug Ledford wrote:
Don't use cmd->request->nr_hw_segments as it may not be initialized
(SG_IO in particular bypasses anything that initializes this and just
uses scsi_do_req to insert a scsi_request directly on the head of the
queue) and a bogus value here can trip up the checks to make sure that
the number of segments will fit in the queue ring buffer, resulting in
commands that are never completed.
Doug,
Which SG_IO code path (via the block layer or the sg driver)
does this happen on?
Looking at the sg driver code, it calls scsi_allocate_request()
prior to calling scsi_do_req(). scsi_allocate _request()
allocates a block of memory starting with a scsi_request
instance followed by a struct request instance; then zeroes the
whole block, etc. nr_hw_segments is a member of struct request.
I would expect that is the same struct request instance that
the LLD ends up seeing. Zero may not be an ideal value but
at least it is not random.
It is not as clear to me what is happening in this regard
when the SG_IO ioctl is used in the block layer. If the
problem is in that path then perhaps a "rq->nr_hw_segment = 0;"
could be placed in block/scsi_ioctl.c::sg_io() to make it
consistent (i.e. zero) with the sg driver path.
If zero in request::nr_hw_segment is invalid, the perhaps
scsi_do_req() could adjust it to something sensible
(sg_tablesize ??).
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
