netdev - Re: [PATCH net-next v6 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201006123705.bnrborrpms6vaegz@skbuf>
Date:   Tue, 6 Oct 2020 15:37:05 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Kurt Kanzenbach <kurt@...utronix.de>
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 net-next v6 2/7] net: dsa: Add DSA driver for Hirschmann
 Hellcreek switches

On Tue, Oct 06, 2020 at 02:32:37PM +0300, Vladimir Oltean wrote:
> - The .port_vlan_add will always install the VLAN to the hardware
>   database, no queuing if there's no reason for it (and I can't see any.
>   Your hardware seems to be sane enough to not drop a VLAN-tagged frame,
>   and forward it correctly on egress, as long as you call
>   hellcreek_setup_ingressflt with enable=false, am I right? or does the
>   VLAN still need to be installed into the egress port?).

I don't know if this goes without saying or not, but of course, if you
can't enforce correct behavior with a vlan_filtering=0 bridge (i.e.
"ingressflt" will only help the VLAN-tagged frames to be accepted on
ingress, but they will be nonetheless dropped on egress due to no valid
destinations), then you should reject that setting in the 2 places where
vlan_filtering can be enabled:

(a) in .port_prechangeupper, you should make sure that if the upper is a
    bridge, then br_vlan_enabled() must be true.
(b) in .port_vlan_filtering, you should reject enabled=false from the
    switchdev_trans_ph_prepare(trans) state.

Again, this isn't about implementing every possible combination, just
about making sure that the user isn't led into believing that a certain
setting works when in reality it doesn't.

> @@ -2006,10 +2006,22 @@ static int dsa_slave_netdevice_event(struct notifier_block *nb,
>  	switch (event) {
>  	case NETDEV_PRECHANGEUPPER: {
>  		struct netdev_notifier_changeupper_info *info = ptr;
> +		struct dsa_switch *ds;
> +		struct dsa_port *dp;
> +		int err;
>  
>  		if (!dsa_slave_dev_check(dev))
>  			return dsa_prevent_bridging_8021q_upper(dev, ptr);
>  
> +		dp = dsa_slave_to_port(dev);
> +		ds = dp->ds;
> +
> +		if (ds->ops->port_prechangeupper) {
> +			err = ds->ops->port_prechangeupper(ds, dp->index, ptr);
> +			if (err)
> +				return err;

Correction: this should return notifier_from_errno(err).

> +		}
> +
>  		if (is_vlan_dev(info->upper_dev))
>  			return dsa_slave_check_8021q_upper(dev, ptr);
>  		break;
> -- 
> 2.25.1