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]
Date:   Sun, 5 May 2019 23:34:18 +0200
From:   Hauke Mehrtens <hauke@...ke-m.de>
To:     Florian Fainelli <f.fainelli@...il.com>, davem@...emloft.net
Cc:     andrew@...n.ch, vivien.didelot@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2 3/5] net: dsa: lantiq: Add VLAN aware bridge offloading

On 5/5/19 11:27 PM, Florian Fainelli wrote:
> 
> 
> On 5/5/2019 2:15 PM, Hauke Mehrtens wrote:
>> The VLAN aware bridge offloading is similar to the VLAN unaware
>> offloading, this makes it possible to offload the VLAN bridge
>> functionalities.
>>
>> The hardware supports up to 64 VLAN bridge entries, we already use one
>> entry for each LAN port to prevent forwarding of packets between the
>> ports when the ports are not in a bridge, so in the end we have 57
>> possible VLANs.
>>
>> The VLAN filtering is currently only active when the ports are in a
>> bridge, VLAN filtering for ports not in a bridge is not implemented.
>>
>> It is currently not possible to change between VLAN filtering and not
>> filtering while the port is already in a bridge, this would make the
>> driver more complicated.
>>
>> The VLANs are only defined on bridge entries, so we will not add
>> anything into the hardware when the port joins a bridge if it is doing
>> VLAN filtering, but only when an allowed VLAN is added.
> 
> [snip]
> 
>>  	struct gswip_priv *priv = ds->priv;
>> +	struct net_device *bridge = dsa_to_port(ds, port)->bridge_dev;
>> +
>> +	/* Do not allow chaning the VLAN filtering options while in bridge */
> 
> Typo: changing.

Will fix the typo.

> This looks fine to me, you might be able to simplify the code a little
> bit if you directly used bridge_dev->ifindex as the FID and just keep a
> bitmap of active FIDs such that you can manage roll-overs etc. upon
> bridge device destruction/creation.

The switch only has 6 bit for the flow ID. It is possible to have more
than 64 network devices in a system and then ifindex would be too big.

> 
> Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ