On Sun, Sep 07, 2025 at 07:08:31PM +0300, Edward Srouji wrote:
> From: Parav Pandit <parav@xxxxxxxxxx>
>
> 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).
> 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?
>
> Fixes: 7025fcd36bd6 ("IB: address translation to map IP toIB addresses (GIDs)")
> Signed-off-by: Parav Pandit <parav@xxxxxxxxxx>
> Reviewed-by: Vlad Dumitrescu <vdumitrescu@xxxxxxxxxx>
> Signed-off-by: Edward Srouji <edwards@xxxxxxxxxx>
> ---
> 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
>
