netdev - Re: [PATCH net-next 1/8] rtnetlink: Do not generate notifications for MTU events

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: <e3765283-f5e5-1f85-2762-b7b99f99bd1a@cumulusnetworks.com>
Date:   Sat, 8 Apr 2017 22:58:44 -0400
From:   David Ahern <dsa@...ulusnetworks.com>
To:     vyasevic@...hat.com, netdev@...r.kernel.org
Cc:     davem@...emloft.net
Subject: Re: [PATCH net-next 1/8] rtnetlink: Do not generate notifications for
 MTU events

On 4/8/17 9:36 PM, Vlad Yasevich wrote:
> On 04/07/2017 05:25 PM, David Ahern wrote:
>> Changing MTU on a link currently causes 3 messages to be sent to userspace:
>>
>> [LINK]11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1490 qdisc noqueue state UNKNOWN group default event PRE_CHANGE_MTU
>>     link/ether f2:52:5c:6d:21:f3 brd ff:ff:ff:ff:ff:ff
>>
>> [LINK]11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default event CHANGE_MTU
>>     link/ether f2:52:5c:6d:21:f3 brd ff:ff:ff:ff:ff:ff
>>
>> [LINK]11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
>>     link/ether f2:52:5c:6d:21:f3 brd ff:ff:ff:ff:ff:ff
>>
>> Remove the PRE_CHANGE_MTU and CHANGE_MTU messages.
> Actually, I have plans for the CHANGE_MTU event.  The last message is not an event. If you
> remove the event, it is much harder to track mtu changes.

it is a set of redundant messages. Roopa suggested using a bitmask for
the events changed by do_setlink which gets added to the last message
seen above. In doing so you only generate 1 message. The above causes
libnl (for example):

- message 1: delete dummy1 from its cache and re-create it
- message 2: delete dummy1 from its cache and re-create it
- message 3: delete dummy1 from its cache and re-create it

All you need is a single message at the end with an attribute that says
"MTU changed"