Re: [PATCH] scsi: sd: Avoid sending an INQUIRY if the page is not supported

[Benjamin Block <lkml@mageta.org>]

On Mon, May 08, 2023 at 09:34:15AM -0700, Brian Bunker wrote:
> > On May 8, 2023, at 3:09 AM, Benjamin Block <bblock@linux.ibm.com> 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.

> 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.

-- 
Best Regards und Beste Grüße, Benjamin Block
               PGP KeyID: 9610 2BB8 2E17 6F65 2362  6DF2 46E0 4E05 67A3 2E9E