All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Hannes Reinecke <hare@suse.de>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Christoph Hellwig <hch@lst.de>,
	Bart van Assche <bart.vanassche@sandisk.com>,
	James Bottomley <james.bottomley@hansenpartnership.com>,
	linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.com>
Subject: Re: [PATCH 2/4] scsi_devinfo: fixup string compare
Date: Tue, 8 Aug 2017 12:06:43 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1708081150250.2055-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <91c73f33-9b34-cdb3-c47d-777bc2c2f8fc@suse.de>

On Tue, 8 Aug 2017, Hannes Reinecke wrote:

> On 08/08/2017 05:25 PM, Alan Stern wrote:
> > On Tue, 8 Aug 2017, Hannes Reinecke wrote:
> > 
> >> When checking the model and vendor string we need to use the
> >> minimum value of either string, otherwise we'll miss out on
> >> wildcard matches.
> >> And we should avoid matching anything with zero size as this
> >> match will be incorrect.
> >> Without this patch certain Hitachi arrays will not be presenting
> >> VPD pages correctly.
> >>
> >> Fixes: 5e7ff2c ("SCSI: fix new bug in scsi_dev_info_list string matching")
> >> Signed-off-by: Hannes Reinecke <hare@suse.com>
> > 
> > This is very questionable.  As described in commit b704f70ce200 ("SCSI: 
> > fix bug in scsi_dev_info_list matching"), there are devices which have 
> > vendor or model strings of length 0, and there are entries in the 
> > global device list like that too.  With this patch, such devices and 
> > such entries would never match anything.
> > 
> > Also, the idea of using the minimum length of either string doesn't 
> > sound right.  It would allow a device with string "abc" to match an 
> > entry in the list with string "abcd", which would be wrong.
> > 
> > Suggestion:
> > 
> > 	Allow a device string to match a list entry if the lengths
> > 	are equal or the list entry is shorter (this would be a 
> > 	wildcard match), but not if the list entry is longer.  Here
> > 	the device string length is after leading and trailing blanks
> > 	have been removed.
> > 
> > 	As a corollary, allow an empty device string to match an empty 
> > 	list entry but nothing else.
> > 
> > Alan Stern
> > 
> Well, so far we haven't encountered any of those devices.

But what if we do in the future?  The code should be correct for 
anything.

> I _have_ validated the patch with the known problematic inquiry strings,
> namely
> 
> "HITACHI" "OPEN-V"
> "Inateck" "       "
> "       " "Scanner"
> "Promise" "STEX"
> 
> and it gives the correct result for all of these.

How can "       " "Scanner" give the correct result?  Oh, I see -- the 
patch description and the code comment both say that empty strings 
never match, but in fact they do -- you allow a match if either the 
vendor or model string is empty, but not if they are both empty.

> If you have any inquiry strings for which this does _not_ produce the
> correct result please let me know.

What about "HITA" "OPEN-V"?  Or "" "OPEN-V"?  Both of these will match
the "HITACHI" "OPEN-" entry, but neither of them should.

What about "ABCD" "Scanner"?  This will match the "        " "Scanner" 
entry, but it shouldn't.

Alan Stern

  reply	other threads:[~2017-08-08 16:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-08 14:36 [PATCH 0/4] Fixup blacklist handling Hannes Reinecke
2017-08-08 14:36 ` [PATCH 1/4] scsi: whitespace fixes in scsi_devinfo.c Hannes Reinecke
2017-08-08 14:36 ` [PATCH 2/4] scsi_devinfo: fixup string compare Hannes Reinecke
2017-08-08 15:25   ` Alan Stern
2017-08-08 15:37     ` Hannes Reinecke
2017-08-08 16:06       ` Alan Stern [this message]
2017-08-08 16:11         ` Bart Van Assche
2017-08-08 16:14           ` Hannes Reinecke
2017-08-08 16:12         ` Hannes Reinecke
2017-08-08 14:36 ` [PATCH 3/4] scsi_debug: allow to specify inquiry vendor and model Hannes Reinecke
2017-08-08 14:36 ` [PATCH 4/4] scsi: Export blacklist flags to sysfs Hannes Reinecke

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=Pine.LNX.4.44L0.1708081150250.2055-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=bart.vanassche@sandisk.com \
    --cc=hare@suse.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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.