netdev - Re: [PATCH net-next v2] net: ipmr/ip6mr: add support for keeping an entry age

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:	Fri, 15 Jul 2016 23:11:15 -0700
From:	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:	David Miller <davem@...emloft.net>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	roopa@...ulusnetworks.com, shm@...ulusnetworks.com,
	sashok@...ulusnetworks.com, sharpd@...ulusnetworks.com,
	kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net
Subject: Re: [PATCH net-next v2] net: ipmr/ip6mr: add support for keeping an entry age


> On Jul 15, 2016, at 10:56 PM, David Miller <davem@...emloft.net> wrote:
> 
> From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
> Date: Thu, 14 Jul 2016 19:28:27 +0300
> 
>> In preparation for hardware offloading of ipmr/ip6mr we need an
>> interface that allows to check (and later update) the age of entries.
>> Relying on stats alone can show activity but not actual age of the entry,
>> furthermore when there're tens of thousands of entries a lot of the
>> hardware implementations only support "hit" bits which are cleared on
>> read to denote that the entry was active and shouldn't be aged out,
>> these can then be naturally translated into age timestamp and will be
>> compatible with the software forwarding age. Using a lastuse entry doesn't
>> affect performance because the members in that cache line are written to
>> along with the age.
>> Since all new users are encouraged to use ipmr via netlink, this is
>> exported via the RTA_EXPIRES attribute.
>> Also do a minor local variable declaration style adjustment - arrange them
>> longest to shortest.
>> 
>> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
>> CC: Roopa Prabhu <roopa@...ulusnetworks.com>
>> CC: Shrijeet Mukherjee <shm@...ulusnetworks.com>
>> CC: Satish Ashok <sashok@...ulusnetworks.com>
>> CC: Donald Sharp <sharpd@...ulusnetworks.com>
>> CC: David S. Miller <davem@...emloft.net>
>> CC: Alexey Kuznetsov <kuznet@....inr.ac.ru>
>> CC: James Morris <jmorris@...ei.org>
>> CC: Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
>> CC: Patrick McHardy <kaber@...sh.net>
>> ---
>> v2: Just reuse RTA_EXPIRES instead to minimize the attr size and simplify,
>> others will be added when needed
> 
> Why are your dates on these changes in the past?
> 
> Having them in the past messes up the ordering on patchwork because
> patchwork orders incoming patches by date, and therefore I can't just
> look at the first page to see "newer" submissions.
> 
> So please don't do whatever propagates commit dates into your emails,
> or whatever is causing this problem.  It's best always to use the
> current time.

Hmm, it seems my VM has its time zone messed up and since I’m in California right now the dates
come out wrong. Sorry about that, would you like me to resubmit the patch ?

Thanks,
 Nik