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
| ||
|
Message-ID: <20221010115731.qjji7bgt53rusvzf@skbuf> Date: Mon, 10 Oct 2022 11:57:31 +0000 From: Vladimir Oltean <vladimir.oltean@....com> To: Sasha Levin <sashal@...nel.org> CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "stable@...r.kernel.org" <stable@...r.kernel.org>, Paolo Abeni <pabeni@...hat.com>, Claudiu Manoil <claudiu.manoil@....com>, "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>, "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>, "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: [PATCH AUTOSEL 6.0 12/77] net: mscc: ocelot: adjust forwarding domain for CPU ports in a LAG On Sun, Oct 09, 2022 at 06:06:49PM -0400, Sasha Levin wrote: > From: Vladimir Oltean <vladimir.oltean@....com> > > [ Upstream commit 291ac1517af58670740528466ccebe3caefb9093 ] > > Currently when we have 2 CPU ports configured for DSA tag_8021q mode and > we put them in a LAG, a PGID dump looks like this: > > PGID_SRC[0] = ports 4, > PGID_SRC[1] = ports 4, > PGID_SRC[2] = ports 4, > PGID_SRC[3] = ports 4, > PGID_SRC[4] = ports 0, 1, 2, 3, 4, 5, > PGID_SRC[5] = no ports > > (ports 0-3 are user ports, ports 4 and 5 are CPU ports) > > There are 2 problems with the configuration above: > > - user ports should enable forwarding towards both CPU ports, not just 4, > and the aggregation PGIDs should prune one CPU port or the other from > the destination port mask, based on a hash computed from packet headers. > > - CPU ports should not be allowed to forward towards themselves and also > not towards other ports in the same LAG as themselves > > The first problem requires fixing up the PGID_SRC of user ports, when > ocelot_port_assigned_dsa_8021q_cpu_mask() is called. We need to say that > when a user port is assigned to a tag_8021q CPU port and that port is in > a LAG, it should forward towards all ports in that LAG. > > The second problem requires fixing up the PGID_SRC of port 4, to remove > ports 4 and 5 (in a LAG) from the allowed destinations. > > After this change, the PGID source masks look as follows: > > PGID_SRC[0] = ports 4, 5, > PGID_SRC[1] = ports 4, 5, > PGID_SRC[2] = ports 4, 5, > PGID_SRC[3] = ports 4, 5, > PGID_SRC[4] = ports 0, 1, 2, 3, > PGID_SRC[5] = no ports > > Note that PGID_SRC[5] still looks weird (it should say "0, 1, 2, 3" just > like PGID_SRC[4] does), but I've tested forwarding through this CPU port > and it doesn't seem like anything is affected (it appears that PGID_SRC[4] > is being looked up on forwarding from the CPU, since both ports 4 and 5 > have logical port ID 4). The reason why it looks weird is because > we've never called ocelot_port_assign_dsa_8021q_cpu() for any user port > towards port 5 (all user ports are assigned to port 4 which is in a LAG > with 5). > > Since things aren't broken, I'm willing to leave it like that for now > and just document the oddity. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@....com> > Signed-off-by: Paolo Abeni <pabeni@...hat.com> > Signed-off-by: Sasha Levin <sashal@...nel.org> > --- Not needed for stable kernels, please drop, thanks.
Powered by blists - more mailing lists