[<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)
Powered by blists - more mailing lists