From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Hannes Reinecke <hare@suse.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.com>
Subject: Re: [PATCH 1/3] ses: make initial allocation size configurable
Date: Fri, 22 Dec 2017 09:14:33 -0800 [thread overview]
Message-ID: <1513962873.3163.12.camel@HansenPartnership.com> (raw)
In-Reply-To: <1513855354-86603-2-git-send-email-hare@suse.de>
On Thu, 2017-12-21 at 12:22 +0100, Hannes Reinecke wrote:
> Some storage arrays have an incorrect SES implementation which will
> always return the allocation length of the CDB instead of the true
> length of the requested page.
That's a pretty gross standards violation, is this common? When the
buffer is > than the data to return, does it get set then? Because if
not, we're going to be processing bogus data and no module parameter
can fix this because the returned length depends on the number of
elements in the enclosure making this parameter really unsafe unless
you get it exactly right.
> With this patch one can modify the initial allocation size to
> get the full output of those arrays.
This really doesn't look like the right way to do it. Shouldn't we
rather have a blacklist for these devices and simply do a page for each
allocation for them (assuming they return the correct length when over
subscribed).
James
next prev parent reply other threads:[~2017-12-22 17:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-21 11:22 [PATCH 0/3] Another round of SES fixes Hannes Reinecke
2017-12-21 11:22 ` [PATCH 1/3] ses: make initial allocation size configurable Hannes Reinecke
2017-12-22 17:14 ` James Bottomley [this message]
2017-12-23 14:29 ` Hannes Reinecke
2017-12-21 11:22 ` [PATCH 2/3] ses: skip error messages for invalid LUNs Hannes Reinecke
2017-12-22 17:39 ` James Bottomley
2017-12-23 14:37 ` Hannes Reinecke
2017-12-21 11:22 ` [PATCH 3/3] ses: Retry Power-on-reset check condition Hannes Reinecke
2017-12-21 15:29 ` James Bottomley
2017-12-21 15:39 ` 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=1513962873.3163.12.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=hare@suse.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox