linux.git/drivers/nvme, branch v6.1.84

nvme: fix reconnection fail due to reserved tag allocation

2024-03-26T22:20:59+00:00

[ Upstream commit de105068fead55ed5c07ade75e9c8e7f86a00d1d ]

We found a issue on production environment while using NVMe over RDMA,
admin_q reconnect failed forever while remote target and network is ok.
After dig into it, we found it may caused by a ABBA deadlock due to tag
allocation. In my case, the tag was hold by a keep alive request
waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the
request maked as idle and will not process before reset success. As
fabric_q shares tagset with admin_q, while reconnect remote target, we
need a tag for connect command, but the only one reserved tag was held
by keep alive command which waiting inside admin_q. As a result, we
failed to reconnect admin_q forever. In order to fix this issue, I
think we should keep two reserved tags for admin queue.

Fixes: ed01fee283a0 ("nvme-fabrics: only reserve a single tag")
Signed-off-by: Chunguang Xu 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Chaitanya Kulkarni 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvme: add the Apple shared tag workaround to nvme_alloc_io_tag_set

2024-03-26T22:20:59+00:00

[ Upstream commit 93b24f579c392bac2e491fee79ad5ce5a131992e ]

Add the apple shared tag workaround to nvme_alloc_io_tag_set to prepare
for using that helper in the PCIe driver.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Chaitanya Kulkarni 
Stable-dep-of: de105068fead ("nvme: fix reconnection fail due to reserved tag allocation")
Signed-off-by: Sasha Levin

nvme: only set reserved_tags in nvme_alloc_io_tag_set for fabrics controllers

2024-03-26T22:20:59+00:00

[ Upstream commit b794d1c2ad6d7921f2867ce393815ad31b5b5a83 ]

The reserved_tags are only needed for fabrics controllers.  Right now only
fabrics drivers call this helper, so this is harmless, but we'll use it
in the PCIe driver soon.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Sagi Grimberg 
Reviewed-by: Chaitanya Kulkarni 
Stable-dep-of: de105068fead ("nvme: fix reconnection fail due to reserved tag allocation")
Signed-off-by: Sasha Levin

nvmet-fc: take ref count on tgtport before delete assoc

2024-03-01T12:26:28+00:00

[ Upstream commit fe506a74589326183297d5abdda02d0c76ae5a8b ]

We have to ensure that the tgtport is not going away
before be have remove all the associations.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Daniel Wagner 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvmet-fc: avoid deadlock on delete association path

2024-03-01T12:26:28+00:00

[ Upstream commit 710c69dbaccdac312e32931abcb8499c1525d397 ]

When deleting an association the shutdown path is deadlocking because we
try to flush the nvmet_wq nested. Avoid this by deadlock by deferring
the put work into its own work item.

Reviewed-by: Christoph Hellwig 
Signed-off-by: Daniel Wagner 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvmet-fc: abort command when there is no binding

2024-03-01T12:26:28+00:00

[ Upstream commit 3146345c2e9c2f661527054e402b0cfad80105a4 ]

When the target port has not active port binding, there is no point in
trying to process the command as it has to fail anyway. Instead adding
checks to all commands abort the command early.

Reviewed-by: Hannes Reinecke 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Daniel Wagner 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvmet-fc: hold reference on hostport match

2024-03-01T12:26:28+00:00

[ Upstream commit ca121a0f7515591dba0eb5532bfa7ace4dc153ce ]

The hostport data structure is shared between the association, this why
we keep track of the users via a refcount. So we should not decrement
the refcount on a match and free the hostport several times.

Reported by KASAN.

Reviewed-by: Hannes Reinecke 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Daniel Wagner 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvmet-fc: defer cleanup using RCU properly

2024-03-01T12:26:28+00:00

[ 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 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Daniel Wagner 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvmet-fc: release reference on target port

2024-03-01T12:26:28+00:00

[ Upstream commit c691e6d7e13dab81ac8c7489c83b5dea972522a5 ]

In case we return early out of __nvmet_fc_finish_ls_req() we still have
to release the reference on the target port.

Reviewed-by: Hannes Reinecke 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Daniel Wagner 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin

nvmet-fcloop: swap the list_add_tail arguments

2024-03-01T12:26:27+00:00

[ Upstream commit dcfad4ab4d6733f2861cd241d8532a0004fc835a ]

The first argument of list_add_tail function is the new element which
should be added to the list which is the second argument. Swap the
arguments to allow processing more than one element at a time.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Daniel Wagner 
Signed-off-by: Keith Busch 
Signed-off-by: Sasha Levin