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]

Message-ID: <55346580.6060801@miraclelinux.com>
Date:	Mon, 20 Apr 2015 11:33:36 +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

Hi,

Ulf Samuelsson wrote:
>>  From RFC2461:
>>
>> |      REACHABLE   Roughly speaking, the neighbor is known to have been
>> |                  reachable recently (within tens of seconds ago).
>> :
>> |      STALE       The neighbor is no longer known to be reachable but
>> |                  until traffic is sent to the neighbor, no attempt
>> |                  should be made to verify its reachability.
>> |      DELAY       The neighbor is no longer known to be reachable, and
>> |                  traffic has recently been sent to the neighbor.
>> |                  Rather than probe the neighbor immediately, however,
>> |                  delay sending probes for a short while in order to
>> |                  give upper layer protocols a chance to provide
>> |                  reachability confirmation.
>>
>>
> 
> It is all depending on the meaning of the word "recently".
> You imply, that if timeouts have been triggered, then it is no longer "recent",
> but that is not the only interpretation, it is up to the implementer to decide
> what is "recently".

That quoted text is just a "brief" description.  The document has detailed
state machine.


> Therefore, if a timeout occurs due to no traffic, they must be probed before
> they are garbage collected.

It is what we do in PROBE state.


> If this is not acceptable, how do you propose to solve the problem that you cannot
> make remote units inaccessible for more than a fraction of a second?

How many neighbors do you want to maintain?
I guess you have to increase the number of gc_thresh1.

-- 
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