[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1369153519.2615.3.camel@bwh-desktop.uk.solarflarecom.com>
Date: Tue, 21 May 2013 17:25:19 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Timo Teräs <timo.teras@....fi>
CC: David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>,
<kaber@...sh.net>
Subject: Re: [PATCH v2 net-next] arp: flush arp cache on IFF_NOARP change
On Tue, 2013-05-21 at 13:23 +0300, Timo Teräs wrote:
> IFF_NOARP affects what kind of neighbor entries are created
> (nud NOARP or nud INCOMPLETE). If the flag changes, flush the arp
> cache to refresh all entries.
>
> Signed-off-by: Timo Teräs <timo.teras@....fi>
> ---
> > This patch makes no sense at all.
> >
> > The state bit in ->priv_flags is a boolean stating whether the
> > notified should do something or not.
> >
> > But you're setting it to match what IFF_NOARP is.
> >
> > You should set it any time IFF_NOARP _changes_, and then clear
> > the bit when the notifier clears the neighbour entries.
>
> IFF_NOARP_CHANGED is set according to "changes = dev->flags ^ old_flags;"
> which reflect the change. But I agree that the clearing out bit was
> misplaced. This is especially true as it seems NETDEV_CHANGE can be
> notified from another place too.
[...]
None of the other persistent flags have a transient flag for changes;
why should IFF_NOARP? Why not cache the IFF_NOARP state in the
in_device and then compare and update that in arp_netdev_event().
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists