Re: [PATCH v8 3/6] IB/isert: tear connections down from an ib_client on device removal

[sashiko-bot@kernel.org]

> The RDMA_CM_EVENT_DEVICE_REMOVAL callback waits for the connection it was
> handed to reach ISER_CONN_DOWN and then frees it.  isert_release_work()
> publishes that state before it drops its reference, so the handler can free
> a connection that isert_connect_release() is still running on.  The wait
> itself deadlocks against the handler_mutex rdma_destroy_id() needs.
> 
> Register an ib_client instead, as nvmet-rdma did in commit f1d4ef7d8883
> ("nvmet-rdma: register ib_client to not deadlock in device removal"), and
> tear the device's connections down from its remove callback.  It walks
> isert_conn_list under isert_conn_mutex, takes a reference with
> kref_get_unless_zero(), tears each one down after dropping the lock, and
> asks iscsi to reinstate the session.  isert_device_put() completes
> removal_comp once the CQs and the PD are gone.  Publishing now happens in
> the same isert_conn_mutex section that tests isert_device->removing, and
> isert_np is reference counted because a connection can outlive its portal.
> [ ... ]
>    entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Fixes: 63b268d232b8 ("IB/isert: Properly release resources on DEVICE_REMOVAL")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261104040318.1844865-1-yhlee@isslab.korea.ac.kr?part=3