netdev - Re: [PATCH net-next 2/2] net: bridge: Notify about !added_by

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:   Tue, 1 May 2018 20:49:15 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Petr Machata <petrm@...lanox.com>, netdev@...r.kernel.org
Cc:     ivecera@...hat.com, davem@...emloft.net,
        stephen@...workplumber.org, andrew@...n.ch,
        vivien.didelot@...oirfairelinux.com, f.fainelli@...il.com,
        jiri@...nulli.us, stephen@...workplumber.org,
        "bridge@...ts.linux-foundation.org" 
        <bridge@...ts.linux-foundation.org>
Subject: Re: [PATCH net-next 2/2] net: bridge: Notify about !added_by_user FDB
 entries

On 01/05/18 20:04, Petr Machata wrote:
> Do not automatically bail out on sending notifications about activity on
> non-user-added FDB entries. Instead, notify about this activity except
> for cases where the activity itself originates in a notification, to
> avoid sending duplicate notifications.
> 
> Signed-off-by: Petr Machata <petrm@...lanox.com>
> ---
>   net/bridge/br.c           |  4 ++--
>   net/bridge/br_fdb.c       | 40 +++++++++++++++++++++++++++-------------
>   net/bridge/br_private.h   |  4 ++--
>   net/bridge/br_switchdev.c |  2 +-
>   4 files changed, 32 insertions(+), 18 deletions(-)
> 

Hi Petr,
We already have 7 different fdb delete functions, I'm really not a fan of
adding yet another one for such trivial change.
Why don't you just add the new notify parameter to the already existing
fdb_delete() ? (actually about the name see below)
IMO it's confusing - if one wants a notification then use fdb_delete() or __fdb_delete(true)
vs __fdb_delete(false) if a notification is not required. I think simply having the last
parameter everywhere for fdb_delete() shows the intention clearer and avoids another
fdb delete function.

Another point, the notify parameter has a confusing name in this context because
you're controlling the switchdev notifications not the rtnetlink ones. I'd suggest
changing the name to something more descriptive like swdev_notify, otherwise you
could get the funny end result of calling __fdb_notify() with notify == false which
to me means don't notify. :-)

Also please add the bridge maintainers to the CC list.

Thanks,
  Nik