All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: James Bottomley <James.Bottomley@HansenPartnership.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: Thu, 13 Aug 2009 16:58:58 +0300	[thread overview]
Message-ID: <4A841C22.4070908@panasas.com> (raw)
In-Reply-To: <1250007887.4301.53.camel@mulgrave.site>

On 08/11/2009 07:24 PM, James Bottomley wrote:
> On Tue, 2009-08-11 at 12:14 -0400, Alan Stern wrote:
>> On Tue, 11 Aug 2009, James Bottomley wrote:
>>
>>> Sort of, but it's not really doing it properly.  Lets do it like this.
>>> This should also fix the > 255 length problem older devices might have.
>>
>> Do you mind including also the residue check?
> 
> But there's no point to it ... it's a Byzantine check.  The standard
> says shall return as many bytes as will fit in the allocation length
> (what it does with allocation length beyond data to return is
> undefined).
> 
> For the USB case where a full residue and no error indicates there was
> actually an error, we already have a translation.
> 
> If devices just return random data lengths and then stop, your proposed
> residue check doesn't catch them anyway.  However, I'd much rather
> assume a device performs to spec until proven otherwise.
> 

OK so this is also the case for devices that did not error, did not return
resid, and yet did not return the page in question. Please remove that
!= page check then. ("until proven otherwise")

> James
> 
> 

Boaz

  reply	other threads:[~2009-08-13 13:59 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
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 [this message]
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=4A841C22.4070908@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@HansenPartnership.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 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.