netdev - Re: [PATCH net-next] net: dsa: mv88e6xxx: Add tx fwd offload PVT on intermediate 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211209224146.gfldu66kqmkgcg54@skbuf>
Date:   Fri, 10 Dec 2021 00:41:46 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mv88e6xxx: Add tx fwd offload PVT on
 intermediate devices

On Thu, Dec 09, 2021 at 11:24:24PM +0100, Tobias Waldekranz wrote:
> In a typical mv88e6xxx switch tree like this:
> 
>   CPU
>    |    .----.
> .--0--. | .--0--.
> | sw0 | | | sw1 |
> '-1-2-' | '-1-2-'
>     '---'
> 
> If sw1p{1,2} are added to a bridge that sw0p1 is not a part of, sw0
> still needs to add a crosschip PVT entry for the virtual DSA device
> assigned to represent the bridge.
> 
> Fixes: ce5df6894a57 ("net: dsa: mv88e6xxx: map virtual bridges with forwarding offload in the PVT")
> Signed-off-by: Tobias Waldekranz <tobias@...dekranz.com>
> ---

This makes sense. Sorry, my Turris MOX has 3 cascaded switches but I
only test it using a single bridge that spans all of the ports.
So this is why in my case the DSA and CPU ports could receive packets
using the virtual bridge device, because mv88e6xxx_port_vlan() had been
called on them through the direct mv88e6xxx_port_bridge_join(), not
through mv88e6xxx_crosschip_bridge_join(). I guess you have a use case
where some leaf ports are in a bridge but some upstream ports aren't,
and this is how you caught this?

Thanks!

Reviewed-by: Vladimir Oltean <vladimir.oltean@....com>

> 
> Though this is a bugfix, it still targets net-next as it depends on
> the recent work done by Vladimir here:
> 
> https://lore.kernel.org/netdev/20211206165758.1553882-1-vladimir.oltean@nxp.com/
> 
>  drivers/net/dsa/mv88e6xxx/chip.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 7fadbf987b23..85f5a35340d7 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2522,6 +2522,7 @@ static int mv88e6xxx_crosschip_bridge_join(struct dsa_switch *ds,
>  
>  	mv88e6xxx_reg_lock(chip);
>  	err = mv88e6xxx_pvt_map(chip, sw_index, port);
> +	err = err ? : mv88e6xxx_map_virtual_bridge_to_pvt(ds, bridge.num);
>  	mv88e6xxx_reg_unlock(chip);
>  
>  	return err;
> @@ -2537,7 +2538,8 @@ static void mv88e6xxx_crosschip_bridge_leave(struct dsa_switch *ds,
>  		return;
>  
>  	mv88e6xxx_reg_lock(chip);
> -	if (mv88e6xxx_pvt_map(chip, sw_index, port))
> +	if (mv88e6xxx_pvt_map(chip, sw_index, port) ||
> +	    mv88e6xxx_map_virtual_bridge_to_pvt(ds, bridge.num))
>  		dev_err(ds->dev, "failed to remap cross-chip Port VLAN\n");
>  	mv88e6xxx_reg_unlock(chip);
>  }
> -- 
> 2.25.1
>