From: sashiko-bot@kernel.org
To: "Guixin Liu" <kanie@linux.alibaba.com>
Cc: linux-nvme@lists.infradead.org
Subject: Re: [PATCH v2 3/5] nvme-auth: fix data race on ctrl->transaction
Date: Mon, 09 Nov 2026 02:31:34 +0000 [thread overview]
Message-ID: <sashiko-outbox-204348@kernel.org> (raw)
In-Reply-To: <20261109022646.290792-4-kanie@linux.alibaba.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] nvme-auth: missing Fixes trailer for ctrl->transaction data race
fix
--
commit 80e147df824d3b130d9f9eca4a6cd6ae6f4b0f78
Author: Guixin Liu <kanie@linux.alibaba.com>
> nvme-auth: fix data race on ctrl->transaction
>
> nvme_ctrl_auth_work() queues the DH-HMAC-CHAP exchange of every queue
> on nvme-auth-wq without waiting for them, so multiple
> nvme_queue_auth_work() instances run concurrently and all increment
> ctrl->transaction in nvme_queue_auth_work(). The plain increment is a
> data race, and the lost updates hand the same transaction id to
> concurrent queues.
>
> The controller side only echoes the transaction id within a queue, so
> the race has no functional impact today, but the increment is still
> unsynchronized and KCSAN reports it. Use atomic_inc_return(); the
> first transaction id is now 1 instead of 0, which is immaterial as
> the controller only echoes the id within a queue.
>
> Reviewed-by: Hannes Reinecke <hare@kernel.org>
> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
[Severity: Low]
Since this fixes the unsynchronized increment of ctrl->transaction across
concurrent per-queue authentication work items, should the commit message
include:
Fixes: f50fff73d620 ("nvme: implement In-Band authentication")
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109022646.290792-1-kanie@linux.alibaba.com?part=3
next prev parent reply other threads:[~2026-11-09 2:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 2:26 [PATCH v2 0/5] nvme: fabrics and target fixes Guixin Liu
2026-11-09 2:26 ` [PATCH v2 1/5] nvme: reject a reconnect_delay of 0 through sysfs Guixin Liu
2026-11-09 17:54 ` Keith Busch
2026-11-10 2:36 ` Guixin Liu
2026-11-09 2:26 ` [PATCH v2 2/5] nvme-fc: fix use-after-free in nvme_fc_match_disconn_ls() Guixin Liu
2026-11-09 2:26 ` [PATCH v2 3/5] nvme-auth: fix data race on ctrl->transaction Guixin Liu
2026-11-09 2:31 ` sashiko-bot [this message]
2026-11-09 17:10 ` Keith Busch
2026-11-10 2:34 ` Guixin Liu
2026-11-09 2:26 ` [PATCH v2 4/5] nvmet: take subsys->lock in nvmet_subsys_attr_tbkas_store() Guixin Liu
2026-11-09 2:26 ` [PATCH v2 5/5] nvmet: use GFP_KERNEL for PR allocations Guixin Liu
2026-11-09 17:47 ` (subset) [PATCH v2 0/5] nvme: fabrics and target fixes Keith Busch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-204348@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kanie@linux.alibaba.com \
--cc=linux-nvme@lists.infradead.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox