netdev - Re: [PATCH net 0/3] Fix VLAN checks for SJA1105 DSA tc-flower filters

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] [day] [month] [year] [list]

Date:   Thu, 18 Jun 2020 20:21:15 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     olteanv@...il.com
Cc:     netdev@...r.kernel.org, andrew@...n.ch, f.fainelli@...il.com,
        vivien.didelot@...il.com, kuba@...nel.org
Subject: Re: [PATCH net 0/3] Fix VLAN checks for SJA1105 DSA tc-flower
 filters

From: Vladimir Oltean <olteanv@...il.com>
Date: Wed, 17 Jun 2020 02:58:40 +0300

> From: Vladimir Oltean <vladimir.oltean@....com>
> 
> This fixes a ridiculous situation where the driver, in VLAN-unaware
> mode, would refuse accepting any tc filter:
> 
> tc filter replace dev sw1p3 ingress flower skip_sw \
> 	dst_mac 42:be:24:9b:76:20 \
> 	action gate (...)
> Error: sja1105: Can only gate based on {DMAC, VID, PCP}.
> 
> tc filter replace dev sw1p3 ingress protocol 802.1Q flower skip_sw \
> 	vlan_id 1 vlan_prio 0 dst_mac 42:be:24:9b:76:20 \
> 	action gate (...)
> Error: sja1105: Can only gate based on DMAC.
> 
> So, without changing the VLAN awareness state, it says it doesn't want
> VLAN-aware rules, and it doesn't want VLAN-unaware rules either. One
> would say it's in Schrodinger's state...
> 
> Now, the situation has been made worse by commit 7f14937facdc ("net:
> dsa: sja1105: keep the VLAN awareness state in a driver variable"),
> which made VLAN awareness a ternary attribute, but after inspecting the
> code from before that patch with a truth table, it looks like the
> logical bug was there even before.
> 
> While attempting to fix this, I also noticed some leftover debugging
> code in one of the places that needed to be fixed. It would have
> appeared in the context of patch 3/3 anyway, so I decided to create a
> patch that removes it.

Series applied, thanks.