[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B8E7357.5050203@trash.net>
Date: Wed, 03 Mar 2010 15:33:59 +0100
From: Patrick McHardy <kaber@...sh.net>
To: Timo Teräs <timo.teras@....fi>
CC: netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] ipv4: flush ARP entries on device change
Timo Teräs wrote:
> Patrick McHardy wrote:
>> Timo Teras wrote:
>>> If device flag IFF_NOARP is changed, we should flush the ARP cache as
>>> all
>>> entries need to get refreshed.
>>>
>>> Signed-off-by: Timo Teras <timo.teras@....fi>
>>> ---
>>> net/ipv4/arp.c | 3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
>>> index c4dd135..036da92 100644
>>> --- a/net/ipv4/arp.c
>>> +++ b/net/ipv4/arp.c
>>> @@ -1245,6 +1245,9 @@ static int arp_netdev_event(struct
>>> notifier_block *this, unsigned long event, vo
>>> neigh_changeaddr(&arp_tbl, dev);
>>> rt_cache_flush(dev_net(dev), 0);
>>> break;
>>> + case NETDEV_CHANGE:
>>> + neigh_changeaddr(&arp_tbl, dev);
>>> + break;
>>
>> It would be nice if we could restrict this to IFF_NOARP changes.
>
> Yes. But I did not see any easy way to figure out which flags have changed.
>
> Should we just keep a copy of the previous IFF_NOARP bit somewhere
> (where?).
> Or did I miss something obvious?
We shouldn't have any arp entries for devices with IFF_NOARP set,
so perhaps we can flush only in that case. The transition IFF_NOARP
-> ~IFF_NOARP shouldn't need flushing.
--
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