linux-kernel - Re: [PATCH] net: fec: defer probe if PHY on external MDIO bus is not available

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:   Tue, 26 Oct 2021 13:54:29 +0200
From:   Matthias Schiffer <matthias.schiffer@...tq-group.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Joakim Zhang <qiangqing.zhang@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: fec: defer probe if PHY on external MDIO bus is
 not available

On Fri, 2021-10-22 at 14:56 +0200, Andrew Lunn wrote:
> > Hmm, lots of network drivers? I tried to find an example, but all
> > drivers that generate -EPROBE_DEFER for missing PHYs at all don't have
> > an internal MDIO bus and thus avoid the circular dependency.
> 
> Try drivers/net/dsa.
> 
> These often have mdio busses which get registered and then
> unregistered. There are also IRQ drivers which do the same.
> 
> 	Andrew

All drivers I looked at were careful to register the MDIO bus in the
last part of the probe function, so that the only errors that could 
happen after that (and thus require to unregister the bus device again)
would not be -EPROBE_DEFER.

The documented infinite loop is easy to reproduce: You just need two
separate device instances with misbehaving probe() functions that
return -EPROBE_DEFER after registering and unregistering some
subdevice. If the missing device that causes the deferral never appears
(for example because its driver is not available), the two devices will
be probed ad infinitum.

I agree with the documentation that a driver should not do this, and
thus we need another way to deal with the cyclic dependency between an
Ethernet interface and a PHY on its internal MDIO bus.

While I think that a generic solution would be theoretically possible
by ensuring that the probing loop makes some kind of "progress", I
think this would set a precedent for "expensive" operations happening
before a -EPROBE_DEFER return, which should be avoided even when no
infinite loop results.

Matthias