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] [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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ