linux-kernel - Re: [PATCH] driver core: Prevent deferred probe loops

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: <2025061147-squishier-oversleep-80cd@gregkh>
Date: Wed, 11 Jun 2025 08:23:40 -0400
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Sean Anderson <sean.anderson@...ux.dev>
Cc: Saravana Kannan <saravanak@...gle.com>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, Christoph Hellwig <hch@....de>,
	Rob Herring <robh+dt@...nel.org>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH] driver core: Prevent deferred probe loops

On Tue, Jun 10, 2025 at 07:44:27PM -0400, Sean Anderson wrote:
> On 6/10/25 19:32, Saravana Kannan wrote:
> > On Tue, Jun 10, 2025 at 11:35 AM Sean Anderson <sean.anderson@...ux.dev> wrote:
> >>
> >> A deferred probe loop can occur when a device returns EPROBE_DEFER after
> >> registering a bus with children:
> > 
> > This is a broken driver. A parent device shouldn't register child
> > devices unless it is fully read itself. It's not logical to say the
> > child devices are available, if the parent itself isn't fully ready.
> > So, adding child devices/the bus should be the last thing done in the
> > parent's probe function.
> >
> > I know there are odd exceptions where the parent depends on the child,
> > so they might add the child a bit earlier in the probe
> 
> This is exactly the case here. So the bus probing cannot happen any
> later than it already does.

Please fix the driver not to do this.

> > but in those cases, the parent's probe should still do all the checks
> > ahead of time.
> 
> Such as what? How is the parent going to know the resource is missing
> without checking for it?
>  
> > Can you be more specific about the actual failure you are seeing?
> 
> MAC is looking for a PCS that's on its internal MDIO bus, but that PCS's
> driver isn't loaded. The PCS has to be loaded at probe time because
> phylink_create needs it, and phylink is necessary to register the
> netdev. The latter situation is not ideal, but it would be quite a bit
> of work to untangle.

Please untangle, don't put stuff in the driver core for broken
subsystems.  That is just pushing the maintaince of this from the driver
authors to the driver core maintainers for the next 20+ years :(

thanks,

greg k-h