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, 18 Mar 2015 10:56:44 +0900
From:	YOSHIFUJI Hideaki/吉藤英明 
	<hideaki.yoshifuji@...aclelinux.com>
To:	Ulf Samuelsson <netdev@...gii.com>,
	David Miller <davem@...emloft.net>
CC:	hideaki.yoshifuji@...aclelinux.com, netdev@...r.kernel.org
Subject: Re: [PATCH] neighbour.c: Avoid GC directly after state change

Hi,

Ulf Samuelsson wrote:
> Den 2015-03-12 19:26, David Miller skrev:
>> I hate changes like this.
>>
>> By making this a Kconfig options it cannot be dynamic, and every
>> distribution is going to have to scratch their head and decide
>> what to set this to.
>>
>> That's seriously suboptimal.
>>
>> If you want to change behavior based upon whether userspace is
>> managing the damn table, make it so the user doing so has to
>> ask for the new behavior at _RUN TIME_ via the netlink interface
>> or similar.
>>
>> Picking the guard time itself at compile time is also undesirable.
>>
>> And you don't even want a damn timer, what you want is for the
>> state of the entry to be frozen and for the user to "release"
>> it by either adjusting the state to something else or marking
>> in some other way to allow it to be unfrozen and released again.
>>
>> Why put it to chance with some timeout?  Make things explicit.
>>
>> I'm not applying this patch.
:
> Sounds reasonable comments to me.
>
> Would this approach work?
>
> 2 new message types are defined, to enable/disable the garbage
> collection functionality.
>
> RTM_ENANEIGHGC
> RTM_DISANEIGHGC
>
>
> When the functionality is disabled, the stack will not garbage collect,
> and the external application will have to send netlink messages
> to delete unwanted entries.
>
> 1 new message is defined to move an entry from STALE to DELAY.
> RTM_NEIGHRECOVER

Why don't you "explicitly" set the neighbour, or mark the neighbour
entry as PERMANENT via netlink when you recognized that the entry
has become REACHABLE, then?

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