On 2023-05-11 12:44, Benjamin Block wrote:
On Mon, May 08, 2023 at 09:34:15AM -0700, Brian Bunker wrote:
On May 8, 2023, at 3:09 AM, Benjamin Block <bblock@xxxxxxxxxxxxx> wrote:
On Fri, May 05, 2023 at 01:49:50PM -0700, Brian Bunker wrote:
+ int ret = -EINVAL;
Been wondering, whether it would make sense to have two different error
levels here. One for the case where the page is not found in the loop
that searches within page 0, and one for when page 0 is not present when
we try to dereference the RCU protected pointer.
That way we could have a safe fallback. If the page is there, we use its
data, if it is not, we blindly send the INQUIRY like we do today.
Not sure whether this is a bit too paranoid.. VPD page 0 is mandatory
after all.
That could be done, but the problem would still exist for the PURE target.
We don’t support the page 0xb9, and we don’t advertise we do in the response
to VPD 0. This approach would still lead to the INQUIRY being sent to devices
I wasn't meaning to send the INQUIRY regardless to what the page says,
if it is present. I was just thinking to having fall-back for when the
page 0 is not there at all (initially, when you call
`rcu_dereference()`). That would support your storage, as you have page
0, and it would be present for the check I assume.
But anyway, it seems this is a no-go regardless. I didn't expect targets
sending a valid page 0, but still supporting pages that are not listed in it.
SCSI standards did contain words that implied vendors would report all
VPD/log/mode pages and operation codes using the mechanisms added to
those standards over the years. I guess users pressured vendors to do
this. Then recently, in T10 approved proposal 21-063r2, the weasel
words "may or may not" were added to all those mechanisms. IMO that
was a pretty disgraceful move by the storage vendors that control T10.
Doug Gilbert
P.S. I have a new option appearing in some of my utilities: --examine
The idea is that it uses an iota function to check for unreported
VPD/log/mode pages as the "report supported" device server responses
"may or may not" be trustworthy :-)
who don’t support it, don’t expect it, and report an unexpected error. What I am
trying to avoid is the INQUIRY being sent to devices who don’t invite it.
