On Wed, 19 Apr 2000, Douglas Gilbert wrote:
> The sg driver is between a rock and a hard place on this one.
>
> The sym/ncr53cxx drivers do nasty things on the PCI bus if the
> data_direction flag is wrong (crash??) but it will safely cope
> with SCSI_DATA_UNKNOWN. This was discussed in a linux-kernel thread
> titled: "2.3.00p1/2.3.49: more problems concerning devfs & generic
> scsi" [started 17th March 2000]. So sg was changed and now
> (2.3.99-pre5) the logic is:
> if (sg_header_interface)
> send SCSI_DATA_UNKNOWN is _all_ cases
> else if (sg_io_hdr_interface)
> send through direction flag indicated by user
My first instinct is that the sym/ncr53cxx drivers need fixing. But I
don't know if that is even possible. Perhaps an expert on those drivers
could comment better?
For the record, if the USB virtual HBA trusts the data_direction flag and
it's wrong, you won't do much harm. The commands will fail, and you might
have to invoke the bus reset routine to fix things, but no permanent harm
will be done. You probably won't even screw up the USB stack. Of course,
it won't work, either. :)
> All existing applications use the sg_header interface so USB will
> have problems as you have indicated. The danger with the sg_io_hdr
> interface is that the app gets the direction flag wrong and the
> above-mentioned drivers bring down the kernel.
Hrm... this seems to be saying that the sym/ncr53cxx drivers are really
still a problem. A user-level application can still bring the roof
crashing down on us if it just uses the sg_io_hdr_interface instead of the
standard sg_header interface. Or am I reading this wrong?
> Cdparanoia has the nasty habit of setting the buffer counts on
> sg_header to indicate data is both being written (i.e. transfer
> user data into the kernel buffers) and also read (i.e. transfer
> user data from the kernel buffers). [It does this "trick" so
> that on a read-like opcode it can detect a short read (with luck).]
> So with a vendor specific opcode and buffer counts indicating
> a bidirectional transfer, sg has no way of knowing the true
> data direction. [In defence of Monty (cdparanoia's author)
> I know he is keen to switch to the sg_io_hdr interface as
> soon as 2.4 becomes available.]
Well, that's good to know. However, it doesn't really solve the general
problem, which is that the Scsi_Cmnd structure can get to the HBA without
having a direction indicated.
> Now sg does know which HBA driver it is talking to and can
> change its direction reporting policy on that basis. That
> seems likely an ugly development to me. Also most anything
> that can be done with sg can also be done through the
> SCSI_IOCTL_SEND_COMMAND and CDROM_SEND_PACKET ioctl()s.
Ugh. Changing the reporting method really doesn't help much. That just
puts the table that maps command onto direction in a different place.
Tho it is a centralized place, which is probably a good thing.
> IMHO HBA drivers should react in a passive fashion when given
> an incorrect direction flag. If not then the pass through
> mechanisms have little option other than to send through
> the SCSI_DATA_UNKNOWN flag. Even when HBA drivers act benignly,
> if the pass through interfaces guess the data direction
> incorrectly (rather than pass through "UNKNOWN" in difficult
> cases) then a previously working app may be broken.
What do you mean by passive? To me, the correct behavior is "don't crash
or wedge the system in an unrecoverable state". The behavior I'd
implement in the USB driver would probably require a bus reset to be
invoked, but other than that, it should work fine. I think that's the
right behavior -- fail the command, perhaps require a reset to unwedge
things, but not crash.
Of course, I would rather see SCSI_DATA_UNKNOWN instead of a bad
direction. If I see SCSI_DATA_UNKNOWN, I can reject the command
immediately because I know I can't handle it.
Is that the best approach? Reject the command out of hand if I see
SCSI_DATA_UNKNOWN? I think that does the right thing in the end -- older
applications can't fubar the system, and newer applications which do
things right will work just fine.
Comments?
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
You should try to see the techs say "three piece suit".
-- The Chief
User Friendly, 11/23/1997
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
