netdev - Re: [PATCH net] net: mdio: Prevent Clause 45 scan on SMSC PHYs

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]

Date: Sat, 6 Jan 2024 16:20:30 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Ezra Buehler <ezra@...yb.ch>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Tristram Ha <Tristram.Ha@...rochip.com>,
	Michael Walle <michael@...le.cc>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH net] net: mdio: Prevent Clause 45 scan on SMSC PHYs

On Sat, Jan 06, 2024 at 01:41:01PM +0100, Ezra Buehler wrote:
> On Tue, Jan 2, 2024 at 7:58 PM Russell King (Oracle)
> <linux@...linux.org.uk> wrote:
> >
> > Any ideas why the scan is taking so long?
> >
> > For each PHY address (of which there are 32) we scan each MMD between
> > 1 and 31 inclusive. We attempt to read the devices-in-package
> > registers. That means 32 * 32 * 2 calls to the mdiobus_c45_read(),
> > which is 2048 calls. Each is two MDIO transactions on the bus, so
> > that's 4096. Each is 64 bits long including preamble, and at 2.5MHz
> > (the "old" maximum) it should take about 100ms to scan the each
> > MMD on each PHY address to determine whether a device is present.
> >
> > I'm guessing the MDIO driver you are using is probably using a software
> > timeout which is extending the latency of each bus frame considerably.
> > Maybe that is where one should be looking if the timing is not
> > acceptable?
> 
> When profiling with ftrace, I see that executing macb_mdio_read_c45()
> takes about 20ms. The function calls  macb_mdio_wait_for_idle() 3 times,
> where the latter 2 invocations take about 10ms each. The
> macb_mdio_wait_for_idle() function invokes the read_poll_timeout() macro
> with a timeout of 1 second, which we obviously do not hit.
> 
> To me it looks like we are simply waiting for the hardware to perform
> the transaction, i.e. write out the address and read the register (which
> is read as 0xFFFF).
> 
> I've checked the MDIO clock, it is at 2MHz.
> 
> So, any suggestions for what to look into next?

Does a C22 read/write call to macb_mdio_wait_for_idle() take as long?

Could you hack a copy of readx_poll_timeout() and real_poll_timeout()
into the driver, and extend it to count how many times it goes around
the loop. Is the usleep_range() actually sleeping for 10ms because you
don't have any high resolution clocks, and a 100Hz tick? If so, you
might want to swap to 1000Hz tick, or NO_HZ, or enable a high
resolution clock, so that usleep_range() can actually sleep for short
times.

	   Andrew