netdev - Re: [RFC] increase MDIO i2c poll timeout gradually (including patch)

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: <3fab95da-95c8-4cf5-af16-4b576095a1d9@kabelmail.de>
Date: Mon, 22 Sep 2025 12:54:20 +0200
From: Janpieter Sollie <janpieter.sollie@...elmail.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
 Heiner Kallweit <hkallweit1@...il.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [RFC] increase MDIO i2c poll timeout gradually (including patch)

Op 22/09/2025 om 10:04 schreef Janpieter Sollie:
> Op 20/09/2025 om 15:53 schreef Russell King (Oracle):
>> So, what we need you to do is to work out how long it takes this module
>> to respond, and whether it always takes a long time to respond. Please
>> add some debugging to i2c_rollball_mii_poll() to measure the amount of
>> time it takes for the module to respond - and please measure it for
>> several transactions.
>>
>> You can use jiffies, and convert to msecs using jiffies_to_msecs(),
>> or you could use ktime_get_ns().
>>
>> Thanks.
>>
>
> All right, so I changed the modification to a more debug-friendly function (view below).
> I also changed the incremental wait() function from (20+10*(10-i)) to (20+5*(10-i)) to be more 
> accurate.
>
> [156732.241897] i2c_rollball_mii_poll:267: mdio_bus i2c:sfp2: poll cmd success after 398065122 
> ns in iteration 3
> [156732.581982] i2c_rollball_mii_poll:267: mdio_bus i2c:sfp2: poll cmd success after 328157082 
> ns in iteration 4
> [156732.921978] i2c_rollball_mii_poll:267: mdio_bus i2c:sfp2: poll cmd success after 327986467 
> ns in iteration 4
>
> ...
>

Something I noticed when going through a lot more iterations:

FYI: The kernel has been compiled with a 100hz timer, tickless idle and no kernel preemption.
I wanted to count how much the system actually runs those i2c calls, substracting msleep,
which is 20, 245 and 300, respectively.

So, I separated i = 10, i = 4 and i = 3 a bit.
 > 192 numbers for i = 10
 > 2309 numbers for i = 4
 > 1129 numbers for i = 3

and calculating max and min, substracting the msleep:

 > 1 function call max: 20131327
 > 1 function call min: 9990574
 > diff at iteration 10: 10140753
 > avg at iteration 10:  10723993

 > 7 function calls min: 82868351
 > 7 function calls max:  123074939
 > diff at iteration 4: 40206588
 > avg at iteration 4: 86375811

 > 8 function calls min: 97889217
 > 8 function calls max: 128086531
 > diff at iteration 3: 30197314
 > avg at iteration 3: 99901858

this is a diff of 10usecs (i=10), 40usecs (i=4) and 30usecs (i=3) my device is running the 
i2c_transfer_rollball().
seems a lot to me when an i2c call takes 11-12 usecs avg per call
are you sure these numbers point to a stable i2c bus?

thanks,

Janpieter Sollie