linux-kernel - Re: [PATCH net 4/4] net: axienet: Split into MAC and MDIO drivers

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: <0854ddee-1b53-472c-a4fe-0a345f65da65@linux.dev>
Date: Mon, 23 Jun 2025 11:16:08 -0400
From: Sean Anderson <sean.anderson@...ux.dev>
To: Andrew Lunn <andrew@...n.ch>
Cc: Radhey Shyam Pandey <radhey.shyam.pandey@....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>,
 netdev@...r.kernel.org, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Michal Simek <michal.simek@....com>, Saravana Kannan <saravanak@...gle.com>,
 Leon Romanovsky <leon@...nel.org>, Dave Ertman <david.m.ertman@...el.com>,
 linux-kernel@...r.kernel.org, Ira Weiny <ira.weiny@...el.com>,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net 4/4] net: axienet: Split into MAC and MDIO drivers

On 6/21/25 03:33, Andrew Lunn wrote:
> On Thu, Jun 19, 2025 at 04:05:37PM -0400, Sean Anderson wrote:
>> Returning EPROBE_DEFER after probing a bus may result in an infinite
>> probe loop if the EPROBE_DEFER error is never resolved.
> 
> That sounds like a core problem. I also thought there was a time
> limit, how long the system will repeat probes for drivers which defer.
> 
> This seems like the wrong fix to me.

I agree. My first attempt to fix this did so by ignoring deferred probes
from child devices, which would prevent "recursive" loops like this one
[1]. But I was informed that failing with EPROBE_DEFER after creating a
bus was not allowed at all, hence this patch.

Limiting the number of deferred probe attempts (at least before
continuing to boot) is a good idea in theory, but would not address the
root of the issue. Setting a good threshold is not obvious, since there
are almost certainly systems out there that are missing some device
links and have a lot of deferred probes. 

--Sean

[1] https://lore.kernel.org/all/CAGETcx-koKBvSXTHChYYF-qSU-r1cBUbLghJZcqtJOGQZjn3BA@mail.gmail.com/