netdev - Re: [RFC PATCH v2] netpoll: Remove 4s sleep during carrier detection

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] [day] [month] [year] [list]

Message-ID: <Y86SGI5QMBS5kAI4@lunn.ch>
Date:   Mon, 23 Jan 2023 14:56:40 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Breno Leitao <leitao@...ian.org>, netdev@...r.kernel.org,
        leit@...com, davem@...emloft.net, edumazet@...gle.com,
        pabeni@...hat.com, sa+renesas@...g-engineering.com,
        linux-kernel@...r.kernel.org,
        Michael van der Westhuizen <rmikey@...a.com>
Subject: Re: [RFC PATCH v2] netpoll: Remove 4s sleep during carrier detection

On Thu, Jan 19, 2023 at 11:04:21AM -0800, Jakub Kicinski wrote:
> On Thu, 19 Jan 2023 10:00:08 -0800 Breno Leitao wrote:
> > This patch proposes to remove the msleep(4s) during netpoll_setup() if
> > the carrier appears instantly.
> > 
> > Modern NICs do not seem to have this bouncing problem anymore, and this
> > sleep slows down the machine boot unnecessarily

I'm not sure 'bouncing' is the correct word here. That would imply up,
down, up, down and then stable up. What i guess the real issue here
was the MAC driver said the link was up while autoneg was still
happening, which takes around 1.5 seconds.

> We should mention in the message that the wait is counter-productive on
> servers which have BMC communicating over NC-SI via the same NIC as gets
> used for netconsole. BMC will keep the PHY up, hence the carrier
> appearing instantly.
> 
> We could add a smaller delay, but really having instant carrier and
> then loosing it seems like a driver bug, so let's try to rip the band
> aid off and ask for forgiveness instead.

It would be good to put some of this into the commit message. Explain
the case you see it go wrong.

The other scenarios i can think of are:

The bootloader configured the interface up, and used the interface,
e.g. to tftp boot. The PHY was left up when transitioning into
Linux. Hence there is no need to wait around 1.5 seconds for autoneg
to complete.

The link is fibre, SERDES getting sync could happen within 0.1Hz, and
so it appears to be instantaneously.

This work around does seem very old, pre-git times, so i also doubt
there are many systems which are truly broken like this.

      Andrew