On 02/12/15(Wed) 09:26, Stuart Henderson wrote: > On 2015/12/02 09:44, Martin Pieuchot wrote: > > If the kernel tries to create (cloned) an ARP entry and found an > > existing conflicting route, do not try to be clever and just bail. > > > > I'm fine with rtalloc(9) taking the KERNEL_LOCK when cloning an entry > > but I'd prefer the ARP layer to not try to delete anything in the hot > > path. > > > > If you entered a conflicting entry in your routing table, that's your > > problem, you deal with it. > > > > Ok? > > Just trying to think it through a bit: > > Where are these conflicting routes going to come from, if you already have > a RTF_GATEWAY route it's not going to need to ARP for that address is it? > Is this something to do with ICMP redirects? > > It would be nice to recreate the conditions that cause it to make sure that > this doesn't result in an ARP storm if the new entry can't be added and we > keep on trying to resolve it.
But the entry *is* added, just from a wrong RTF_CLONING route. It's easy to reproduce, you can simply do: # route add 192.168.0/24 -cloning -gateway 192.168.0.5 -priority 3 Assuming that 192.168.0/24 is already your cloning route. After cleaning your ARP cache you'll still get RTF_CLONED routes from this higher priority route and this code below won't solve anything because they're still being recreated.
