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

Powered by blists - more mailing lists