From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 52BB02652AF for ; Mon, 15 Jun 2026 17:46:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781545583; cv=none; b=DUzAhoLxbfpOQh7PEm4D8IfOibMvpRWLGI+tnDUwWkcZ2Os3WYttxOAoPup+hBh93OAz+r1oUx9NzMYupHpOLhouow+Ww+3drx2zhTO+lnnHwigxDd1DYXiwFNyGwX/BsLWrfk0rbJlk8Z4dc+MnTqx1sQOiaMexLv9wMe9EFsk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781545583; c=relaxed/simple; bh=6FChuiiY1Ab4DoQ0VIjmNXOowo/9a9Qo6Y6YIXFBBsw=; h=From:Subject:Date:To:Cc:Message-ID:In-Reply-To:References; b=btZMuPUZrlXCV1i5bhusfVTP+8igYrvyrNI3xnA/ILQwEFpJz1JoHFxnj8d8tTdzTsPE1/v8RVqUbWK6P/Wvg5lH09ns3jEeNJ+cThsGcuIVS6cruh/LJ6lY2v2i7wMea/4DkPnhxsj4F5wRwhwrvvtCZH2SR0xcl4I6YU8Ng0o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ankey.net; spf=none smtp.mailfrom=ankey.net; dkim=pass (2048-bit key) header.d=ankey-net.20251104.gappssmtp.com header.i=@ankey-net.20251104.gappssmtp.com header.b=pa4XmYcx; arc=none smtp.client-ip=209.85.210.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ankey.net Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ankey.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ankey-net.20251104.gappssmtp.com header.i=@ankey-net.20251104.gappssmtp.com header.b="pa4XmYcx" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-8422f395a4aso2433439b3a.0 for ; Mon, 15 Jun 2026 10:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ankey-net.20251104.gappssmtp.com; s=20251104; t=1781545582; x=1782150382; darn=vger.kernel.org; h=references:in-reply-to:message-id:cc:to:date:subject:from:from:to :cc:subject:date:message-id:reply-to; bh=EM3udb0oDgJN3cKMNmux7YsMkV9lDzcITmGFkVGmGqE=; b=pa4XmYcxUADAHuHOG3K+8NWlvTj24h7N/JrEGIWqgFjPaNqTt8HiBJ+eoGjulX/tUt +GUNCsQTohhqIdY5rMnCUWZ2ekPSoktw03uR919hD+dEbcbTsaITMxciZoi9m5eecfvY dficIhVifwvF3fTY9VW7a4+h9lHFkys+yMnbSaBCs3FyENYYY55zELXDODf0bUhEBvbj syVrsfj/eZDyPVndaVB0NdpPF/d2ipaPG3vFycXzQsPYHQzE+HXtwD8/FZpywpdM8O5C 4UEIHFQNqxOXUo3tP8E8smAzX1qCU/5nGX3B0iElMJ49cN//YnqkHYF6e5ptCX8Ytbvq 0OUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781545582; x=1782150382; h=references:in-reply-to:message-id:cc:to:date:subject:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EM3udb0oDgJN3cKMNmux7YsMkV9lDzcITmGFkVGmGqE=; b=OykDrM5gLCkG0BGmR0GlMmI6cRxWWfUSDO8Gcf0g+A3A1AP05r4Iktia2QUDKzVYXr zohvTdY/zkZDjKtTNbEzgC88ngvjM6IRsrJHwxVx4VzjiOO+Ew+KytDPiJHCKx6p6rsJ gace1Zod5HK3dV0xHzmzEXaeooGbUgOT2dks4/2RSLOnjPCP2DMapdiKx/viANOQiHCm EcqxjNlqC9s9f8kK3ZaJzXy9h9yHPUjTAFmXQxuNbob4yn5b+bXsvAEhH62340Wm7Vwb fpOHrPj78A6CGVQoFdENmUsCrq+dMmDFa3B6Ogeo7JPe7kZ+zCAL5J8PiuBU4stDN0/9 LEqg== X-Forwarded-Encrypted: i=1; AFNElJ8IbODGG0Ga3l96GFir25Wm+J8P1QzxTw/WSolL5Tp2/UgvXjlpmqEz27F4dohJZkdbNd9sqtTWPAufRcA=@vger.kernel.org X-Gm-Message-State: AOJu0YwhzJoPPq3Y5lp9rsbq5lx2skygqhIbnuHgdy9TNDVgGBdQqVSo DMtD952XGZczy8IzCWtS9i/tCxe3e9RLTnBCKaod/LEeTWtNdqsV2fxyvsJNrQmcLA== X-Gm-Gg: Acq92OH+kjOtDL+NG2zqlJI8rgstxOl6m74TaZr4Q/jEA3/jVG/s/MQt8s091bZMxvv YBIrdFyLOQOQUt151Aw/700/pTUcnPwXEY8EcTIaGGyKpRus2Iuk8va8dxUak7eJPQEcKRrViCe R0PoJUhfGZptHrr8JXmLhsoeEeMTbqnvPUhFVGuvE24/oRGl0wVUo2kPMGz/0eM2a+lGSHKmvPo Ja/qA73sXMN80jE/VG9tmdLf2Owt1R+NqeGSQK3r3oa+rjYI+aFhr6URbdBYap0QM61q93NcxqA 04aJJx1G8UMoW0E/9OLaXc5/wbMPObizzVxrpFHXvdPRGX6lfxlhQxnEYCF2jR8HZB69IXKC+9Z AnliwMrEmkf7P8vvqI9Dn398FDi2g6E9Sh3e+wif2IGPUfJj/AroXcL/I3APfKN40wpJ9p6AqfI GE3oBaZ0V5V6wAMU+EEZzMT4lP4CfIIgptgVL/eIyQwwVvOWv9uERaD9iISOkfYyAk8d7MiblfH Wzo5HQUl1uzGBz9numkxqTc4TVJILMH70ll X-Received: by 2002:a05:6a00:813:b0:842:614b:50e1 with SMTP id d2e1a72fcca58-84513e3c998mr348207b3a.12.1781545581724; Mon, 15 Jun 2026 10:46:21 -0700 (PDT) Received: from atimofey-ld1.linkedin.biz ([52.149.25.61]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-8434accae18sm11214086b3a.17.2026.06.15.10.46.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2026 10:46:21 -0700 (PDT) From: Alex Timofeyev Subject: [PATCH rdma-next v1 1/2] RDMA/core: use destination netdev MAC for cross-NIC same-host local dst Date: Mon, 15 Jun 2026 17:46:19 +0000 To: Jason Gunthorpe , Leon Romanovsky , linux-rdma@vger.kernel.org Cc: Parav Pandit , Edward Srouji , Vlad Dumitrescu , stable@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: <1781545579.2-sashka@ankey.net> In-Reply-To: <1781545579.1-sashka@ankey.net> References: <1781545579.1-sashka@ankey.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: addr_resolve_neigh() treats every is_dst_local() destination as loopback and copies the source device's MAC into the path record's destination MAC (dst_dev_addr <- src_dev_addr). That is correct for true loopback (source and destination on the same netdev), but wrong when the local destination address lives on a different netdev of the same host. In that cross-NIC same-host case the destination NIC will not accept a frame whose destination MAC is the source NIC's MAC, and drops it in hardware before it reaches the peer. rdma_resolve_addr() and ib_send_cm_req() both return success, but the CM REQ never arrives and the connection times out. Look up the netdev that owns the destination address and copy its MAC into dst_dev_addr instead. Fall back to the source MAC when no netdev claims the address (true loopback), preserving the existing behaviour. This was observed with two RoCEv2 ConnectX-7 ports on the same host, each holding a global IPv6 GID, when one process pinned per NUMA NIC connected to the other over RDMA-CM: the resolved destination MAC was the source port's MAC instead of the destination port's, and the REQ was silently dropped. With the fix the resolved MAC is the destination port's and the connection completes. Fixes: c31e4038c97f ("RDMA/core: Use route entry flag to decide on loopback traffic") Cc: stable@vger.kernel.org Cc: Parav Pandit Signed-off-by: Alex Timofeyev --- drivers/infiniband/core/addr.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c index 7e62b5b1ffaa..84aa43436bfe 100644 --- a/drivers/infiniband/core/addr.c +++ b/drivers/infiniband/core/addr.c @@ -451,10 +451,26 @@ static int addr_resolve_neigh(const struct dst_entry *dst, u32 seq) { if (is_dst_local(dst)) { - /* When the destination is local entry, source and destination - * are same. Skip the neighbour lookup. + struct net_device *dst_ndev; + + /* When the destination is local, source and destination are on + * the same host. For true loopback (same netdev) the source and + * destination MACs are equal, but when the destination address + * lives on a different netdev of the same host the destination + * MAC must be that netdev's MAC -- otherwise the destination NIC + * silently drops the frame. Look up the netdev that owns the + * destination address and copy its MAC; fall back to the source + * MAC if no netdev claims the address. */ - memcpy(addr->dst_dev_addr, addr->src_dev_addr, MAX_ADDR_LEN); + rcu_read_lock(); + dst_ndev = rdma_find_ndev_for_src_ip_rcu(dev_net(dst->dev), dst_in); + if (!IS_ERR(dst_ndev)) + memcpy(addr->dst_dev_addr, dst_ndev->dev_addr, + MAX_ADDR_LEN); + else + memcpy(addr->dst_dev_addr, addr->src_dev_addr, + MAX_ADDR_LEN); + rcu_read_unlock(); return 0; } -- 2.40.4