netdev - Re: [PATCH net-next 1/4] bridge: Allow enslaving 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] [day] [month] [year] [list]
Message-ID: <4dbbb407-18f2-f5b0-c47f-88fa54c193f5@cumulusnetworks.com>
Date:   Thu, 30 Apr 2020 21:05:04 +0300
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jiri Pirko <jiri@...nulli.us>,
        Ido Schimmel <idosch@...sch.org>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>, Li Yang <leoyang.li@....com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>
Subject: Re: [PATCH net-next 1/4] bridge: Allow enslaving DSA master network
 devices

On 30/04/2020 20:55, Nikolay Aleksandrov wrote:
> On 30/04/2020 20:50, Vladimir Oltean wrote:
>> Hi Nikolay, Roopa,
>>
>> On Wed, 29 Apr 2020 at 19:33, Nikolay Aleksandrov
>> <nikolay@...ulusnetworks.com> wrote:
>>>
>>> +CC Roopa
>>>
>>> On 29/04/2020 19:27, Nikolay Aleksandrov wrote:
>>>> On 29/04/2020 19:19, Vladimir Oltean wrote:
>>>>> From: Florian Fainelli <f.fainelli@...il.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.
>>>>>
>>>>> Make br_handle_frame() return RX_HANDLER_PASS in order to call into the
>>>>> DSA specific tagging protocol handlers, and lift the restriction from
>>>>> br_add_if.
>>>>>
>>>>> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
>>>>> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
>>>>> ---
>>>>>  net/bridge/br_if.c    | 4 +---
>>>>>  net/bridge/br_input.c | 4 +++-
>>>>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>>>>> index ca685c0cdf95..e0fbdb855664 100644
>>>>> --- a/net/bridge/br_if.c
>>>>> +++ b/net/bridge/br_if.c
>>>>> @@ -18,7 +18,6 @@
>>>>>  #include <linux/rtnetlink.h>
>>>>>  #include <linux/if_ether.h>
>>>>>  #include <linux/slab.h>
>>>>> -#include <net/dsa.h>
>>>>>  #include <net/sock.h>
>>>>>  #include <linux/if_vlan.h>
>>>>>  #include <net/switchdev.h>
>>>>> @@ -571,8 +570,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
>>>>>       */
>>>>>      if ((dev->flags & IFF_LOOPBACK) ||
>>>>>          dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
>>>>> -        !is_valid_ether_addr(dev->dev_addr) ||
>>>>> -        netdev_uses_dsa(dev))
>>>>> +        !is_valid_ether_addr(dev->dev_addr))
>>>>>              return -EINVAL;
>>>>>
>>>>>      /* No bridging of bridges */
>>>>> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
>>>>> index d5c34f36f0f4..396bc0c18cb5 100644
>>>>> --- a/net/bridge/br_input.c
>>>>> +++ b/net/bridge/br_input.c
>>>>> @@ -17,6 +17,7 @@
>>>>>  #endif
>>>>>  #include <linux/neighbour.h>
>>>>>  #include <net/arp.h>
>>>>> +#include <net/dsa.h>
>>>>>  #include <linux/export.h>
>>>>>  #include <linux/rculist.h>
>>>>>  #include "br_private.h"
>>>>> @@ -263,7 +264,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>>>>>      struct sk_buff *skb = *pskb;
>>>>>      const unsigned char *dest = eth_hdr(skb)->h_dest;
>>>>>
>>>>> -    if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
>>>>> +    if (unlikely(skb->pkt_type == PACKET_LOOPBACK) ||
>>>>> +        netdev_uses_dsa(skb->dev))
>>>>>              return RX_HANDLER_PASS;
>>>>>
>>>>>      if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
>>>>>
>>>>
>>>> Yet another test in fast-path for all packets.
>>>> Since br_handle_frame will not be executed at all for such devices I'd suggest
>>>> to look into a scheme that avoid installing rx_handler and thus prevents br_handle_frame
>>>> to be called in the frist place. In case that is not possible then we can discuss adding
>>>> one more test in fast-path.
>>>>
>>>> Actually you can just add a dummy rx_handler that simply returns RX_HANDLER_PASS for
>>>> these devices and keep rx_handler_data so all br_port_get_* will continue working.
>>>>
>>>> Thanks,
>>>>  Nik
>>>>
>>
>> Actually both of those are problematic, since br_port_get_check_rcu
>> and br_port_get_check_rtnl check for the rx_handler pointer against
>> br_handle_frame.
> 
> Right, but they can be changed to use a different validation.
> 

To be more specific I was referring to the most frequently used br_port_get_rcu/rtnl helpers.
The versions with _check can be changed to use a different validation.

>> Actually a plain old revert of 8db0a2ee2c63 works just fine for what I
>> need it to, not sure if there's any point in making this any more
>> complicated than that.
>> What do you think?
>>
> 
> Sounds much better to me if it works for you.
> 
> Thanks!
> 
>> Thanks,
>> -Vladimir
>>
>