linux-kernel - [PATCH net 0/2] Fix MTU reporting for Marvell DSA switches where we can't change it

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

Message-Id: <20230314182405.2449898-1-vladimir.oltean@nxp.com>
Date:   Tue, 14 Mar 2023 20:24:03 +0200
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     netdev@...r.kernel.org
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Murali Krishna Policharla <murali.policharla@...adcom.com>,
        Lukasz Majewski <lukma@...x.de>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org
Subject: [PATCH net 0/2] Fix MTU reporting for Marvell DSA switches where we can't change it

As explained in patch 2, the driver doesn't know how to change the MTU
on MV88E6165, MV88E6191, MV88E6220, MV88E6250 and MV88E6290, and there
is a regression where it actually reports an MTU value below the
Ethernet standard (1500).

Fixing that shows another issue where DSA is unprepared to be told that
a switch supports an MTU of only 1500, and still errors out. That is
addressed by patch 1.

Testing was not done on "real" hardware, but on a different Marvell DSA
switch, with code modified such that the driver doesn't know how to
change the MTU on that, either.

A key assumption is that these switches don't need any MTU configuration
to pass full MTU-sized, DSA-tagged packets, which seems like a
reasonable assumption to make. My 6390 and 6190 switches, with
.port_set_jumbo_size commented out, certainly don't seem to have any
problem passing MTU-sized traffic, as can be seen in this iperf3 session
captured with tcpdump on the DSA master:

$MAC > $MAC, Marvell DSA mode Forward, dev 2, port 8, untagged, VID 1000,
	FPri 0, ethertype IPv4 (0x0800), length 1518:
	10.0.0.69.49590 > 10.0.0.1.5201: Flags [.], seq 81088:82536,
	ack 1, win 502, options [nop,nop,TS val 2221498829 ecr 3012859850],
	length 1448

I don't want to go all the way and say that the adjustment made by
commit b9c587fed61c ("dsa: mv88e6xxx: Include tagger overhead when
setting MTU for DSA and CPU ports") is completely unnecessary, just that
there's an equally good chance that the switches with unknown MTU
configuration procedure "just work".

Vladimir Oltean (2):
  net: dsa: don't error out when drivers return ETH_DATA_LEN in
    .port_max_mtu()
  net: dsa: mv88e6xxx: fix max_mtu of 1492 on 6165, 6191, 6220, 6250,
    6290

 drivers/net/dsa/mv88e6xxx/chip.c | 16 ++++++++++++----
 net/dsa/slave.c                  |  9 +++++----
 2 files changed, 17 insertions(+), 8 deletions(-)

-- 
2.34.1