linux-kernel - [PATCH v2 00/15] nvmet-fcloop: track resources via reference counting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250311-nvmet-fcloop-v2-0-fc40cb64edea@kernel.org>
Date: Tue, 11 Mar 2025 11:11:26 +0100
From: Daniel Wagner <wagi@...nel.org>
To: James Smart <james.smart@...adcom.com>, Christoph Hellwig <hch@....de>, 
 Sagi Grimberg <sagi@...mberg.me>, Chaitanya Kulkarni <kch@...dia.com>
Cc: Hannes Reinecke <hare@...e.de>, Keith Busch <kbusch@...nel.org>, 
 linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org, 
 Daniel Wagner <wagi@...nel.org>
Subject: [PATCH v2 00/15] nvmet-fcloop: track resources via reference
 counting

The idea to use ref counting for tport and rport didn't work well. fcloop
was to eager to remove resources when the assocication was torn down.
Thus I looked more closely how the existing solution is supposed to work
and fixed all the problems I found.

This also avoids taking references for a nport and a rport/tport step in
step which Hannes was not happy with.

With all these changes it is possible to add/remove the target side and
nothing blows up anymore. There is just one small issue left with
nvme/030. The problem is that the test case assumes that the generation
counter is updated immediately but for FC it takes a bit, thus the test
fails. A sleep before reading the genctr 'fixes' it:

@@ -36,27 +36,32 @@ test() {
 	_add_nvmet_subsys_to_port "${port}" "${subsys}1"
 	_create_nvmet_host "${subsys}1" "${def_hostnqn}"

+	sleep 1
 	genctr=$(_discovery_genctr "$port")
[...]

There is another problem I was not able to figure out so far. When I run
blktests in a loop, the system runs out of memory eventually.

Signed-off-by: Daniel Wagner <wagi@...nel.org>
---
Changes in v2:
- drop tport and rport ref counting, use implicit synchronisation
- a bunch of additional fixes in existing ref countig
- replaced kref with refcount
- Link to v1: https://lore.kernel.org/r/20250226-nvmet-fcloop-v1-0-c0bd83d43e6a@kernel.org

---
Daniel Wagner (15):
      nvmet-fcloop: remove nport from list on last user
      nvmet-fcloop: replace kref with refcount
      nvmet-fcloop: add ref counting to lport
      nvmet-fcloop: refactor fcloop_nport_alloc
      nvmet-fcloop: track ref counts for nports
      nvmet-fcloop: sync targetport removal
      nvmet-fcloop: update refs on tfcp_req
      nvmet-fcloop: add missing fcloop_callback_host_done
      nvmet-fc: update tgtport ref per assoc
      nvmet-fc: take tgtport reference only once
      nvmet-fc: free pending reqs on tgtport unregister
      nvmet-fc: inline nvmet_fc_delete_assoc
      nvmet-fc: inline nvmet_fc_free_hostport
      nvmet-fc: take tgtport refs for portentry
      nvmet-fc: put ref when assoc->del_work is already scheduled

 drivers/nvme/target/fc.c     | 146 ++++++++++-------
 drivers/nvme/target/fcloop.c | 366 +++++++++++++++++++++++++------------------
 2 files changed, 308 insertions(+), 204 deletions(-)
---
base-commit: 4bfed375fd3acdfa4324acaf22f7664e4819fbb1
change-id: 20250214-nvmet-fcloop-a649738b7e6e

Best regards,
-- 
Daniel Wagner <wagi@...nel.org>