These error cases were not setting an auth-failure-reason-code-explanation.
This means an AUTH_Failure2 message will be sent with an explanation value
of 0 which is a reserved value.
Signed-off-by: Mark O'Donovan <[email protected]>
---
drivers/nvme/host/auth.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/auth.c b/drivers/nvme/host/auth.c
index e1a98647c3a2..094f37e11921 100644
--- a/drivers/nvme/host/auth.c
+++ b/drivers/nvme/host/auth.c
@@ -760,6 +760,7 @@ static void nvme_queue_auth_work(struct work_struct *work)
ret = nvme_auth_dhchap_setup_host_response(ctrl, chap);
mutex_unlock(&ctrl->dhchap_auth_mutex);
if (ret) {
+ chap->status = NVME_AUTH_DHCHAP_FAILURE_FAILED;
chap->error = ret;
goto fail2;
}
@@ -776,6 +777,7 @@ static void nvme_queue_auth_work(struct work_struct *work)
tl = ret;
ret = nvme_auth_submit(ctrl, chap->qid, chap->buf, tl, true);
if (ret) {
+ chap->status = NVME_AUTH_DHCHAP_FAILURE_FAILED;
chap->error = ret;
goto fail2;
}
@@ -811,6 +813,7 @@ static void nvme_queue_auth_work(struct work_struct *work)
ret = nvme_auth_dhchap_setup_ctrl_response(ctrl, chap);
if (ret) {
mutex_unlock(&ctrl->dhchap_auth_mutex);
+ chap->status = NVME_AUTH_DHCHAP_FAILURE_FAILED;
chap->error = ret;
goto fail2;
}
@@ -830,8 +833,10 @@ static void nvme_queue_auth_work(struct work_struct *work)
__func__, chap->qid);
tl = nvme_auth_set_dhchap_success2_data(ctrl, chap);
ret = nvme_auth_submit(ctrl, chap->qid, chap->buf, tl, true);
- if (ret)
+ if (ret) {
+ chap->status = NVME_AUTH_DHCHAP_FAILURE_FAILED;
chap->error = ret;
+ }
}
if (!ret) {
chap->error = 0;
--
2.39.2
On Thu, Jul 27, 2023 at 01:47:48PM +0000, Mark O'Donovan wrote:
> These error cases were not setting an auth-failure-reason-code-explanation.
> This means an AUTH_Failure2 message will be sent with an explanation value
> of 0 which is a reserved value.
I'll leave the final decision to Hannes, but shouldn't we find a common
place, either behind a label or in the body of the function to set
chap->status? Having to add this in a lot of error labels doesn't feel
very maintainable.
On 7/31/23 07:58, Christoph Hellwig wrote:
> On Thu, Jul 27, 2023 at 01:47:48PM +0000, Mark O'Donovan wrote:
>> These error cases were not setting an auth-failure-reason-code-explanation.
>> This means an AUTH_Failure2 message will be sent with an explanation value
>> of 0 which is a reserved value.
>
> I'll leave the final decision to Hannes, but shouldn't we find a common
> place, either behind a label or in the body of the function to set
> chap->status? Having to add this in a lot of error labels doesn't feel
> very maintainable.
>
Yeah; the whole AUTH_XXX errors are ever so cumbersome as we don't have
a good way to passing them up the stack. Plus we can't transport errors
during connect, making it doubly pointless.
Maybe a printk() somewhere. I'll check.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
[email protected] +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman