netdev - Re: net: ipconfig: dev_set_mtu call is incompatible with a number of Ethernet drivers

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: <b3014260-8a57-40ed-a2b1-301503e392e3@kernel.org>
Date: Sun, 17 Dec 2023 11:42:32 -0700
From: David Ahern <dsahern@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Graeme Smecher <gsmecher@...eespeedlogic.com>, davem@...emloft.net,
 netdev@...r.kernel.org, claudiu.beznea@...on.dev,
 nicolas.ferre@...rochip.com, mdf@...nel.org
Subject: Re: net: ipconfig: dev_set_mtu call is incompatible with a number of
 Ethernet drivers

On 12/17/23 11:22 AM, Andrew Lunn wrote:
> On Fri, Dec 15, 2023 at 09:49:45AM -0800, David Ahern wrote:
>> On 12/14/23 12:07 PM, Graeme Smecher wrote:
>>> Hi all,
>>>
>>> In a number of ethernet drivers, the MTU can't be changed on a running
>>> device. Here's one example (from drivers/net/ethernet/cadence/macb_main.c):
>>>
>>
>> ...
>>
>>>
>>> So - what to do? I can see three defensible arguments:
>>>
>>> - The network drivers should allow MTU changes on-the-fly (many do), or
>>> - The ipconfig code could bring the adapter down and up again, or
>>
>> looking at the ordering, bringing down the selected device to change the
>> MTU seems the more reasonable solution.
> 
> But you need to review all the drivers and make sure there are none
> which require the interface to be up in order to change the MTU.

Is there really such a driver / H/W? Seems like a bug to me that the
device has to be brought up to configure it. Very counter-intuitive.

> 
> So you might actually want to do is first try to change the MTU with
> the interface up. If that fails, try it with it down. That should not
> cause any regressions.
> 

yea, that would be the least invasive.