netdev - Re: [PATCH] net: usb: lan78xx: Enforce a minimum interrupt polling period

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: <11f5be1d-9250-4aba-8f51-f231b09d3992@lunn.ch>
Date: Mon, 10 Mar 2025 22:27:03 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Fiona Klute <fiona.klute@....de>
Cc: netdev@...r.kernel.org,
	Thangaraj Samynathan <Thangaraj.S@...rochip.com>,
	Rengarajan Sundararajan <Rengarajan.S@...rochip.com>,
	UNGLinuxDriver@...rochip.com, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel-list@...pberrypi.com, stable@...r.kernel.org
Subject: Re: [PATCH] net: usb: lan78xx: Enforce a minimum interrupt polling
 period

On Mon, Mar 10, 2025 at 05:59:31PM +0100, Fiona Klute wrote:
> If a new reset event appears before the previous one has been
> processed, the device can get stuck into a reset loop. This happens
> rarely, but blocks the device when it does, and floods the log with
> messages like the following:
> 
>   lan78xx 2-3:1.0 enp1s0u3: kevent 4 may have been dropped
> 
> The only bit that the driver pays attention to in the interrupt data
> is "link was reset". If there's a flapping status bit in that endpoint
> data (such as if PHY negotiation needs a few tries to get a stable
> link), polling at a slower rate allows the state to settle.

Could you expand on this a little bit more. What is the issue you are
seeing?

I had a quick look at the PHY handling code, and it looks broken. The
only time a MAC driver should look at members of phydev is during the
adjust link callback, so lan78xx_link_status_change(). Everything is
guaranteed to be consistent at this time. However, the current
lan78xx_link_status_change() only adjusts EEE setting. The PHY code in
lan78xx_link_reset() looks wrong. MAC drivers should not be reading
PHY registers, or calling functions like phy_read_status(). Setting
flow control should be performed in lan78xx_link_status_change() using
phydev->pause and phydev->asym_pause.

	Andrew