From: Leon Romanovsky <leon@kernel.org>
To: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Cc: Sagi Grimberg <sagi@grimberg.me>,
Max Gurtovoy <mgurtovoy@nvidia.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Mike Christie <michael.christie@oracle.com>,
linux-rdma@vger.kernel.org, target-devel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 0/6] IB/isert: fix the device removal use-after-free
Date: Wed, 4 Nov 2026 16:20:43 +0200 [thread overview]
Message-ID: <20261104142043.GG478286@unreal> (raw)
In-Reply-To: <20261104040318.1844865-1-yhlee@isslab.korea.ac.kr>
On Wed, Nov 04, 2026 at 01:03:11PM +0900, Yehyeong Lee wrote:
> The RDMA_CM_EVENT_DEVICE_REMOVAL callback in ib_isert waits for the
> connection it was handed to reach ISER_CONN_DOWN and then frees it, a
> use-after-free against isert_connect_release(), and the wait deadlocks
> against the handler_mutex rdma_destroy_id() needs. 3/6 moves the teardown
> into an ib_client callback, as nvmet-rdma did in f1d4ef7d8883, and gives
> every connection one owner. 1/6 and 2/6 are older problems; 4/6, 5/6 and
> 6/6 close three holes the walk makes visible.
>
> v7 -> v8
>
> v7: https://lore.kernel.org/r/20261104012219.1759523-1-yhlee@isslab.korea.ac.kr
>
> v6: https://lore.kernel.org/r/20261103223802.1697607-1-yhlee@isslab.korea.ac.kr
>
> v5: https://lore.kernel.org/r/20261103125955.1530355-1-yhlee@isslab.korea.ac.kr
>
> v4: https://lore.kernel.org/r/20261103032924.1073138-1-yhlee@isslab.korea.ac.kr
>
> Sashiko v7 3/6 High: isert_connect_error() clears cm_id after
> ib_drain_qp() again, as before the series. Before the drain the QP can
> still take an event, and isert_qp_event_callback() dereferences cm_id.
>
> Sashiko v7 5/6 High: isert_device_get() matches the ib_device pointer
> instead of node_guid, the same key isert_remove_one() uses. Two devices
> can share a node_guid, and the PD and the DMA mappings belong to one of
> them.
>
> Measured over soft-RoCE with KASAN, 114 runs. A test-only event delivered
> to isert_qp_event_callback() before the drain oopsed in rdma_notify() nine
> times over two runs of 3/6 as it was in v7 and not once in two runs of
> this series. A connect on a second device sharing a node_guid failed
> rdma_create_qp() twice in both runs before 5/6 and not at all after it.
> The cells v7 passed are unchanged: no KASAN, no Oops, no lockdep splat and
> no refcount warning on either side, device_list empty after twenty link
> removals and re-adds, and the login park finishing in eight seconds. I
> still could not measure the namespace move, for the reason given in v6.
>
> Yehyeong Lee (6):
> IB/isert: do not publish connections being released on a second list
> IB/isert: drain the QP without holding isert_conn->mutex
> IB/isert: tear connections down from an ib_client on device removal
> IB/isert: drop the promotion reference when a connection errors out
> IB/isert: do not build a new isert_device for a device being removed
> IB/isert: only reinstate a connection that reached full feature phase
>
> drivers/infiniband/ulp/isert/ib_isert.c | 395 +++++++++++++++++-------
> drivers/infiniband/ulp/isert/ib_isert.h | 9 +-
> 2 files changed, 294 insertions(+), 110 deletions(-)
So what do you expect from us now? You didn't bother to invest time into it,
by all these resubmissions, you clearly showed us that this is 100% AI work,
not reviewed, not tested, but marked for the stable@.
Thanks
>
>
> base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
> --
> 2.43.0
>
prev parent reply other threads:[~2026-11-04 14:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 4:03 [PATCH v8 0/6] IB/isert: fix the device removal use-after-free Yehyeong Lee
2026-11-04 4:03 ` [PATCH v8 1/6] IB/isert: do not publish connections being released on a second list Yehyeong Lee
2026-11-04 4:24 ` sashiko-bot
2026-11-04 4:03 ` [PATCH v8 2/6] IB/isert: drain the QP without holding isert_conn->mutex Yehyeong Lee
2026-11-04 4:22 ` sashiko-bot
2026-11-04 4:03 ` [PATCH v8 3/6] IB/isert: tear connections down from an ib_client on device removal Yehyeong Lee
2026-11-04 4:33 ` sashiko-bot
2026-11-04 4:03 ` [PATCH v8 4/6] IB/isert: drop the promotion reference when a connection errors out Yehyeong Lee
2026-11-04 4:16 ` sashiko-bot
2026-11-04 4:03 ` [PATCH v8 5/6] IB/isert: do not build a new isert_device for a device being removed Yehyeong Lee
2026-11-04 4:20 ` sashiko-bot
2026-11-04 4:03 ` [PATCH v8 6/6] IB/isert: only reinstate a connection that reached full feature phase Yehyeong Lee
2026-11-04 4:29 ` sashiko-bot
2026-11-04 14:20 ` Leon Romanovsky [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261104142043.GG478286@unreal \
--to=leon@kernel.org \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mgurtovoy@nvidia.com \
--cc=michael.christie@oracle.com \
--cc=sagi@grimberg.me \
--cc=target-devel@vger.kernel.org \
--cc=yhlee@isslab.korea.ac.kr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.