[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <woyigt522zjki3zqudphkxmnzqmerrbk4qdammefuuxww3n3a2@ahfxqfztkmvp>
Date: Fri, 5 Apr 2024 08:45:11 +0200
From: Daniel Wagner <dwagner@...e.de>
To: Christoph Hellwig <hch@....de>
Cc: James Smart <james.smart@...adcom.com>,
Keith Busch <kbusch@...nel.org>, Sagi Grimberg <sagi@...mberg.me>, Hannes Reinecke <hare@...e.de>,
linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/5] nvme: authentication error are always
non-retryable
On Fri, Apr 05, 2024 at 08:16:24AM +0200, Christoph Hellwig wrote:
> > --- a/drivers/nvme/host/fabrics.c
> > +++ b/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;
>
> This is still abusing on the wire status code for in-kernel return
> codes. Can we please sort this out properly?
Okay, though I am not really sure how to do it correctly.
So the current mapping is
ret < 0: kernel errors
ret = 0: all good
ret > 0: wire status incl DNR
In order to split the internal DNR away, we could attach it to the cmd.
Is this what you had in mind? Or do you mean we should not return
NVME_SC_AUTH_REQUIRED at all. Instead just a negative value and update
the error handling on the callers?
Powered by blists - more mailing lists