SG_IO open flags are which

SG_IO open flags are which

[Pat LaVarre]

Doug G:

What open flags should apps use to talk SG_IO?

O_RDWR?  O_RDONLY?  O_NONBLOCK?  Other?  Combination?

Wrong info in Google includes:

> List: linux-scsi
> Date: 2003-12-03 0:17:56
> Re: sg utils sg_io -i 0x24 -y "12 00:00:00 24 00"
> ...
> > > - O_RDWR
> > > + O_RDONLY|O_NONBLOCK
> > ... not from reading a document anywhere ...
> ...
> Possibly we recommend open O_NONBLOCK for SG_IO ...
> Evidence in favour ... includes ...
> From: linux-2.6.0-test11/Documentation/cdrom/cdrom-standard.tex
> ...
> 1997/12/28 ... propose ... $O_NONBLOCK$ to indicate
> that the device is opened just for issuing $ioctl$
> commands.

Wrong guess, if we try 2.6.0-test11 with the three commands:

-i x24 -y "12 00:00:00 24 00" // standard Inquiry
-y "1B 00:00:00 00 00" // Stop Unit
-y "1B 00:00:00 01 00" // Start Unit

Either open O_NONBLOCK or open O_RDWR allows pass thru of standard
Inquiry.  And open O_RDWR allows pass thru of Stop Unit.  But open
O_NONBLOCK rejects pass thru of Stop Unit:

$ sudo plscsi /dev/sg0 -x "1B 00:00:00 00 00"
...
$ grep -i 'Operation not permitted' /usr/include/asm/errno.h
#define EPERM            1      /* Operation not permitted */
$

Perhaps lk has no open that allows all of SG_IO without closing trays,
spinning up discs, etc.?  If we do face that limit, then often we can
settle for O_NONBLOCK to list device names (e.g. sg_scan) and O_RDWR
otherwise (e.g. sg_dd).

Wish I knew where in the lk source we're choosing to have the privilege
of the open vary the transparency of the pass thru.

Pat LaVarre

Re: SG_IO open flags are which

[Douglas Gilbert]

Pat LaVarre wrote:
> Doug G:
> 
> What open flags should apps use to talk SG_IO?
> 
> O_RDWR?  O_RDONLY?  O_NONBLOCK?  Other?  Combination?
> 
> Wrong info in Google includes:
> 
> 
>>List: linux-scsi
>>Date: 2003-12-03 0:17:56
>>Re: sg utils sg_io -i 0x24 -y "12 00:00:00 24 00"
>>...
>>
>>>>- O_RDWR
>>>>+ O_RDONLY|O_NONBLOCK
>>>
>>>... not from reading a document anywhere ...
>>
>>...
>>Possibly we recommend open O_NONBLOCK for SG_IO ...
>>Evidence in favour ... includes ...
>>From: linux-2.6.0-test11/Documentation/cdrom/cdrom-standard.tex
>>...
>>1997/12/28 ... propose ... $O_NONBLOCK$ to indicate
>>that the device is opened just for issuing $ioctl$
>>commands.
> 
> 
> Wrong guess, if we try 2.6.0-test11 with the three commands:
> 
> -i x24 -y "12 00:00:00 24 00" // standard Inquiry
> -y "1B 00:00:00 00 00" // Stop Unit
> -y "1B 00:00:00 01 00" // Start Unit
> 
> Either open O_NONBLOCK or open O_RDWR allows pass thru of standard
> Inquiry.  And open O_RDWR allows pass thru of Stop Unit.  But open
> O_NONBLOCK rejects pass thru of Stop Unit:
> 
> $ sudo plscsi /dev/sg0 -x "1B 00:00:00 00 00"
> ...
> $ grep -i 'Operation not permitted' /usr/include/asm/errno.h
> #define EPERM            1      /* Operation not permitted */
> $
> 
> Perhaps lk has no open that allows all of SG_IO without closing trays,
> spinning up discs, etc.?  If we do face that limit, then often we can
> settle for O_NONBLOCK to list device names (e.g. sg_scan) and O_RDWR
> otherwise (e.g. sg_dd).
> 
> Wish I knew where in the lk source we're choosing to have the privilege
> of the open vary the transparency of the pass thru.

Pat,
The implementation of open() is found in the driver that "owns"
the device name (e.g. /dev/hdc or /dev/st0m). The same is true
for ioctl() [and read()/write() for char devices].

Therefore the exact action of the O_NONBLOCK flag given to
an open() differs. Broadly speaking the interpretation is the
same: "let me in". For drivers that often encounter removable
media, a simple open() will fail if no media is present
(e.g. st yields EIO while sr/ide-cd yield ENOMEDIUM). In the
case of sg it won't wait for the O_EXCL lock to clear (rather
it yields EBUSY) and sidesteps error processing waits which is
arguably risky. For pass through purposes you should set O_NONBLOCK
as it can't hurt (e.g. sd ignores it and yields ENOMEDIUM if there
is no media (which looks wrong)).

Unix/Linux will only allow a non-root user to open() a file O_RDWR
that they have "rw" permissions for (so individual drivers have no
control over that). The "w" permissions is needed to call write()
but not to call ioctl(). Historically the sg driver output metadata
(including the SCSI command) with a write() and got the results with
a read(). That meant "rw" permissions and O_RDWR were needed. Then
the SG_IO ioctl came along in lk 2.4. The sg driver will only allow
the following SCSI commands through if the file was opened O_RDONLY:
   TEST_UNIT_READY
   REQUEST_SENSE
   INQUIRY
   READ_CAPACITY
   READ_BUFFER
   READ_6
   READ_10
   READ_12
   MODE_SENSE
   MODE_SENSE_10
   LOG_SENSE

Perhaps READ_16, SERVICE_IN and MAINTENANCE_IN should be added
to that list. The idea is to inhibit changing the state of
a device when it is opened O_RDONLY. START_STOP is definitely
_not_ on the list. The SG_IO ioctl() found in block/scsi_ioctl.c
does not have this restriction so you can issue any SCSI
commands when /dev/sda, for example, is opened O_RDONLY.

So first try and open() with the (O_NONBLOCK | O_RDWR) flags.
If that yields ENOMEDIUM look for the corresponding sg
device name. If the initial open() yields EROFS or EACESS then
try to open it (O_NONBLOCK | O_RDONLY). ...

Confused enough yet :-)

Doug Gilbert

Re: SG_IO open flags are which

[Jens Axboe]

On Thu, Dec 18 2003, Douglas Gilbert wrote:
> the SG_IO ioctl came along in lk 2.4. The sg driver will only allow
> the following SCSI commands through if the file was opened O_RDONLY:
>   TEST_UNIT_READY
>   REQUEST_SENSE
>   INQUIRY
>   READ_CAPACITY
>   READ_BUFFER
>   READ_6
>   READ_10
>   READ_12
>   MODE_SENSE
>   MODE_SENSE_10
>   LOG_SENSE

I think that's bogus to attempt to put such vague restrictions on what
you can do with the open device. What purpose does it serve?!

> _not_ on the list. The SG_IO ioctl() found in block/scsi_ioctl.c
> does not have this restriction so you can issue any SCSI
> commands when /dev/sda, for example, is opened O_RDONLY.

Thankfully, and that's quite on purpose.

-- 
Jens Axboe

Re: SG_IO open flags are which

[Pat LaVarre]

Doug G:

> > Re: SG_IO open flags are which
> > http://marc.theaimsgroup.com/?t=107150658300002
> > ...
> > So first try and open() with the (O_NONBLOCK
> > | O_RDWR) flags.  If that yields ENOMEDIUM
> > look for the corresponding sg device name.
> > If the initial open() yields EROFS or EACESS
> > then try to open it (O_NONBLOCK | O_RDONLY).
> > ...

Clear workarounds for three possible results, yes, thank you.

Naturally I fear uncertainly and doubt the effects of defaulting to
O_RDWR or O_RDONLY.

> > Confused enough yet :-)

I can confirm ioctl SG_IO op x2A, in Linux-2.6.5, passes:

thru open O_NONBLOCK of mountable /dev/scd$n, and
thru open (O_NONBLOCK | O_RDWR) of unmountable /dev/sg$n, but
NOT thru open O_NONBLOCK of unmountable /dev/sg$n.

I get these same results no matter disc absent or present.

Next steps may include:

a) Contrast PDT x05 ioctl CDROM_SEND_PACKET with ioctl SG_IO.

b) Trace when open/ close implies op x1E "PREVENT" "ALLOW" around ioctl,
even ioctl of op x1B "START" "STOP" Eject.

Pat LaVarre

Re: SG_IO open flags are which

[Pat LaVarre]

Recently I saw yet another newbie trip over the ioctl 
CDROM_SEND_PACKET/ SG_IO dialectic that:

1) open /dev/scd$n /dev/hd$v maybe inflict less undesirable side 
effects if we open O_NONBLOCK

2) open /dev/sg$n maybe inflict less undesirable side effects if we 
open O_RDWR | O_NONBLOCK

I'm replying again in this thread only because I don't remember before 
now seeing that dialectic nutshelled so pointedly.

Looks like ioctl SCSI pass thru apps should string-compare the device 
name to decide default open flags.  Over the years, that's potentially 
insanely fragile, but I guess it will work out ok for Linux 2.6/ 2.4.

Pat LaVarre