netdev - Re: warnings from MTU setting on switch ports

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: <61a2e853-9d81-8c1a-80f0-200f5d8dc650@prevas.dk>
Date:   Mon, 30 Nov 2020 23:13:39 +0100
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     Network Development <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: warnings from MTU setting on switch ports

On 30/11/2020 17.04, Vladimir Oltean wrote:
> Hi Rasmus,
> 
> On Mon, Nov 30, 2020 at 03:30:50PM +0100, Rasmus Villemoes wrote:
>> Hi,
>>
>> Updating our mpc8309 board to 5.9, we're starting to get
>>
>> [    0.709832] mv88e6085 mdio@...02120:10: nonfatal error -34 setting MTU on port 0
>> [    0.720721] mv88e6085 mdio@...02120:10: nonfatal error -34 setting MTU on port 1
>> [    0.731002] mv88e6085 mdio@...02120:10: nonfatal error -34 setting MTU on port 2
>> [    0.741333] mv88e6085 mdio@...02120:10: nonfatal error -34 setting MTU on port 3
>> [    0.752220] mv88e6085 mdio@...02120:10: nonfatal error -34 setting MTU on port 4
>> [    0.764231] eth1: mtu greater than device maximum
>> [    0.769022] ucc_geth e0102000.ethernet eth1: error -22 setting MTU to include DSA overhead
>>
>> So it does say "nonfatal", but do we have to live with those warnings on
>> every boot going forward, or is there something that we could do to
>> silence it?
>>
>> It's a mv88e6250 switch with cpu port connected to a ucc_geth interface;
>> the ucc_geth driver indeed does not implement ndo_change_mtu and has
>> ->max_mtu set to the default of 1500.
> 
> To suppress the warning:
> 
> commit 4349abdb409b04a5ed4ca4d2c1df7ef0cc16f6bd
> Author: Vladimir Oltean <olteanv@...il.com>
> Date:   Tue Sep 8 02:25:56 2020 +0300
> 
>     net: dsa: don't print non-fatal MTU error if not supported
>

Thanks, but I don't think that will change anything. -34 is -ERANGE.
> But you might also want to look into adding .ndo_change_mtu for
> ucc_geth. 

Well, that was what I first did, but I'm incapable of making sense of
the QE reference manual. Perhaps, given the domain of your email
address, you could poke someone that might know what would need to be done?

In any case, something else seems to be broken with 5.9; no network
traffic seems to be working (but the bridge creation etc. seems to work
just the same, link status works, and "ip link show" shows the same
things as in 4.19). So until I figure that out I can't play around with
modifying ucc_geth.

If you are able to pass MTU-sized traffic through your
> mv88e6085, then it is probably the case that the mpc8309 already
> supports larger packets than 1500 bytes, and it is simply a matter of
> letting the stack know about that. 

Perhaps, but I don't know how I should test that given that 1500
give-or-take is hardcoded. FWIW, on a 4.19 kernel, I can do 'ping -s X
-M do' for X up to 1472 for IPv4 and 1452 for IPv6, but I don't think
that tells me much about what the hardware could do.

A thought: Shouldn't the initialization of slave_dev->max_mtu in
dsa_slave_create() be capped by master->max_mtu minus tag overhead?

Rasmus