> 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. Yep, of course. > 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? sg driver. > - indirect IO (i.e. O_DIRECT not set)? indirect IO, O_DIRECT was not set. > - did the offending process have superuser permissions? Yes. > - did the resid field indicate a short data-in transfer? resid == 64, the requested buffer was 1088 bytes. (If I interpret that right, it means that all but 64 bytes were transferred, that is, 1024 bytes were transferred? Odd, considering the CDB was nonsense.) > 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. I haven't tried it as non-superuser. (And couldn't, unless I chmod'ed /dev/sg* ) -- steve - To unsubscribe from this list: 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
