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]: [1709629970.1735] platform: (eth0) link: setting mtu 1400 NetworkManager[412]: [1709629970.1737] platform-linux: delayed- action: schedule wait-for-response-rtnl (seq 41, timeout in 0.199992796, response-type 0) NetworkManager[412]: [1709629970.1737] platform-linux: delayed- action: schedule refresh-link (ifindex 2) NetworkManager[412]: [1709629970.1738] platform-linux: delayed- action: handle refresh-link (ifindex 2) NetworkManager[412]: [1709629970.1738] platform-linux: do- request-link: 2 NetworkManager[412]: [1709629970.1739] platform-linux: rtnl: recvmsg: new message NLMSG_ERROR, flags 0, seq 41 NetworkManager[412]: [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