netdev - Re: [PATCH v5 2/7] net: dsa: Add DSA driver for Hirschmann Hellcreek switches

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: <87a6y1adnu.fsf@kurt>
Date:   Mon, 07 Sep 2020 16:01:57 +0200
From:   Kurt Kanzenbach <kurt@...utronix.de>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Richard Cochran <richardcochran@...il.com>,
        Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
        ilias.apalodimas@...aro.org
Subject: Re: [PATCH v5 2/7] net: dsa: Add DSA driver for Hirschmann Hellcreek switches

On Mon Sep 07 2020, Vladimir Oltean wrote:
> On Mon, Sep 07, 2020 at 02:49:03PM +0200, Kurt Kanzenbach wrote:
>> On Mon Sep 07 2020, Vladimir Oltean wrote:
>> > On Mon, Sep 07, 2020 at 08:05:25AM +0200, Kurt Kanzenbach wrote:
>> >> Well, that depends on whether hellcreek_vlan_add() is called for
>> >> creating that vlan interfaces. In general: As soon as both ports are
>> >> members of the same vlan that traffic is switched.
>> >
>> > That's indeed what I would expect.
>> > Not only that, but with your pvid-based setup, you only ensure port
>> > separation for untagged traffic anyway.
>>
>> Why? Tagged traffic is dropped unless the vlan is configured somehow. By
>> default, I've configured vlan 2 and 3 to reflect the port separation for
>> DSA. At reset the ports aren't members of any vlan.
>>
>
> Wait, so what is the out-of-reset state of "ptcfg & HR_PTCFG_INGRESSFLT"?

No, ingress filtering is not set by default. But, still the ports are by
default not members of any vlan. So, I thought the traffic will be
dropped as well. I'll check that. 

> If it is filtering by default (and even if it isn't, but you can make
> it), then I suppose you can keep it like that, and try to model your
> ports something like this:
>
> - force "ethtool -k swpN | grep rx-vlan-filter" to return "on (fixed)".
> - enforce a check that in standalone mode, you can't have an 8021q upper
>   interface with the same VLAN ID on more than 1 port at the same time.
>   This will be the only way in which you can terminate VLAN traffic on
>   standalone ports.
>
> If you do this, I think you should be compliant with the stack.

OK, great. I'll look into it.

>> OK. when a new driver should set the flag, then I'll set it. So, all
>> vlan requests programming requests should be "buffered" and executed
>> when vlan filtering is enabled? What is it good for?
>
> It is good for correct functionality of the hardware, I don't get the
> question? If your driver makes private use of VLAN tags beyond what the
> upper layers ask for, then it should keep track of them.

OK.

> DSA has, in the past, ignored VLAN switchdev operations from the
> bridge when not in vlan_filtering mode, for unknown reasons. This is
> known to break some command sequences (see below), so the consensus at
> the time was to stop doing that, and introduce this temporary
> compatibility flag.
>
> Some tests to make sure you're passing are:
>
> 1. Statically creating an 802.1Q bridge:
>
> ip link add br0 type bridge vlan_filtering 1
> ip link set swp1 master br0
> ip link set swp2 master br0
>
> 2. Dynamically turning an 802.1D bridge into an 802.1Q bridge:
>
> ip link add br0 type bridge
> ip link set swp1 master br0
> ip link set swp2 master br0
> ip link set br0 type bridge vlan_filtering 1
> # at this moment in time, if you don't have
> # configure_vlan_while_not_filtering = true, then the VLAN tables of
> # swp1 and swp2 will be missing the default_pvid (by default 1) of br0.

Yes, OK. I've observed this behavior myself and was confused about it.

Thanks,
Kurt

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)