netdev - Re: [PATCH net-next] net: macb: allow MTU change when the interface is up

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: <277c78a696e27e77e34820ebf2f7a0d0ce5d0633.camel@bootlin.com>
Date: Tue, 26 Mar 2024 09:49:19 +0100
From: Thomas Perrot <thomas.perrot@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>, Simon Horman <horms@...nel.org>
Cc: Nicolas Ferre <nicolas.ferre@...rochip.com>, Claudiu Beznea
 <claudiu.beznea@...on.dev>, "David S . Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 netdev@...r.kernel.org,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: macb: allow MTU change when the interface
 is up

Hello,

On Mon, 2024-03-25 at 18:56 -0700, Jakub Kicinski wrote:
> On Mon, 25 Mar 2024 20:54:01 +0000 Simon Horman wrote:
> > I'm not sure that it is expected behaviour for an interface
> > to reset like this when a change of MTU is requested.
> > While conversely I think it is common (if not entirely desirable)
> > to prohibit changing the MTU when an interface is up.
> > What is the problem being addressed here?
> 

The problem being addressed here, is that NetworkManager isn't able to
apply the MTU value set in the connection configuration file because
the link is already up, then the change_mtu callback returns an error:

"NetworkManager[412]: <debug> [1709629970.1735] platform: (eth0) link:
setting mtu 1400                                                      
NetworkManager[412]: <trace> [1709629970.1737] platform-linux: delayed-
action: schedule wait-for-response-rtnl (seq 41, timeout in
0.199992796, response-type 0)                                         
NetworkManager[412]: <trace> [1709629970.1737] platform-linux: delayed-
action: schedule refresh-link (ifindex 2)                             
NetworkManager[412]: <trace> [1709629970.1738] platform-linux: delayed-
action: handle refresh-link (ifindex 2)                               
NetworkManager[412]: <debug> [1709629970.1738] platform-linux: do-
request-link: 2                                                       
NetworkManager[412]: <trace> [1709629970.1739] platform-linux: rtnl:
recvmsg: new message NLMSG_ERROR, flags 0, seq 41                     
NetworkManager[412]: <debug> [1709629970.1740] platform-linux: rtnl:
recvmsg: error message from kernel: Device or resource busy (-16) for
request 41"

Kind regards,
Thomas Perrot

> Right..
> 
> > >  	dev->mtu = new_mtu;
> > >  
> > > +	if (reset)
> > > +		macb_open(dev);
> 
> .. imagine admin does this over SSH on a remote box and system 
> is under memory pressure. Even ignoring the fact you're not checking
> the return value, the result of changing MTU should be either having 
> the requested MTU (success) or having the old MTU (failure).
> Not "machine drops off the network" :(
> 

-- 
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


Download attachment "signature.asc" of type "application/pgp-signature" (660 bytes)