On (05/30/17 18:42), David Ahern wrote:
> It has been noticed. I have not sent a patch since adjusting gc
> parameters will reclaim FAILED entries at whatever rate the user wants.
Overly aggressive garbage collection will delete other (non-FAILED)
entries as well, and can trigger needless re-ARP
On 5/30/17 5:32 PM, Sowmini Varadhan wrote:
> On (05/30/17 16:20), Stephen Hemminger wrote:
>>
>> Please don't copy/paste chunks of code. Instead refactor and make this
>> into a helper function.
>
> sure, I have no problems with that, and as I pointed out, I've not
> tested ipv6 for this yet
On (05/30/17 16:20), Stephen Hemminger wrote:
>
> Please don't copy/paste chunks of code. Instead refactor and make this
> into a helper function.
sure, I have no problems with that, and as I pointed out, I've not
tested ipv6 for this yet either. I'll do all of this after getting
some feedback
On Mon, 29 May 2017 20:48:16 -0700
Sowmini Varadhan wrote:
> + np = >hash_buckets[hash_val];
> + while ((n = rcu_dereference_protected(*np,
> + lockdep_is_held(>lock))) != NULL) {
> + write_lock(>lock);
> +
Noticed during some testing: the command
# arp -s 62.2.0.1 a:b:c:d:e:f dev eth2
adds an entry like the following (listed by "arp -an")
? (62.2.0.1) at 0a:0b:0c:0d:0e:0f [ether] PERM on eth2
but the symmetric deletion command
# arp -i eth2 -d 62.2.0.1
does not remove the PERM entry from the