]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
nvmet-fc: defer cleanup using RCU properly
authorDaniel Wagner <dwagner@suse.de>
Wed, 31 Jan 2024 08:51:04 +0000 (09:51 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 1 Mar 2024 12:34:52 +0000 (13:34 +0100)
commitccd49adde0547bd6b6c857909d1c4a3ad6ab93c0
tree1058f61bab4703759714602dc3a0d20813c01a2c
parent2baa7272f2d98476fbff68404ddc1d42500efa36
nvmet-fc: defer cleanup using RCU properly

[ Upstream commit 4049dc96b8de7aeb3addcea039446e464726a525 ]

When the target executes a disconnect and the host triggers a reconnect
immediately, the reconnect command still finds an existing association.

The reconnect crashes later on because nvmet_fc_delete_target_assoc
blindly removes resources while the reconnect code wants to use it.

To address this, nvmet_fc_find_target_assoc should not be able to
lookup an association which is being removed. The association list
is already under RCU lifetime management, so let's properly use it
and remove the association from the list and wait for a grace period
before cleaning up all. This means we also can drop the RCU management
on the queues, because this is now handled via the association itself.

A second step split the execution context so that the initial disconnect
command can complete without running the reconnect code in the same
context. As usual, this is done by deferring the ->done to a workqueue.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/nvme/target/fc.c