Re: [PATCH v2 2/5] nvme-fc: do not retry when auth fails or connection is refused

[Sagi Grimberg]

On 23/02/2024 13:58, Hannes Reinecke wrote:
> On 2/22/24 18:02, Daniel Wagner wrote:
> > On Thu, Feb 22, 2024 at 08:45:04AM +0100, Daniel Wagner wrote:
> > > On Thu, Feb 22, 2024 at 07:46:12AM +0100, Hannes Reinecke wrote:
> > > > On 2/21/24 17:37, Daniel Wagner wrote:
> > > > > On Wed, Feb 21, 2024 at 04:53:44PM +0100, Hannes Reinecke wrote:
> > > > > In this case yes, I've tested on top of this patch. This breaks 
> > > > > the loop
> > > > > where the provided key is invalid or is missing. The loop would happy
> > > > > retry until reaching max of retries.
> > > >
> > > > But that's to be expected, no?
> > >
> > > Why? If the key is wrong/missing it will be likely wrong/missing the
> > > next retry again. So what's the point in retrying?
> > >
> > > > After all, that's _precisely_ what
> > > > NVME_SC_DNR is for;
> > > > if you shouldn't retry, that bit is set.
> > > > If it's not set, you should.
> > >
> > > Okay, in this case there is a bug in the auth code somewhere.
> >
> > With the change below nvme/041 also passes:
> >
> > modified   drivers/nvme/host/fabrics.c
> > @@ -467,7 +467,7 @@ int nvmf_connect_admin_queue(struct nvme_ctrl *ctrl)
> >           if (result & NVME_CONNECT_AUTHREQ_ASCR) {
> >               dev_warn(ctrl->device,
> >                    "qid 0: secure concatenation is not supported\n");
> > -            ret = NVME_SC_AUTH_REQUIRED;
> > +            ret = NVME_SC_AUTH_REQUIRED | NVME_SC_DNR;
> >               goto out_free_data;
> >           }
> >           /* Authentication required */
> > @@ -475,7 +475,7 @@ int nvmf_connect_admin_queue(struct nvme_ctrl *ctrl)
> >           if (ret) {
> >               dev_warn(ctrl->device,
> >                    "qid 0: authentication setup failed\n");
> > -            ret = NVME_SC_AUTH_REQUIRED;
> > +            ret = NVME_SC_AUTH_REQUIRED | NVME_SC_DNR;
> >               goto out_free_data;
> >           }
> >           ret = nvme_auth_wait(ctrl, 0);
> > @@ -540,8 +540,9 @@ int nvmf_connect_io_queue(struct nvme_ctrl *ctrl, 
> > u16 qid)
> >           /* Secure concatenation is not implemented */
> >           if (result & NVME_CONNECT_AUTHREQ_ASCR) {
> >               dev_warn(ctrl->device,
> > -                 "qid 0: secure concatenation is not supported\n");
> > -            ret = NVME_SC_AUTH_REQUIRED;
> > +                 "qid %d: secure concatenation is not supported\n",
> > +                 qid);
> > +            ret = NVME_SC_AUTH_REQUIRED | NVME_SC_DNR;
> >               goto out_free_data;
> >           }
> >           /* Authentication required */
> > @@ -549,7 +550,7 @@ int nvmf_connect_io_queue(struct nvme_ctrl *ctrl, 
> > u16 qid)
> >           if (ret) {
> >               dev_warn(ctrl->device,
> >                    "qid %d: authentication setup failed\n", qid);
> > -            ret = NVME_SC_AUTH_REQUIRED;
> > +            ret = NVME_SC_AUTH_REQUIRED | NVME_SC_DNR;
> >           } else {
> >               ret = nvme_auth_wait(ctrl, qid);
> >               if (ret)
> >
> > Is this what you had in mind?
>
> Which, incidentally, is basically the patch I just posted.

Reading this, the patchset from Hannes now is clearer.
Isn't the main issue is that nvme-fc tries to periodicly reconnect
when failing the first connect? This is exactly what the test expects
it to do right?