netdev - Re: Errors enabling bridge with KSZ9897 DSA switch driver

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: <b73220ea-3807-7571-4e04-a392a3a5ba3e@sedsystems.ca>
Date:   Sun, 23 Dec 2018 13:29:42 -0600
From:   Robert Hancock <hancock@...systems.ca>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: Errors enabling bridge with KSZ9897 DSA switch driver

On 2018-12-23 5:23 a.m., Andrew Lunn wrote:
> On Sat, Dec 22, 2018 at 08:29:08PM -0600, Robert Hancock wrote:
>> I have a device using a KSZ9897 switch
>> (CONFIG_MICROCHIP_KSZ_SPI_DRIVER=y) using a 4.19.9 kernel, where I am
>> trying to enable a bridge on some of the ports using systemd-networkd.
> 
> Hi Robert
> 
> I don't think many of use use such a setup, so we probably have not
> noticed this.
> 
>> However, it seems to be getting an error when it tries to configure the
>> ports to be part of the bridge. systemd-networkd complains with:
>>
>> lan1: Set link
>> lan1: Could not join netdev: Operation not supported
>> lan1: Failed
>>
>> and the kernel complains:
>>
>> lan: bridge flag offload is not supported 4(lan1)
>>
>> That message is coming from br_switchdev_set_port_flag in
>> net/bridge/br_switchdev.c. Adding some more output to that statement
>> tells me:
>>
>> lan: bridge flag offload is not supported, flags 18656 mask 64 support
>> 0, 4(lan1)
>>
>> which appears to mean something is trying to enable BR_BCAST_FLOOD,
>> BR_MCAST_FLOOD, BR_PROMISC, BR_FLOOD, BR_LEARNING on the port, but it is
>> failing to enable BR_FLOOD because brport_flags_support is 0. I am just
>> using the default bridge settings in systemd-networkd, so that is
>> nothing that I am specifying explicitly.
> 
> I think this is a systemd problem. It should first query what flags
> are supported. See
> 
> dc0ecabd6231 ("net: switchdev: Add support for querying supported bridge flags by hardware")
> 
> And then only try to turn on flags which are supported.  If it tries
> to turn on flags which are not supported, an error is the correct
> thing to do.

I may be missing some context about how the switchdev/DSA code works, 
but are those flags actually unsupported, or just unsupported in 
hardware offload? Userspace doesn't know or care about the hardware 
offload capability of the switch, it's just trying to set standard flags 
on the bridge. As far as I can tell, BR_FLOOD is enabled by default (as 
a bridge without that set isn't very generally useful), but systemd 
trying to explicitly set it to enabled causes the entire userspace 
netlink operation to fail. That doesn't seem right.

As I mentioned in my follow-up message, it seems like the function 
producing that message shouldn't be failing the operation in this case, 
just bailing out in the same way as if the port doesn't support 
retrieving switchdev attributes at all.