All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Rob Landley <rob@landley.net>
Cc: linux-scsi@vger.kernel.org
Subject: Re: Questions about proc_scsi_write() in scsi_proc.c
Date: Fri, 26 Oct 2007 16:09:37 -0500	[thread overview]
Message-ID: <1193432977.3293.76.camel@localhost.localdomain> (raw)
In-Reply-To: <200710261507.49284.rob@landley.net>

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



  reply	other threads:[~2007-10-26 21:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-26 20:07 Questions about proc_scsi_write() in scsi_proc.c Rob Landley
2007-10-26 21:09 ` James Bottomley [this message]
2007-10-26 22:29   ` Rob Landley
2007-10-26 22:47     ` James Bottomley
2007-10-27  4:16       ` Rob Landley
2007-10-26 22:58     ` Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1193432977.3293.76.camel@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=rob@landley.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.