mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH net] net/smc: check every link before skipping the RMB registration
@ 2026-11-13 19:11 Bryam Vargas via B4 Relay
  2026-11-13 19:17 ` netdev-bot+sinfo
  0 siblings, 1 reply; 2+ messages in thread
From: Bryam Vargas via B4 Relay @ 2026-11-13 19:11 UTC (permalink / raw)
  To: Eric Dumazet, Sidraya Jayagond, Dust Li, D. Wythe,
	Mahanta Jambigi, Paolo Abeni, Jakub Kicinski, David S. Miller
  Cc: Simon Horman, linux-s390, Wen Gu, netdev, linux-rdma,
	linux-kernel, Tony Lu

From: Bryam Vargas <hexlabsecurity@proton.me>

smcr_lgr_reg_rmbs() skips the MR registration (its fast path) when the
RMB is registered on every active link, but the check reads is_reg_mr[]
at the index of the connection's link for each link it walks. An RMB
that sits unused in the pool when a link is added is not registered on
that link. A later connection on the older link that reuses it takes
the fast path, never registers it on the newer link, and its
CONFIRM_RKEY still gives the peer an rkey for that link. After a
failover to the newer link, the peer's RDMA writes into the RMB fail
with a remote access error, that link goes down too and, with no other
link left, the link group is terminated.

Read is_reg_mr[] at each active link's own index, so the fast path is
taken only when the RMB is registered on all of them.

Fixes: 4da687448de7 ("net/smc: reduce unnecessary blocking in smcr_lgr_reg_rmbs()")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
Repro on SMC-Rv2 with soft-RoCE (rxe) over two veth pairs between two
namespaces. The link group starts with one link, and the second link
comes up only after the first connection is closed and its RMBs are
back in the pools. A second connection on the first link then takes
those RMBs, and the server's rxe device for the first link is removed.

Unpatched, the client's first RDMA write over the second link completes
with IB_WC_REM_ACCESS_ERR, the second link goes down and the link
groups on both sides are terminated; the server reads EOF. Patched, the
connection survives the failover and the data checks out in both
directions. A connection that gets a new RMB survives the failover with
and without the patch, and one placed on the second link that reuses
the RMBs takes the slow path in both builds (read from debug counters
added to smc.ko for the test). No KASAN splat in any run.
---
 net/smc/af_smc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index bfc0c7e71a12..53ee0f4afc11 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -581,7 +581,7 @@ static int smcr_lgr_reg_rmbs(struct smc_link *link,
 	for (i = 0; i < SMC_LINKS_PER_LGR_MAX; i++) {
 		if (!smc_link_active(&lgr->lnk[i]))
 			continue;
-		if (!rmb_desc->is_reg_mr[link->link_idx]) {
+		if (!rmb_desc->is_reg_mr[lgr->lnk[i].link_idx]) {
 			up_read(&lgr->llc_conf_mutex);
 			goto slow_path;
 		}

---
base-commit: ead6fa9a0ab194f02a2f36d634b193e9c5f9a1c6
change-id: 20261113-b4-disp-08835f86-e769a35d475b

Best regards,
--  
Bryam Vargas <hexlabsecurity@proton.me>



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-11-13 19:17 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-13 19:11 [PATCH net] net/smc: check every link before skipping the RMB registration Bryam Vargas via B4 Relay
2026-11-13 19:17 ` netdev-bot+sinfo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®