netdev - Re: [PATCH v2 net-next 1/4] net: bridge: allow enslaving some DSA master network devices

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: <6d46b1ea-0d46-3857-e3b8-82d73ddcaea0@cumulusnetworks.com>
Date:   Fri, 1 May 2020 12:28:21 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Vladimir Oltean <olteanv@...il.com>, andrew@...n.ch,
        f.fainelli@...il.com, vivien.didelot@...il.com, davem@...emloft.net
Cc:     jiri@...nulli.us, idosch@...sch.org, kuba@...nel.org,
        netdev@...r.kernel.org, leoyang.li@....com,
        roopa@...ulusnetworks.com
Subject: Re: [PATCH v2 net-next 1/4] net: bridge: allow enslaving some DSA
 master network devices

On 30/04/2020 23:25, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@....com>
> 
> Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
> as bridge members") added a special check in br_if.c in order to check
> for a DSA master network device with a tagging protocol configured. This
> was done because back then, such devices, once enslaved in a bridge
> would become inoperative and would not pass DSA tagged traffic anymore
> due to br_handle_frame returning RX_HANDLER_CONSUMED.
> 
> But right now we have valid use cases which do require bridging of DSA
> masters. One such example is when the DSA master ports are DSA switch
> ports themselves (in a disjoint tree setup). This should be completely
> equivalent, functionally speaking, from having multiple DSA switches
> hanging off of the ports of a switchdev driver. So we should allow the
> enslaving of DSA tagged master network devices.
> 
> Instead of the regular br_handle_frame(), install a new function
> br_handle_frame_dummy() on these DSA masters, which returns
> RX_HANDLER_PASS in order to call into the DSA specific tagging protocol
> handlers, and lift the restriction from br_add_if.
> 
> Suggested-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
> Suggested-by: Florian Fainelli <f.fainelli@...il.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> ---
> Changes in v2:
> * Removed the hotpath netdev_uses_dsa check and installed a dummy
>   rx_handler for such net devices.
> * Improved the check of which DSA master net devices are able to be
>   bridged and which aren't.
> * At this stage, the patch is different enough from where I took it from
>   (aka https://github.com/ffainelli/linux/commit/75618cea75ada8d9eef7936c002b5ec3dd3e4eac)
>   that I just added my authorship to it).
> 
>  include/net/dsa.h       |  2 +-
>  net/bridge/br_if.c      | 32 +++++++++++++++++++++++---------
>  net/bridge/br_input.c   | 23 ++++++++++++++++++++++-
>  net/bridge/br_private.h |  6 +++---
>  4 files changed, 49 insertions(+), 14 deletions(-)
> 

Looks good to me, thanks.
Acked-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>