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

Message-ID: <5072C961.3030807@st.com>
Date:	Mon, 08 Oct 2012 13:38:57 +0100
From:	Srinivas KANDAGATLA <srinivas.kandagatla@...com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC:PATCH 3.6.0-] net/ipconfig: Extend ipconfig retries to device
 open

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".

>
> The whole point of late initcalls is that you can be certain that they
> run after such things.
Yes I agree.
>
> Fix the virus not the symptom.
>
> I'm not applying this patch.

This use-case here is totally possible given that mdio bus can be
independent driver to MAC driver and Vice-versa.
So there might be situation at times that mdio bus driver might depend
on MAC driver, like in my case MAC driver has to setup itself to provide
clock to PHY's on MDIO bus before mdio-bus driver scan phys.
So using "Defered probe" feature for mdio-bus drivers will never work.

Thanks,
srini

--
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