[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170515.140832.354922796595622860.davem@davemloft.net>
Date: Mon, 15 May 2017 14:08:32 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: ihrachys@...hat.com
Cc: jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
netdev@...r.kernel.org
Subject: Re: [PATCH] arp: honour gratuitous ARP _replies_
From: Ihar Hrachyshka <ihrachys@...hat.com>
Date: Tue, 9 May 2017 17:16:07 -0700
> @@ -842,8 +844,20 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
> It is possible, that this option should be enabled for some
> devices (strip is candidate)
> */
> - is_garp = arp->ar_op == htons(ARPOP_REQUEST) && tip == sip &&
> - addr_type == RTN_UNICAST;
> + is_garp = tip == sip && addr_type == RTN_UNICAST;
> +
> + /* Unsolicited ARP _replies_ also require target hwaddr to be
> + * the same as source.
> + */
> + if (is_garp && arp->ar_op == htons(ARPOP_REPLY))
> + is_garp =
> +#if IS_ENABLED(CONFIG_FIREWIRE_NET)
> + /* IPv4 over IEEE 1394 doesn't provide target
> + * hardware address field in its ARP payload.
> + */
> + tha &&
> +#endif
> + !memcmp(tha, sha, dev->addr_len);
>
The ifdefs here make the test harder to understand.
I would suggest removing the ifdef and letting the compiler remove the 'tha'
check if it can.
Thank you.
Powered by blists - more mailing lists