netdev - Re: Choose a default DSA CPU port

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:   Tue, 28 Feb 2023 13:58:46 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Frank Wunderlich <frank-w@...lic-files.de>
Cc:     Arınç ÜNAL <arinc.unal@...nc9.com>,
        Felix Fietkau <nbd@....name>, netdev <netdev@...r.kernel.org>,
        erkin.bozoglu@...ont.com, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        John Crispin <john@...ozen.org>,
        Mark Lee <Mark-MC.Lee@...iatek.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>
Subject: Re: Choose a default DSA CPU port

On Sun, Feb 26, 2023 at 01:12:04PM +0100, Frank Wunderlich wrote:
> but back to topic...we have a patch from vladuimir which allows
> setting the preferred cpu-port...how do we handle mt7531 here
> correctly (which still sets port5 if defined and then break)?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/drivers/net/dsa/mt7530.c#n2383
> 
> 	/* BPDU to CPU port */
> 	dsa_switch_for_each_cpu_port(cpu_dp, ds) {
> 		mt7530_rmw(priv, MT7531_CFC, MT7531_CPU_PMAP_MASK,
> 			   BIT(cpu_dp->index));
> 		break; //<<< should we drop this break only to set all "cpu-bits"? what happens then (flooding both ports with packets?)
> 	}
> 
> as dsa only handles only 1 cpu-port we want the real cpu-port
> (preferred | first). is this bit set also if the master is changed
> with your follow-up patch?

Could you please make a best-effort attempt at describing what does the
MT7531_CFC[MT7531_CPU_PMAP_MASK] register affect? From the comment, if
affects the trapping of control packets. Does the MT7530 not have this
register? Do they behave differently? Does the register affect anything
else? If that logic is commented out, does DSA-tagged traffic still work
on MT7531? How about a bridge created with stp_state 1? I don't
understand at the moment why the hardware allows specifying a port mask
rather than a single port. Intuitively I'd say that if this field
contains more than one bit set, then control packets would be delivered
to all CPU ports that are up, effectively resulting in double processing
in Linux. So that doesn't seem to be useful. But I don't have enough data.