Re: SG_IO weirdness

[Douglas Gilbert <dougg@torque.net>]

Cameron, Steve wrote:
> I noticed that when I do two SG_IO ioctls to a target
> device (say, tape drive, disk drive, whatever) in which
> the first request is well formed (e.g. an inquiry) and the 
> second one has a malformed CDB, such that it gets check condition 
> with sense key == 5 (ILLEGAL REQUEST), the data buffer returned for 
> the second malformed SG_IO request is filled out with the same 
> data as was returned for the first successful command (e.g. the 
> same inquiry data again.)  I'm using separate data buffers for
> the two commands, and memsetting them to zero before calling
> ioctl().  I don't think this data is coming from the device,
> as it happens with every device I've tried.
> 
> Is that normal?  Seems like for a malformed request, the 
> data buffer should not be transferred at all, much less
> transferred with contents of a prior request's data buffer.
> 
> Kernel is 2.6.18 from kernel.org.

Steve,
Even though the SCSI status is CHECK CONDITION, the data-in
buffer may still be transferred. One obvious example
is a READ command when the sense key is RECOVERED ERROR.

The sg driver and I suspect the block layer SG_IO do
not check the SCSI status to determine whether or not
to transfer the data-in buffer (or where it would have
been DMA-ed to if the command worked) back to user space.
If it was _direct_ IO then the block layer SG_IO and the
sg driver would have no control over the data-in transfer
(apart from setting it up).

Both the sg driver and the block layer SG_IO could check
the resid field which a LLD should set after a DMA
(especially inbound). However LLDs are not compelled to
set resid properly.

So a few questions:
 - block layer SG_IO, the sg driver or both?
 - indirect IO (i.e. O_DIRECT not set)?
 - did the offending process have superuser permissions?
 - did the resid field indicate a short data-in transfer?

> The two requests were done from the same process, I haven't
> tried two separate processes to see if one process could
> by this method access another process's data.  I did try
> using two devices, so the first well formed command went 
> to one device, and the 2nd, malformed command went to another
> device.  In that case, I didn't get the same buffer back again,
> but garbage. (some recognizeable strings, "en_US" was in there...)
> 
> Is this a problem, or is this a matter of "just don't do that."?

As long as the SCSI status and sense buffer are conveyed
back properly _and_ this is only observed when the
process has superuser permissions, then I wouldn't
regard it as serious. Others may disagree.

Doug Gilbert