linux-kernel - Re: [PATCH 2/4] RDMA/core: Resolve MAC of next-hop device without ARP support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <09b53dc4-79b2-4933-abcb-4b414860cea0@nvidia.com>
Date: Mon, 15 Sep 2025 10:16:20 -0700
From: Parav Pandit <parav@...dia.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Leon Romanovsky <leon@...nel.org>, Edward Srouji <edwards@...dia.com>,
 "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Cosmin Ratiu <cratiu@...dia.com>, Vlad Dumitrescu <vdumitrescu@...dia.com>,
 "kuba@...nel.org" <kuba@...nel.org>, Tariq Toukan <tariqt@...dia.com>,
 Mark Bloch <mbloch@...dia.com>, Gal Pressman <gal@...dia.com>
Subject: Re: [PATCH 2/4] RDMA/core: Resolve MAC of next-hop device without ARP
 support


On 15-09-2025 09:30 am, Jason Gunthorpe wrote:
> On Wed, Sep 10, 2025 at 10:55:36AM +0000, Parav Pandit wrote:
>>>> This leads to incorrect behavior and may result in packet transmission
>>> failures.
>>>> Fix this by deferring MAC resolution to the IP stack via neighbour
>>>> lookup, allowing proper resolution or error reporting as appropriate.
>>> What is the difference here? For IPv4, neighbour lookup is ARP, no?
>> It is but it is not the only way. A device may not do ARP by itself but it relies on the rest of the stack like vrf or ip vlan mode to resolve.
>> A user may also set manual entry without explicit ARP.
> I think it was just a mistake to use NOARP this way in RDMA, I looked
> in the git history and there was no justification. That or it was
> right in the 2.x days and netdev moved on to the current schem.
>
> I expect to just call the neighbor functions and if they can't work
> for some reason they should fail?
>
> Jason

Right. This is the patch does, to rely on the neighbour functions to 
resolve without depending on the NOARP.