netdev - Re: [RFC:PATCH 3.6.0-] net/ipconfig: Extend ipconfig retries to device open

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] [day] [month] [year] [list]

Message-Id: <20121008.141403.36402742873454814.davem@davemloft.net>
Date:	Mon, 08 Oct 2012 14:14:03 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	srinivas.kandagatla@...com
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC:PATCH 3.6.0-] net/ipconfig: Extend ipconfig retries to
 device open

From: Srinivas KANDAGATLA <srinivas.kandagatla@...com>
Date: Mon, 08 Oct 2012 13:38:57 +0100

> On 07/10/12 05:11, David Miller wrote:
>> From: Srinivas KANDAGATLA <srinivas.kandagatla@...com>
>> Date: Thu,  4 Oct 2012 16:38:43 +0100
>>
>>> This patch adds retries to ipconfig at device open, the reason to do
>>> this is: Lets say If some mdio bus driver decide to use defered probe
>>> when it does not find any phys on the bus. The same mdio-bus driver is
>>> re-probed as part of lateinit calls. However ipconfig also fits into
>>> lateinit calls, so if ipconfig is called before the re-probe of mdio-bus
>>> driver, the mac driver will fail to find a valid PHY on the mdio-bus.
>> Real device drivers for real devices should not probe using late
>> initcalls.
> I agree,
> Let me summarize what I did try.
> 
> I wanted to use "Defered Probe Feature" which went in 3.4 kernel to
> solve a sequencing issue.
> So modified Mdio-driver accordingly, mdio-driver decided to defer its
> probe for the first-time when It could not detect any PHY's on the BUS.
> (second time) device probe is actually called in lateinit call sequence
> by "Defered Probe Code".

That's not how we probe "devices on a bus" which is the model you
should be following here to fix this bug.

Just delaying is going to run into corner cases where things do not
work.  You need cooperation between bus provider and bus consumer,
full stop.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html