netdev - Re: [PATCH net-next 5/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs

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, 16 Mar 2016 15:49:11 +0100
From:	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:	Xin Long <lucien.xin@...il.com>
Cc:	network dev <netdev@...r.kernel.org>, davem <davem@...emloft.net>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>
Subject: Re: [PATCH net-next 5/6] bridge: a netlink notification should be
 sent when those attributes are changed by br_sysfs_if

On 03/16/2016 03:45 PM, Xin Long wrote:
> On Wed, Mar 16, 2016 at 10:23 PM, Nikolay Aleksandrov
> <nikolay@...ulusnetworks.com> wrote:
>> On 03/16/2016 02:34 PM, Xin Long wrote:
>>> Now when we change the attributes of bridge or br_port by netlink,
>>> a relevant netlink notification will be sent, but if we change them
>>> by ioctl or sysfs, no notification will be sent.
>>>
>>> We should ensure that whenever those attributes change internally or from
>>> sysfs/ioctl, that a netlink notification is sent out to listeners.
>>>
>>> Also, NetworkManager will use this in the future to listen for out-of-band
>>> bridge master attribute updates and incorporate them into the runtime
>>> configuration.
>>>
>>> This patch is used for br_sysfs_if, and we also move br_ifinfo_notify out
>>> of store_flag.
>>>
>>> Signed-off-by: Xin Long <lucien.xin@...il.com>
>>> ---
>>>  net/bridge/br_sysfs_if.c | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>
>> Generally looks good, but it creates an inconsistency between bridge fdb_flush
>> and port fdb_flush since the latter will generate a notification while the
>> bridge flush will not.
>>
> yeah, because port fdb_flush is called by brport_store(), in the
> common function.
Right.

> do you think it''s redundant if we add a notification in bridge
> fdb_flush to keep
> consistence with port fdb_flush?
> 
Hmm, technically we're doing this via a sysfs option and the netlink fdb flush
one will generate a notification, so I'd say let's make them all consistent and
make them all generate a notification, and also making the bridge fdb_flush use
the bridge_store_parm should be trivial.

Thanks,
 Nik