All of lore.kernel.org
 help / color / mirror / Atom feed
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



             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.