On 12/9/18 10:12 PM, Eric Dumazet wrote:
> What protects gc_list linkage ?
Yes, I found this yesterday morning as well: the list_add_tail in
neigh_alloc needs to be moved to ___neigh_create. Internet to our lab
has been knocked out for a while now; I will send a patch when I can.
Eric Dumazet wrote:
>
>
> On 12/07/2018 04:03 PM, David Miller wrote:
> > From: David Ahern
> > Date: Fri, 7 Dec 2018 12:24:57 -0800
> >
> >> From: David Ahern
> >>
> >> The existing garbage collection algorithm has a number of problems:
> > ...
> >> This patch addresses these problems as fo
On 12/09/2018 09:12 PM, Eric Dumazet wrote:
> What protects gc_list linkage ?
>
> We can not use list_del_init(&n->gc_list);or
>list_add_tail(&n->gc_list, &n->tbl->gc_list);
>
> if tbl->lock is not held.
>
> It seems to me this patch needs more care.
>
On 12/07/2018 04:03 PM, David Miller wrote:
> From: David Ahern
> Date: Fri, 7 Dec 2018 12:24:57 -0800
>
>> From: David Ahern
>>
>> The existing garbage collection algorithm has a number of problems:
> ...
>> This patch addresses these problems as follows:
>>
>> 1. Use of a separate list_he
From: David Ahern
Date: Fri, 7 Dec 2018 12:24:57 -0800
> From: David Ahern
>
> The existing garbage collection algorithm has a number of problems:
...
> This patch addresses these problems as follows:
>
> 1. Use of a separate list_head to track entries that can be garbage
>collected alon
From: David Ahern
The existing garbage collection algorithm has a number of problems:
1. The gc algorithm will not evict PERMANENT entries as those entries
are managed by userspace, yet the existing algorithm walks the entire
hash table which means it always considers PERMANENT entries whe
