[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240219131531.15134-1-dwagner@suse.de>
Date: Mon, 19 Feb 2024 14:15:25 +0100
From: Daniel Wagner <dwagner@...e.de>
To: James Smart <james.smart@...adcom.com>
Cc: Keith Busch <kbusch@...nel.org>,
Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
Hannes Reinecke <hare@...e.de>,
linux-nvme@...ts.infradead.org,
linux-kernel@...r.kernel.org,
Daniel Wagner <dwagner@...e.de>
Subject: [PATCH v1 0/6] nvme-fc: fix blktests nvme/041
I've dropped the rport ref counting change in the main patch and gave it another
round of testing. This time with dev_loss_tmo active with SCSI and NVME enabled
on the same rport. Nothing exploded, all resources were released correctly.
I am not so happy with the 'connect_sync' name yet (patch #1) but we still have
to agree on that offloading the initial connect attemp is correct. James and
Hannes are strongly in favour for this approach as far I can tell.
changes:
v1:
- renamed 'nvme-fc: redesign locking and refcounting'
to 'nvme-fc: reorder ctrl ref counting and cleanup code path'
- testing with scsi/nvme dev_loss_tmo on real hw
- removed rport ref counting part
- collected RB tags
v0:
- initial version
- https://lore.kernel.org/linux-nvme/20240216084526.14133-1-dwagner@suse.de/
Daniel Wagner (6):
nvme-fabrics: introduce connect_sync option
nvme-fc: rename free_ctrl callback to match name pattern
nvme-fc: do not retry when auth fails or connection is refused
nvme-fabrics: introduce ref counting for nvmf_ctrl_options
nvme-fc: reorder ctrl ref counting and cleanup code path
nvme-fc: wait for connect attempt to finish
drivers/nvme/host/fabrics.c | 28 ++++++-
drivers/nvme/host/fabrics.h | 9 ++-
drivers/nvme/host/fc.c | 145 +++++++++++++++++-------------------
drivers/nvme/host/rdma.c | 18 +++--
drivers/nvme/host/tcp.c | 21 ++++--
drivers/nvme/target/loop.c | 19 +++--
6 files changed, 141 insertions(+), 99 deletions(-)
--
2.43.1
Powered by blists - more mailing lists