Skip to contentSkip to conversation

Questions about proc_scsi_write() in scsi_proc.c

DISCUSSION Rob Landley 3 participants 6 messages Oct 26, 2007 – Oct 27, 2007 SCSI

lore
Share & tools
lore
#0 lore raw

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

Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
#1 lore raw
Quoted 4 lines · 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?

No.

Quoted 3 lines

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.

Quoted 1 line

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

root can still write to it.

Quoted 16 lines

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...)

Quoted 1 line

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

#2 lore raw
Quoted 6 lines · James Bottomley
Quoted 4 lines · 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?

Quoted 7 lines

No.

Quoted 3 lines

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:

Quoted 4 lines · James Bottomley
Quoted 3 lines · Stephan Richter

"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

Quoted 4 lines
Quoted 4 lines

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?

Quoted 10 lines
Quoted 4 lines

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?)

Quoted 3 lines
Quoted 1 line

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?)

Quoted 17 lines
Quoted 17 lines

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...)

Quoted 4 lines
Quoted 1 line

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?)

Quoted 1 line

James

Thanks (still confused),

Rob

Signature · 6 lines
"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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#3 lore raw
Quoted 51 lines · Rob Landley
Quoted 6 lines · James Bottomley
Quoted 4 lines · 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?

Quoted 7 lines

No.

Quoted 3 lines

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:

Quoted 4 lines · James Bottomley
Quoted 3 lines · Stephan Richter

"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

Quoted 4 lines
Quoted 4 lines

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?

Quoted 10 lines
Quoted 4 lines

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.

Quoted 7 lines

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.

Quoted 24 lines
Quoted 3 lines
Quoted 1 line

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?)

Quoted 17 lines
Quoted 17 lines

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...)

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

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

#4 lore raw
Quoted 10 lines · James Bottomley
Quoted 10 lines
Quoted 2 lines

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.

Quoted 6 lines
Quoted 3 lines

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

Quoted 39 lines
Quoted 27 lines
Quoted 4 lines
Quoted 2 lines

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?)

Quoted 19 lines
Quoted 18 lines

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,

Quoted 7 lines
Quoted 3 lines

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

Signature · 2 lines
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
#5 lore raw
In reply to Rob Landley
Quoted 4 lines · Rob Landley

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.

Quoted 3 lines

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.

Signature · 4 lines
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."