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: <21578ba2-e8ac-2921-80d5-cd32bc1e4700@sedsystems.ca>
Date:   Thu, 27 Dec 2018 17:32:46 -0600
From:   Robert Hancock <hancock@...systems.ca>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, arkadis@...lanox.com
Subject: Re: Errors enabling bridge with KSZ9897 DSA switch driver

On 2018-12-23 2:57 p.m., Andrew Lunn wrote:
> On Sun, Dec 23, 2018 at 01:29:42PM -0600, Robert Hancock wrote:
>> 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.
> 
> Hi Robert
> 
> We really need Arkadi Sharshevsky to comment on this.

FYI, changing the code in question to return 0 instead of -EOPNOTSUPP in
the missing brport_flags_support flag case allows systemd-networkd to
initialize the port successfully. We have some other issues in our
hardware setup that prevent me from testing that fully at the moment,
but I will likely submit that as a patch shortly unless I hear of a
better solution..

-- 
Robert Hancock
Senior Software Developer
SED Systems
Email: hancock@...systems.ca

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ