netdev - Re: [PATCH net 08/14] selftests: net: bridge_vlan_aware: test that other TPIDs are seen as untagged

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: <20240815093855.zvosiich6jyxggag@skbuf>
Date: Thu, 15 Aug 2024 12:38:55 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Ido Schimmel <idosch@...dia.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Claudiu Manoil <claudiu.manoil@....com>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	Antoine Tenart <atenart@...nel.org>, UNGLinuxDriver@...rochip.com,
	Hongbo Wang <hongbo.wang@....com>,
	Xiaoliang Yang <xiaoliang.yang_1@....com>,
	Andrew Lunn <andrew@...n.ch>,
	Florian Fainelli <f.fainelli@...il.com>,
	Colin Foster <colin.foster@...advantage.com>,
	Horatiu Vultur <horatiu.vultur@...rochip.com>,
	Hangbin Liu <liuhangbin@...il.com>, Petr Machata <petrm@...dia.com>,
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 08/14] selftests: net: bridge_vlan_aware: test that
 other TPIDs are seen as untagged

On Thu, Aug 15, 2024 at 12:11:07PM +0300, Ido Schimmel wrote:
> Thanks for the test. Passes with mlxsw as well.

Thanks for testing.

> > +	ethtool -K $h2 rx-vlan-filter off rx-vlan-stag-filter off
> 
> Any reason not to undo it at the end of the test like other settings?

A combination of laziness to add even more logic to save/restore the
ethtool features (should probably live in lib.sh), plus a persistent
question of "who cares anyway". The default values are driver defined
anyway, so it's likely that anyone who cares will control these features
prior to starting their application. Plus, turning off RX VLAN filtering
offload should not technically leave anything broken behind.