From: Guixin Liu <kanie@linux.alibaba.com>
To: Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Nilay Shroff <nilay@linux.ibm.com>,
Daniel Wagner <dwagner@suse.de>, Hannes Reinecke <hare@suse.de>
Cc: linux-nvme@lists.infradead.org
Subject: [PATCH v2 0/5] nvme: fabrics and target fixes
Date: Mon, 9 Nov 2026 10:26:41 +0800 [thread overview]
Message-ID: <20261109022646.290792-1-kanie@linux.alibaba.com> (raw)
Five fixes found by code inspection of the nvme host and target
drivers:
- a reconnect_delay of 0 is accepted through sysfs and makes the
ctrl_loss_tmo store divide by zero; reproduced on an unfixed
kernel, rejected on the patched one
- a use-after-free in nvme_fc_match_disconn_ls(): no iterator is
sound across the rport lock drop inside the loop, so the loop is
reworked to run entirely under the rport lock and to take a
reference only for the match; reproduced under KASAN through fcloop
- a data race on ctrl->transaction between concurrent per-queue
DH-HMAC-CHAP exchanges
- nvmet_subsys_attr_tbkas_store() walks subsys->ctrls without
subsys->lock, the same bug fixed for qid_max_store() in patch 4
of this series
- needless GFP_ATOMIC allocations in the nvmet persistent reservation
code
The reconnect_delay, tbkas, nvme-auth and persistent reservation fixes
are verified on an initiator/target VM pair running the patched
kernel: connect/IO/disconnect cycles, tbkas toggles racing connection
churn, persistent reservation operations across all six reservation
types, and a full DH-HMAC-CHAP authenticated session with I/O. The
reworked nvme-fc loop is compile tested and exercised under KASAN
through fcloop with six controllers on one remote port across tbkas
force-reconnect cycles and concurrent disconnects, with no reports.
Changes since v1:
- rework the nvme-fc fix: neither the _safe iterator nor a plain one
is sound across the lock drop, as the loop's own put can be the
final reference; the loop now runs entirely under the rport lock
and takes a reference only for the match (Hannes Reinecke, sashiko)
- drop the nvmet_install_queue() patch: the callers already release
their reference on failure (Hannes Reinecke)
- use atomic_inc_return() in the nvme-auth patch (Hannes Reinecke)
- correct the Fixes tag of the reconnect_delay patch to the commit
that introduced the sysfs store (sashiko, confirmed by Christoph
Hellwig)
Link: https://lore.kernel.org/all/20261106015842.3534898-1-kanie@linux.alibaba.com/
Guixin Liu (5):
nvme: reject a reconnect_delay of 0 through sysfs
nvme-fc: fix use-after-free in nvme_fc_match_disconn_ls()
nvme-auth: fix data race on ctrl->transaction
nvmet: take subsys->lock in nvmet_subsys_attr_tbkas_store()
nvmet: use GFP_KERNEL for PR allocations
drivers/nvme/host/auth.c | 2 +-
drivers/nvme/host/fc.c | 22 ++++++++++++----------
drivers/nvme/host/nvme.h | 2 +-
drivers/nvme/host/sysfs.c | 3 +++
drivers/nvme/target/configfs.c | 2 ++
drivers/nvme/target/pr.c | 4 ++--
6 files changed, 21 insertions(+), 14 deletions(-)
--
2.43.7
next reply other threads:[~2026-11-09 2:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 2:26 Guixin Liu [this message]
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
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=20261109022646.290792-1-kanie@linux.alibaba.com \
--to=kanie@linux.alibaba.com \
--cc=axboe@kernel.dk \
--cc=dwagner@suse.de \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
--cc=sagi@grimberg.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.