netdev - Re: mv88e6xxx broken on 6176 with "Disentangle STU from VTU"

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: <874k3vj708.fsf@waldekranz.com>
Date:   Fri, 18 Mar 2022 22:16:55 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Marek Behún <kabel@...nel.org>,
        Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: mv88e6xxx broken on 6176 with "Disentangle STU from VTU"

On Fri, Mar 18, 2022 at 22:18, Vladimir Oltean <olteanv@...il.com> wrote:
> Hello Tobias,
>
> On Fri, Mar 18, 2022 at 08:20:33PM +0100, Tobias Waldekranz wrote:
>> On Fri, Mar 18, 2022 at 18:28, Marek Behún <kabel@...nel.org> wrote:
>> > Hello Tobias,
>> >
>> > mv88e6xxx fails to probe in net-next on Turris Omnia, bisect leads to
>> > commit
>> >   49c98c1dc7d9 ("net: dsa: mv88e6xxx: Disentangle STU from VTU")
>> 
>> Oh wow, really sorry about that! I have it reproduced, and I understand
>> the issue.
>> 
>> > Trace:
>> >   mv88e6xxx_setup
>> >     mv88e6xxx_setup_port
>> >       mv88e6xxx_port_vlan_join(MV88E6XXX_VID_STANDALONE) OK
>> >       mv88e6xxx_port_vlan_join(MV88E6XXX_VID_BRIDGED) -EOPNOTSUPP
>> >
>> 
>> Thanks, that make it easy to find. There is a mismatch between what the
>> family-info struct says and what the chip-specific ops struct supports.
>> 
>> I'll try to send a fix ASAP.
>
> I've seen your patches, but I don't understand the problem they fix.
> For switches like 6190 indeed this is a problem. It has max_stu = 63 but
> mv88e6190_ops has no stu_getnext or stu_loadpurge. That I understand.
>
> But Marek reported the problem on 6176. There, max_sid is 0, so
> mv88e6xxx_has_stu() should already return false. Where is the
> -EOPNOTSUPP returned from?

Somewhat surprisingly, it is from mv88e6xxx_broadcast_setup.

Ok, I'll go out on a limb and say that _now_ I know what the problem
is. If I uncomment .max_sid and .stu_{loadpurge,getnext} from my 6352
(which, like the 6176, is also of the Agate-family) I can reproduce the
same issue.

It seems like this family does not like to load VTU entries who's SID
points to an invalid STU entry. Since .max_sid == 0, we never run
stu_setup, which takes care of loading a valid STU entry for SID 0;
therefore when we read back MV88E6XXX_VID_BRIDGED in
mv88e6xxx_port_db_load_purge it is reported as invalid.

This still doesn't explain why we're able to load
MV88E6XXX_VID_STANDALONE though...

Vladimir, any advise on how to proceed here? I took a very conservative
approach to filling in the STU ops, only enabling it on HW that I could
test. I could study some datasheets and make an educated guess about the
full range of chips that we could enable this on, and which version of
the ops to use. Does that sound reasonable?