linux-kernel - Re: [PATCH v2 1/2] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ee37f457-3d2d-4c18-b22f-dfb315b3c078@davidv.dev>
Date: Sat, 10 Feb 2024 00:15:42 +0100
From: David <david@...idv.dev>
To: Andrew Lunn <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>
Cc: Jonathan Corbet <corbet@....net>, "David S. Miller"
 <davem@...emloft.net>, David Ahern <dsahern@...nel.org>,
 Eric Dumazet <edumazet@...gle.com>, 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>,
 "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
 open list <linux-kernel@...r.kernel.org>,
 "open list:NETWORKING [IPv4/IPv6]" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] net: make driver settling time configurable

On 2/9/24 23:11, Andrew Lunn wrote:
> On Fri, Feb 09, 2024 at 01:59:44PM -0800, Jakub Kicinski wrote:
>> On Thu,  8 Feb 2024 10:52:29 +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.
>> Please CC folks who gave you feedback, Andrew's is missing.
Thanks for the feedback, still learning this workflow
>>
>> Andrew, what do you think about just removing the wait?
>> Or decreasing it to 1ms?
>> It feels a little wasteful to be adding uAPI for something
>> which as you said is likely papering over ancient bugs. We'll
>> fix the bugs which are still around and the uAPI will stay
>> forever :(
> My guess is, the broken drivers are doing setup stuff after they call
> netdev_register().
>
> Reducing it to 1ms will probably continue to hide such bugs. So we
> could just go with that, and probably not see any regressions. Or we
> can decide we really do want to know about broken drivers, and just
> remove the delay.
>
> Either way, we don't need a new uAPI.

Would it make sense to move this to a build-time configuration flag?

I do not have a gut-feeling for which behaviors should be configurable

at build vs run time.

> David, is 1ms too long for you? If we do take the delay out, you are
> going to receive some of the flack from regression reports.

I've used this patch to experiment with different values, and the sleep time

behaves as described in Documentation/timers/timers-howto.rst, that is, a

call of `msleep(1)` usually delays boot time by 12~13 ms in my tests.

On top of this, I'm running this specific example on a no-smp systemm, 
where I

do not believe the `msleep` achieves anything (but I'm a kernel newbie 
so please

correct me if I'm wrong).

>
>        Andrew
>