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  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]
Date:   Wed, 24 Oct 2018 15:10:35 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     netdev@...r.kernel.org
Cc:     jiri@...lanox.com, petr@...lanox.com, idosch@...lanox.com,
        privat@...l-hjelmeland.no, Woojung.Huh@...rochip.com,
        tristram.ha@...rochip.com, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        "David S. Miller" <davem@...emloft.net>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] net: dsa: Make switches VLAN aware when enslaved into
 a bridge

On 10/24/18 12:36 PM, Florian Fainelli wrote:
> Commit 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is
> disabled") changed the behavior of DSA switches when the switch ports
> are enslaved into the bridge and only pushed the VLAN configuration down
> to the switch if the bridge is configured with VLAN filtering enabled.
> 
> This is unfortunately wrong, because what vlan_filtering configures is a
> policy on the acceptance of VLAN tagged frames with an unknown VID.
> 
> vlan_filtering=0 means a frame with a VLAN tag that is not part of the
> VLAN table should be allowed to ingress the switch, and vlan_fltering=1
> would reject that frame.
> 
> Fixes: 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
> ---
> Andrew,
> 
> I checked with Jiri and he confirmed that our interpretention of
> vlan_filtering in DSA was incorrect and that it does denote whether the
> switch should be doing VID ingress policy checking.
> 
> You mentioned in the commit message some problems without being too
> specific about them which is why I am putting the same checks in
> mv88e6xxx in order not to break your use cases. Let me know if you want
> to drop that hunk entirely.
> 
> Thanks!
> 
>  drivers/net/dsa/mv88e6xxx/chip.c |  7 ++++++-
>  net/dsa/port.c                   | 10 ++--------
>  2 files changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 8da3d39e3218..df411e776911 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -1684,13 +1684,14 @@ static int _mv88e6xxx_port_vlan_add(struct mv88e6xxx_chip *chip, int port,
>  static void mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,
>  				    const struct switchdev_obj_port_vlan *vlan)
>  {
> +	struct dsa_port *dp = &ds->ports[i];

This should obviously be port instead of i, but I would still appreciate
a review, thanks!
-- 
Florian

Powered by blists - more mailing lists