netdev - Re: [net PATCH 2/2] ipv4: Drop suffix update from resize code

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] [day] [month] [year] [list]

Message-ID: <e78286e1-18eb-e900-bb65-a00c5611263c@brocade.com>
Date:   Mon, 5 Dec 2016 19:27:38 +0000
From:   Robert Shearman <rshearma@...cade.com>
To:     David Miller <davem@...emloft.net>
CC:     <alexander.h.duyck@...el.com>, <netdev@...r.kernel.org>
Subject: Re: [net PATCH 2/2] ipv4: Drop suffix update from resize code

On 05/12/16 17:28, David Miller wrote:
> From: Robert Shearman <rshearma@...cade.com>
> Date: Mon, 5 Dec 2016 15:05:18 +0000
>
>> On 01/12/16 12:27, Alexander Duyck wrote:
>>> It has been reported that update_suffix can be expensive when it is
>>> called
>>> on a large node in which most of the suffix lengths are the same.  The
>>> time
>>> required to add 200K entries had increased from around 3 seconds to
>>> almost
>>> 49 seconds.
>>>
>>> In order to address this we need to move the code for updating the
>>> suffix
>>> out of resize and instead just have it handled in the cases where we
>>> are
>>> pushing a node that increases the suffix length, or will decrease the
>>> suffix length.
>>>
>>> Fixes: 5405afd1a306 ("fib_trie: Add tracking value for suffix length")
>>> Reported-by: Robert Shearman <rshearma@...cade.com>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@...el.com>
>>
>> $ time sudo ip route restore < ~/allroutes
>> RTNETLINK answers: File exists
>> RTNETLINK answers: File exists
>> RTNETLINK answers: File exists
>> RTNETLINK answers: File exists
>
> What are these errors all about?

These are just routes that are already added by the system but are 
present in the dump:

$ ip route showdump < ~/allroutes | grep -v 110.110.110.2
default via 192.168.100.1 dev eth0  proto static  metric 1024
10.37.96.0/20 dev eth2  proto kernel  scope link  src 10.37.96.204
110.110.110.0/24 dev eth1  proto kernel  scope link  src 110.110.110.1
192.168.100.0/24 dev eth0  proto kernel  scope link  src 192.168.100.153

So the errors are expected and are seen both with and without these patches.

Thanks,
Rob