netdev - Re: [PATCH] neighbour.c: Avoid GC directly after state change

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Apr 2015 19:46:59 +0900
From:	YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com>
To:	Ulf Samuelsson <ulf.samuelsson@...csson.com>, netdev@...gii.com
CC:	hideaki.yoshifuji@...aclelinux.com, netdev@...r.kernel.org
Subject: Re: [PATCH] neighbour.c: Avoid GC directly after state change

Ulf Samuelsson wrote:
> 
> On 04/21/2015 05:58 AM, YOSHIFUJI Hideaki wrote:
>> Ulf Samuelsson wrote:
>>>> How many neighbors do you want to maintain?
>>>> I guess you have to increase the number of gc_thresh1.
>>> The current use cases have up to 2048 entries.
>>> This is expected to grow in the future.
>>> The 3.4 kernel used in the system today is limited to 1024,
>>> but that has been raised to about 10k.
>>>
>>> The gc_thresh1 test is not implemented in 3.4 but can be backported,
>>> but still not convinced it is a good idea.
>> Why?
>>
> A good solution makes sure that:
> * equipment which is connected NEVER IS garbage collected
> * equipment which is disconnected IS garbage collected.
> 
> The threshold idea does not meet the criteria for a good solution.

We try providing "good solution" if you have less than gc_thresh1
entries only.  Otherwise, we try hard to protect ourselves.


> With this solution you keep unnecessary entries in the table.
> If you ever pass the limit, then equipment which should not
> be garbage collected may be.
> It relies on someone keeping track of traffic loss,
> so needs more maintenance by the SysOp.try pr
> 
> The ARP probes should be considered to be NECESSARY traffic
> to maintain a quality link.
> Obviously not everyone would want to make this trade-off.
> 
> 
>>> To complicate things, one requirement is that for some interfaces
>>> you always want to keep things alive, if connected, but
>>> for other interfaces you want things to be removed
>>> to conserve memory.
>>> Actually you would want to do this selection on a subnet level.
>> If you want to introduce per-interface parameter, I am okay with it.
>>
>>> Internal discussions resulted in a proposal to change the patch,
>>> so that you have a "keepalive" flag which is tested after
>>> it has been decided to exit the REACHABLE state.
>>>
>>> if the "keepalive" flag is set, you always go to DELAY state from REACHABLE.
>> No.
>>
> And why is it a bad idea to have a high quality connection?

We reclaim neighbor entries as much as possible to protect
ourselves if the number is below gc_thresh1.  We could stop
purging entries, but the idea was rejected AFAIK.  That is
our design.

Again, you should increase gc_thresh1, first.

-- 
Hideaki Yoshifuji <hideaki.yoshifuji@...aclelinux.com>
Technical Division, MIRACLE LINUX CORPORATION
--
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