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