netdev - Re: [PATCH] net: make driver settling time configurable

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: <580001e3-17ef-4f24-8fd8-bc14110e874e@lunn.ch>
Date: Mon, 5 Feb 2024 16:20:20 +0100
From: Andrew Lunn <andrew@...n.ch>
To: David <david@...idv.dev>
Cc: Jonathan Corbet <corbet@....net>,
	"David S. Miller" <davem@...emloft.net>,
	David Ahern <dsahern@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Xiongwei Song <xiongwei.song@...driver.com>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] net: make driver settling time configurable

On Mon, Feb 05, 2024 at 03:31:38PM +0100, David wrote:
> On 2/5/24 15:06, Andrew Lunn wrote:
> > On Mon, Feb 05, 2024 at 12:44:40PM +0100, David Ventura wrote:
> > > During IP auto configuration, some drivers apparently need to wait a
> > > certain length of time to settle; as this is not true for all drivers,
> > > make this length of time configurable.
> > Do you see this problem with multiple drivers, or just one in
> > particular. To me this seems like a driver bug, and you are just
> > papering over the cracks.
> > 
> > 	Andrew
> I don't know of any drivers that may need to wait -- I noticed
> this code path being hit when building a minimal kernel that only
> had a virtio network device.
> At least for the virtio device, the wait is unnecessary and bloats
> the time to boot a minimal kernel from 15ms to 33ms.

Looking at the code, a delay has been here a long time, since before
git. However, 2011 the delay was changes from 1 second to 10ms. There
was a discussion about this at the time:

https://lore.kernel.org/netdev/1305696161-18277-1-git-send-email-micha@neli.hopto.org/t/

It was said that ARP and DHCP retries should recover any system where
the first transmit/receive gets lost with the change from 1s to 10ms.

Maybe after 12 years, its time to try a default of 0ms? I would
suggest that is a second patch, which is easy to revert if it all goes
horribly wrong.

	 Andrew