From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Matthew Wilcox <willy@linux.intel.com>,
SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: Bugs in scsi_vpd_inquiry()
Date: Tue, 11 Aug 2009 10:27:18 -0500 [thread overview]
Message-ID: <1250004438.4301.36.camel@mulgrave.site> (raw)
In-Reply-To: <4A818BBC.8090705@panasas.com>
On Tue, 2009-08-11 at 18:18 +0300, Boaz Harrosh wrote:
> On 08/11/2009 06:13 PM, James Bottomley wrote:
> > On Tue, 2009-08-11 at 10:53 -0400, Alan Stern wrote:
> >> On Tue, 11 Aug 2009, Boaz Harrosh wrote:
> >>
> >>> This is certainly a bug. Otherwise I would get all my pages 4 bytes short
> >>> and wonder why.
> >>>
> >>> I wish the bug would explain that stupid USB device Martin was fixing.
> >>> "I die if evpd page=0 is read" is a very brain dead thing. But there
> >>> is no overflow in current code, only underflow.
> >>>
> >>> If you are at it could you please fix all the bugs in this code: ;-)
> >>
> >> The USB problem shouldn't affect anything thanks to Martin's other
> >> changes (sd won't read VPD for devices with scsi_level <= SCSI_2). So
> >> how does this revised patch look?
> >>
> >> Alan Stern
> >>
> >>
> >> Index: usb-2.6/drivers/scsi/scsi.c
> >> ===================================================================
> >> --- usb-2.6.orig/drivers/scsi/scsi.c
> >> +++ usb-2.6/drivers/scsi/scsi.c
> >> @@ -969,7 +969,7 @@ EXPORT_SYMBOL(scsi_track_queue_full);
> >> * @sdev: The device to ask
> >> * @buffer: Where to put the result
> >> * @page: Which Vital Product Data to return
> >> - * @len: The length of the buffer
> >> + * @len: The length of the data (= buffer length - 4)
> >
> > Really, no. The former is the correct (and universally used
> > definition). This one you propose is asking for confusion and misuse.
> >
>
> This is what is done today Only documented
>
> If you want to fix it to be the full buffer size the user code
> should be fixed
Right.
> >> *
> >> * This is an internal helper function. You probably want to use
> >> * scsi_get_vpd_page instead.
> >> @@ -980,7 +980,10 @@ static int scsi_vpd_inquiry(struct scsi_
> >> u8 page, unsigned len)
> >> {
> >> int result;
> >> - unsigned char cmd[16];
> >> + int resid;
> >> + unsigned char cmd[6];
> >> +
> >> + len += 4; /* Include room for the header bytes */
> >>
> >> cmd[0] = INQUIRY;
> >> cmd[1] = 1; /* EVPD */
> >> @@ -989,17 +992,19 @@ static int scsi_vpd_inquiry(struct scsi_
> >> cmd[4] = len & 0xff;
> >> cmd[5] = 0; /* Control byte */
> >>
> >> + buffer[1] = ~page;
> >
> > This is pointless and dangerous: Some architectures will invalidate
> > caches for DMA not flush them, so it might not do what you think it
> > does.
> >
>
> Then you can't do that "after check" either. It's a simple minefield.
> What do you suggest?
Well, nothing really, like the original code. Byzantine checking is
never a good idea. You always assume that if a device told you it did
what you told it, it actually did. If we find devices that fail this
simple premise, then we get into blacklists and other forms of
nastiness.
James
next prev parent reply other threads:[~2009-08-11 15:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-10 14:41 Bugs in scsi_vpd_inquiry() Alan Stern
2009-08-10 14:58 ` Matthew Wilcox
2009-08-10 15:32 ` Alan Stern
2009-08-10 17:08 ` Martin K. Petersen
2009-08-10 20:13 ` Alan Stern
2009-08-10 20:49 ` Martin K. Petersen
2009-08-10 21:14 ` Alan Stern
2009-08-10 22:47 ` Martin K. Petersen
2009-08-11 14:35 ` Alan Stern
2009-08-10 21:53 ` Douglas Gilbert
2009-08-10 22:52 ` Martin K. Petersen
2009-08-11 16:04 ` Matthew Wilcox
2009-08-11 7:07 ` Boaz Harrosh
2009-08-11 14:53 ` Alan Stern
2009-08-11 15:13 ` James Bottomley
2009-08-11 15:18 ` Boaz Harrosh
2009-08-11 15:27 ` James Bottomley [this message]
2009-08-11 15:38 ` Alan Stern
2009-08-11 15:57 ` Matthew Wilcox
2009-08-11 15:59 ` James Bottomley
2009-08-11 16:14 ` Alan Stern
2009-08-11 16:24 ` James Bottomley
2009-08-13 13:58 ` Boaz Harrosh
2009-08-13 14:15 ` James Bottomley
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=1250004438.4301.36.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership.com \
--cc=bharrosh@panasas.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=stern@rowland.harvard.edu \
--cc=willy@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox