linux-kernel - Re: [PATCH] net: stmmac: synchronize stmmac_open and stmmac_dvr

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:   Mon, 26 Dec 2016 21:10:09 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     "Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Giuseppe CAVALLARO <peppe.cavallaro@...com>,
        seraphin.bonnaffe@...com
Cc:     Alexandre TORGUE <alexandre.torgue@...il.com>,
        Joachim Eastwood <manabian@...il.com>,
        Niklas Cassel <niklas.cassel@...s.com>,
        Johan Hovold <johan@...nel.org>, pavel@....cz,
        Ong Boon Leong <boon.leong.ong@...el.com>,
        netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, weifeng.voon@...el.com,
        Lars Persson <lars.persson@...s.com>
Subject: Re: [PATCH] net: stmmac: synchronize stmmac_open and stmmac_dvr_probe



On 12/27/2016 03:44 AM, Kweh, Hock Leong wrote:
> From: "Kweh, Hock Leong" <hock.leong.kweh@...el.com>
> 
> If kernel module stmmac driver being loaded after OS booted, there is a
> race condition between stmmac_open() and stmmac_mdio_register(), which is
> invoked inside stmmac_dvr_probe(), and the error is showed in dmesg log as
> PHY not found and stmmac_open() failed:
> [  473.919358] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
> 		stmmac_dvr_probe: warning: cannot get CSR clock
> [  473.919382] stmmaceth 0000:01:00.0: no reset control found
> [  473.919412] stmmac - user ID: 0x10, Synopsys ID: 0x42
> [  473.919429] stmmaceth 0000:01:00.0: DMA HW capability register supported
> [  473.919436] stmmaceth 0000:01:00.0: RX Checksum Offload Engine supported
> [  473.919443] stmmaceth 0000:01:00.0: TX Checksum insertion supported
> [  473.919451] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
> 		Enable RX Mitigation via HW Watchdog Timer
> [  473.921395] libphy: PHY stmmac-1:00 not found
> [  473.921417] stmmaceth 0000:01:00.0 eth0: Could not attach to PHY
> [  473.921427] stmmaceth 0000:01:00.0 eth0: stmmac_open: Cannot attach to
> 		PHY (error: -19)
> [  473.959710] libphy: stmmac: probed
> [  473.959724] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 0 IRQ POLL
> 		(stmmac-1:00) active
> [  473.959728] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 1 IRQ POLL
> 		(stmmac-1:01)
> [  473.959731] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 2 IRQ POLL
> 		(stmmac-1:02)
> [  473.959734] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 3 IRQ POLL
> 		(stmmac-1:03)
> 
> The resolution used wait_for_completion_interruptible() to synchronize
> stmmac_open() and stmmac_dvr_probe() to prevent the race condition
> happening.

The proper fix for this would be to have register_netdev() be the last
thing done in stmmac_drv_probe(), whereas right now, the last thing done
is stmmac_mdio_register(), leading the window you are seeing here, where
the network interface can be open prior to all resources being set up,
including, but not limited to MDIO devices.
-- 
Florian