Questions about proc_scsi_write() in scsi_proc.c

Questions about proc_scsi_write() in scsi_proc.c

[Rob Landley]

I don't understanding this code:

1) for echo "scsi add-single-device 0 1 2 3" > /proc/scsi/scsi, is this only 
for parallel scsi?  I thought most modern busses (usb, sata, FC, firewire, 
etc) dynamically assign these numbers and just use them as a unique 
identifier ala kdev_t.  How would this work on one of the other devices?

2) How do you trigger this?  /proc/scsi/scsi is read only even for root.

3) This bit is repeated in both the add and remove logic:
                p = buffer + 23;

                host = simple_strtoul(p, &p, 0);
                channel = simple_strtoul(p + 1, &p, 0);
                id = simple_strtoul(p + 1, &p, 0);
                lun = simple_strtoul(p + 1, &p, 0);

So what happens if you echo "scsi add-single-device 0" > /proc/scsi/scsi (or 
wherever file would trigger this function) so the read for channel skips over 
the null terminator (I'm assuming there is one) and reads who knows what?  Or 
what if instead of ending that with one 0, you end it with enough zeroes to 
pad right up to PAGE_SIZE, so it reads the next page?  (I don't even know 
what the page protections are on that, depends how 
__get_free_page(GFP_KERNEL) works...)

Confused,

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: Questions about proc_scsi_write() in scsi_proc.c

[James Bottomley]

On Fri, 2007-10-26 at 15:07 -0500, Rob Landley wrote:
> I don't understanding this code:
> 
> 1) for echo "scsi add-single-device 0 1 2 3" > /proc/scsi/scsi, is this only 
> for parallel scsi? 

No.

>  I thought most modern busses (usb, sata, FC, firewire, 
> etc) dynamically assign these numbers and just use them as a unique 
> identifier ala kdev_t.  How would this work on one of the other devices?

It's most often used to add or remove LUNs.

> 2) How do you trigger this?  /proc/scsi/scsi is read only even for root.

root can still write to it.

> 3) This bit is repeated in both the add and remove logic:
>                 p = buffer + 23;
> 
>                 host = simple_strtoul(p, &p, 0);
>                 channel = simple_strtoul(p + 1, &p, 0);
>                 id = simple_strtoul(p + 1, &p, 0);
>                 lun = simple_strtoul(p + 1, &p, 0);
> 
> So what happens if you echo "scsi add-single-device 0" > /proc/scsi/scsi (or 
> wherever file would trigger this function) so the read for channel skips over 
> the null terminator (I'm assuming there is one) and reads who knows what?  Or 
> what if instead of ending that with one 0, you end it with enough zeroes to 
> pad right up to PAGE_SIZE, so it reads the next page?  (I don't even know 
> what the page protections are on that, depends how 
> __get_free_page(GFP_KERNEL) works...)
> 
> Confused,

It's relying on the user buffer being zero padded, but even if it isn't,
there's not much that can go wrong.  It's also a deprecated interface.

James

Re: Questions about proc_scsi_write() in scsi_proc.c

[Rob Landley]

On Friday 26 October 2007 4:09:37 pm James Bottomley wrote:
> On Fri, 2007-10-26 at 15:07 -0500, Rob Landley wrote:
> > I don't understanding this code:
> >
> > 1) for echo "scsi add-single-device 0 1 2 3" > /proc/scsi/scsi, is this
> > only for parallel scsi?
>
> No.
>
> >  I thought most modern busses (usb, sata, FC, firewire,
> > etc) dynamically assign these numbers and just use them as a unique
> > identifier ala kdev_t.  How would this work on one of the other devices?
>
> It's most often used to add or remove LUNs.

Ok, I'm unclear on what a LUN is.  All the devices I have lying around give me 
a LUN of zero.  I used to think that a LUN was a bit like partition, and 
mostly used for CD changes.  The structure "scsi_target" seems to aggregate 
host/channel/target and I thought it referred to a device.

The earlier email between you, me, and Stefan, and myself said:

James Bottomley said:
> Stephan Richter said:
> > "lun" is a target-wide unique number to address a logical unit on a
> > target device.  Its format is also a priori defined by the Linux SCSI
> > low-level API.

I think I understand that bit

> > It is possible to transform "Logical Unit Identifiers" 
> > a.k.a. "Logical Unit Numbers" a.k.a. "LUNs" (which are either 8 bytes
> > wide or 2 bytes wide) into the format of the lun.  (Logical Unit
> > Identifier is a property of all logical units of SCSI target devices.)

This is something totally different, and seems a bit like a MAC address?

> > The SCSI Architecture Model defines several different subspecies of 8
> > bytes wide LUNs.  Some of these variants cannot be transformed lossless
> > into the SCSI core's lun, but it appears that such variants of LUNs are
> > not used in real hardware.
>
> Right, LUN has a specific transport independent meaning defined in SAM-3
> or SAM-4:
>
> http://www.t10.org/ftp/t10/drafts/sam3/sam3r14.pdf
> http://www.t10.org/ftp/t10/drafts/sam4/sam4r13.pdf

Unfortunately those two documents are 127 pages and 148 pages, respectively, 
and I haven't had a chance to make any headway in them yet.

Every device I have that shows up as SCSI has shown up with a LUN of 0, which 
is target-wide unique because none of those targets have sub-functions that 
need to be independently addressed as devices.

Is there an easy way to distinguish between "target-wide unique lun" and this 
Logical Unit Number device attribute that's either 8 bytes or 2 bytes wide?  
(Capitalization?)

> > 2) How do you trigger this?  /proc/scsi/scsi is read only even for root.
>
> root can still write to it.

Wow.  (Is this an idiosyncrasy of /proc, or a capability of root I've been 
unaware of all this time?)

> > 3) This bit is repeated in both the add and remove logic:
> >                 p = buffer + 23;
> >
> >                 host = simple_strtoul(p, &p, 0);
> >                 channel = simple_strtoul(p + 1, &p, 0);
> >                 id = simple_strtoul(p + 1, &p, 0);
> >                 lun = simple_strtoul(p + 1, &p, 0);
> >
> > So what happens if you echo "scsi add-single-device 0" > /proc/scsi/scsi
> > (or wherever file would trigger this function) so the read for channel
> > skips over the null terminator (I'm assuming there is one) and reads who
> > knows what?  Or what if instead of ending that with one 0, you end it
> > with enough zeroes to pad right up to PAGE_SIZE, so it reads the next
> > page?  (I don't even know what the page protections are on that, depends
> > how
> > __get_free_page(GFP_KERNEL) works...)
> >
> > Confused,
>
> It's relying on the user buffer being zero padded, but even if it isn't,
> there's not much that can go wrong.  It's also a deprecated interface.

Where do I find out what interfaces are deprecated?  (Is this written down 
somewhere?  Or do you just mean that the whole of /proc is moving to /sys 
where possible?)

> James

Thanks (still confused),

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Questions about proc_scsi_write() in scsi_proc.c

[James Bottomley]

On Fri, 2007-10-26 at 17:29 -0500, Rob Landley wrote:
> On Friday 26 October 2007 4:09:37 pm James Bottomley wrote:
> > On Fri, 2007-10-26 at 15:07 -0500, Rob Landley wrote:
> > > I don't understanding this code:
> > >
> > > 1) for echo "scsi add-single-device 0 1 2 3" > /proc/scsi/scsi, is this
> > > only for parallel scsi?
> >
> > No.
> >
> > >  I thought most modern busses (usb, sata, FC, firewire,
> > > etc) dynamically assign these numbers and just use them as a unique
> > > identifier ala kdev_t.  How would this work on one of the other devices?
> >
> > It's most often used to add or remove LUNs.
> 
> Ok, I'm unclear on what a LUN is.  All the devices I have lying around give me 
> a LUN of zero.  I used to think that a LUN was a bit like partition, and 
> mostly used for CD changes.  The structure "scsi_target" seems to aggregate 
> host/channel/target and I thought it referred to a device.
> 
> The earlier email between you, me, and Stefan, and myself said:
> 
> James Bottomley said:
> > Stephan Richter said:
> > > "lun" is a target-wide unique number to address a logical unit on a
> > > target device.  Its format is also a priori defined by the Linux SCSI
> > > low-level API.
> 
> I think I understand that bit
> 
> > > It is possible to transform "Logical Unit Identifiers" 
> > > a.k.a. "Logical Unit Numbers" a.k.a. "LUNs" (which are either 8 bytes
> > > wide or 2 bytes wide) into the format of the lun.  (Logical Unit
> > > Identifier is a property of all logical units of SCSI target devices.)
> 
> This is something totally different, and seems a bit like a MAC address?
> 
> > > The SCSI Architecture Model defines several different subspecies of 8
> > > bytes wide LUNs.  Some of these variants cannot be transformed lossless
> > > into the SCSI core's lun, but it appears that such variants of LUNs are
> > > not used in real hardware.
> >
> > Right, LUN has a specific transport independent meaning defined in SAM-3
> > or SAM-4:
> >
> > http://www.t10.org/ftp/t10/drafts/sam3/sam3r14.pdf
> > http://www.t10.org/ftp/t10/drafts/sam4/sam4r13.pdf
> 
> Unfortunately those two documents are 127 pages and 148 pages, respectively, 
> and I haven't had a chance to make any headway in them yet.
> 
> Every device I have that shows up as SCSI has shown up with a LUN of 0, which 
> is target-wide unique because none of those targets have sub-functions that 
> need to be independently addressed as devices.
> 
> Is there an easy way to distinguish between "target-wide unique lun" and this 
> Logical Unit Number device attribute that's either 8 bytes or 2 bytes wide?  
> (Capitalization?)

They both have a section called " Definitions, symbols, abbreviations,
and conventions"; you'll find LUN (and LU) defined in there.

> > > 2) How do you trigger this?  /proc/scsi/scsi is read only even for root.
> >
> > root can still write to it.
> 
> Wow.  (Is this an idiosyncrasy of /proc, or a capability of root I've been 
> unaware of all this time?)
> 
> > > 3) This bit is repeated in both the add and remove logic:
> > >                 p = buffer + 23;
> > >
> > >                 host = simple_strtoul(p, &p, 0);
> > >                 channel = simple_strtoul(p + 1, &p, 0);
> > >                 id = simple_strtoul(p + 1, &p, 0);
> > >                 lun = simple_strtoul(p + 1, &p, 0);
> > >
> > > So what happens if you echo "scsi add-single-device 0" > /proc/scsi/scsi
> > > (or wherever file would trigger this function) so the read for channel
> > > skips over the null terminator (I'm assuming there is one) and reads who
> > > knows what?  Or what if instead of ending that with one 0, you end it
> > > with enough zeroes to pad right up to PAGE_SIZE, so it reads the next
> > > page?  (I don't even know what the page protections are on that, depends
> > > how
> > > __get_free_page(GFP_KERNEL) works...)
> > >
> > > Confused,
> >
> > It's relying on the user buffer being zero padded, but even if it isn't,
> > there's not much that can go wrong.  It's also a deprecated interface.
> 
> Where do I find out what interfaces are deprecated?  (Is this written down 
> somewhere?  Or do you just mean that the whole of /proc is moving to /sys 
> where possible?)

It's part of the general deprecating proc except for process files
edict.

James

Re: Questions about proc_scsi_write() in scsi_proc.c

[Rob Landley]

On Friday 26 October 2007 5:47:57 pm James Bottomley wrote:
> > > http://www.t10.org/ftp/t10/drafts/sam3/sam3r14.pdf
> > > http://www.t10.org/ftp/t10/drafts/sam4/sam4r13.pdf
> >
> > Unfortunately those two documents are 127 pages and 148 pages,
> > respectively, and I haven't had a chance to make any headway in them yet.
> >
> > Every device I have that shows up as SCSI has shown up with a LUN of 0,
> > which is target-wide unique because none of those targets have
> > sub-functions that need to be independently addressed as devices.
> >
> > Is there an easy way to distinguish between "target-wide unique lun" and
> > this Logical Unit Number device attribute that's either 8 bytes or 2
> > bytes wide? (Capitalization?)
>
> They both have a section called " Definitions, symbols, abbreviations,
> and conventions"; you'll find LUN (and LU) defined in there.

Page 23 of the PDF:

  3.1.64 Logical Unit Number (LUN): A 64-bit or 16-bit identifier for a 
logical unit.  See 4.9



> > > > 2) How do you trigger this?  /proc/scsi/scsi is read only even for
> > > > root.
> > >
> > > root can still write to it.
> >
> > Wow.  (Is this an idiosyncrasy of /proc, or a capability of root I've
> > been unaware of all this time?)
> >
> > > > 3) This bit is repeated in both the add and remove logic:
> > > >                 p = buffer + 23;
> > > >
> > > >                 host = simple_strtoul(p, &p, 0);
> > > >                 channel = simple_strtoul(p + 1, &p, 0);
> > > >                 id = simple_strtoul(p + 1, &p, 0);
> > > >                 lun = simple_strtoul(p + 1, &p, 0);
> > > >
> > > > So what happens if you echo "scsi add-single-device 0" >
> > > > /proc/scsi/scsi (or wherever file would trigger this function) so the
> > > > read for channel skips over the null terminator (I'm assuming there
> > > > is one) and reads who knows what?  Or what if instead of ending that
> > > > with one 0, you end it with enough zeroes to pad right up to
> > > > PAGE_SIZE, so it reads the next page?  (I don't even know what the
> > > > page protections are on that, depends how
> > > > __get_free_page(GFP_KERNEL) works...)
> > > >
> > > > Confused,
> > >
> > > It's relying on the user buffer being zero padded, but even if it
> > > isn't, there's not much that can go wrong.  It's also a deprecated
> > > interface.
> >
> > Where do I find out what interfaces are deprecated?  (Is this written
> > down somewhere?  Or do you just mean that the whole of /proc is moving to
> > /sys where possible?)
>
> It's part of the general deprecating proc except for process files
> edict.
>
> James



-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: Questions about proc_scsi_write() in scsi_proc.c

[Matthew Wilcox]

On Fri, Oct 26, 2007 at 05:29:53PM -0500, Rob Landley wrote:
> Ok, I'm unclear on what a LUN is.  All the devices I have lying around give me 
> a LUN of zero.  I used to think that a LUN was a bit like partition, and 
> mostly used for CD changes.  The structure "scsi_target" seems to aggregate 
> host/channel/target and I thought it referred to a device.

Maybe the best way to understand this is by analogy with PCI.  With PCI,
you have a 5-bit device id and a 3-bit function ID.  Most physical
devices implement only one function, but we create a pci_dev for every
implemented function.  I'm not sure how many bits we have for target and
lun in SCSI, but it works much the same way; the target is the physical
thing, and the LUN is a logical entity within that hunk of hardware.  We
create a scsi_device for each LUN.

> Every device I have that shows up as SCSI has shown up with a LUN of 0, which 
> is target-wide unique because none of those targets have sub-functions that 
> need to be independently addressed as devices.

I have two devices with multiple LUNs.  One is a Plasmon PD-2000 combo
CD-reader and optical-disc.  If you put a CD-ROM in it, that's LUN 0
(sr) and if you put an optical disc in it, that shows up on LUN 1 (sd).

The other device is an HP fibre-channel Virtual Array which is a 3U
piece of metal with up to 15 drives inside it.  It splits those discs
up into as many LUNs as you configure it to, at whatever RAID level you
configure it to, and (in my configuration) presents itself as a single
target with 128 LUNs.

Not all storage arrays behave like that; I have another HP array that
presents each disc within it as an individual target, and the controller
is another target (it shows up as a PROCESSOR device).  In this scenario,
you only have LUN 0 on each target.

I'm sure there are plenty of other examples, but hopefully this will
help.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."