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

[Thomas Perrot]

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

Attachment: signature.asc
Description: This is a digitally signed message part