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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <CY8PR12MB71954BE7258390B4B7965E8FDC0EA@CY8PR12MB7195.namprd12.prod.outlook.com>
Date: Wed, 10 Sep 2025 10:55:36 +0000
From: Parav Pandit <parav@...dia.com>
To: Leon Romanovsky <leon@...nel.org>, Edward Srouji <edwards@...dia.com>
CC: "jgg@...pe.ca" <jgg@...pe.ca>, "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


> From: Leon Romanovsky <leon@...nel.org>
> Sent: 10 September 2025 02:02 PM
> 
> On Sun, Sep 07, 2025 at 07:08:31PM +0300, Edward Srouji wrote:
> > From: Parav Pandit <parav@...dia.com>
> >
> > Currently, if the next-hop netdevice does not support ARP resolution,
> > the destination MAC address is silently set to zero without reporting
> > an error.
> 
> Not an expert here, but from my understanding this is right behavior.
> IFF_NOARP means "leave" MAC address as is (zero).
>
Not really.
In the example of the VRF, the device does not resolve the ARP itself, but it's the enslaved device which resolves the neighbour.
Some ip vlan l2 devices do not do arp internally but depends on the bridge/stack to resolve.


> > 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.

> 
> >
> > Fixes: 7025fcd36bd6 ("IB: address translation to map IP toIB addresses
> > (GIDs)")
> > Signed-off-by: Parav Pandit <parav@...dia.com>
> > Reviewed-by: Vlad Dumitrescu <vdumitrescu@...dia.com>
> > Signed-off-by: Edward Srouji <edwards@...dia.com>
> > ---
> >  drivers/infiniband/core/addr.c | 10 +++-------
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/infiniband/core/addr.c
> > b/drivers/infiniband/core/addr.c index 594e7ee335f7..ca86c482662f
> > 100644
> > --- a/drivers/infiniband/core/addr.c
> > +++ b/drivers/infiniband/core/addr.c
> > @@ -454,14 +454,10 @@ static int addr_resolve_neigh(const struct
> > dst_entry *dst,  {
> >  	int ret = 0;
> >
> > -	if (ndev_flags & IFF_LOOPBACK) {
> > +	if (ndev_flags & IFF_LOOPBACK)
> >  		memcpy(addr->dst_dev_addr, addr->src_dev_addr,
> MAX_ADDR_LEN);
> > -	} else {
> > -		if (!(ndev_flags & IFF_NOARP)) {
> > -			/* If the device doesn't do ARP internally */
> > -			ret = fetch_ha(dst, addr, dst_in, seq);
> > -		}
> > -	}
> > +	else
> > +		ret = fetch_ha(dst, addr, dst_in, seq);
> >  	return ret;
> >  }
> >
> > --
> > 2.21.3
> >