netdev - Re: [RFC net-next 4/4] net: phy: Correctly process PHY_HALTED in phy_stop

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: <d7eadcfe-98ea-7316-7269-c60a55ed18d5@sigmadesigns.com>
Date:   Mon, 4 Dec 2017 16:08:19 +0100
From:   Marc Gonzalez <marc_gonzalez@...madesigns.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Florian Fainelli <f.fainelli@...il.com>
CC:     netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Andrew Lunn <andrew@...n.ch>, Doug Berger <opendmb@...il.com>,
        Mason <slash.tmp@...e.fr>, David Daney <david.daney@...ium.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: [RFC net-next 4/4] net: phy: Correctly process PHY_HALTED in
 phy_stop_machine()

On 27/11/2017 08:48, Geert Uytterhoeven wrote:

> The MDIO bus callback is not called from the network device ...
> 
>>> smsc hangs of [fec10000.bus, which is started only here --->
>>>
>>>     Workqueue: events_power_efficient phy_state_machine
>>>     [<c010f304>] (unwind_backtrace) from [<c010b7ec>] (show_stack+0x10/0x14)
>>>     [<c010b7ec>] (show_stack) from [<c0551ab0>] (dump_stack+0xa4/0xdc)
>>>     [<c0551ab0>] (dump_stack) from [<c0120480>] (__warn+0xcc/0xfc)
>>>     [<c0120480>] (__warn) from [<c0120554>] (warn_slowpath_null+0x1c/0x24)
>>>     [<c0120554>] (warn_slowpath_null) from [<c03ce264>] (__smsc911x_reg_read+0x1c/0x88)
>>>     [<c03ce264>] (__smsc911x_reg_read) from [<c03cefc8>] (smsc911x_mac_read+0x4c/0x118)
>>>     [<c03cefc8>] (smsc911x_mac_read) from [<c03cf320>] (smsc911x_mii_read+0x2c/0xa4)
>>>     [<c03cf320>] (smsc911x_mii_read) from [<c03cd490>] (mdiobus_read+0x58/0x70)
>>>     [<c03cd490>] (mdiobus_read) from [<c03cc4a0>] (genphy_update_link+0x18/0x50)
>>>     [<c03cc4a0>] (genphy_update_link) from [<c03cc4e4>] (genphy_read_status+0xc/0x1cc)
>>>     [<c03cc4e4>] (genphy_read_status) from [<c03ca3e4>] (phy_state_machine+0xa8/0x3f4)
>>>     [<c03ca3e4>] (phy_state_machine) from [<c013a740>] (process_one_work+0x240/0x3fc)
>>>     [<c013a740>] (process_one_work) from [<c013af28>] (worker_thread+0x2cc/0x40c)
>>>     [<c013af28>] (worker_thread) from [<c014024c>] (kthread+0x124/0x144)
>
> ... but from the worker thread, which is unaware of PM states, unless it is
> a freezable workqueue.
> 
> Cfr. my patch "[1/2] net: phy: Freeze PHY polling before suspending devices"
> (https://patchwork.kernel.org/patch/9915901/), which made it a freezable
> workqueue, like was done on PCI to solve similar issues with PME scanning.

Hello Geert, Florian,

Is there something I can do to help this patch move forward?

Should we look for a different solution than a synchronous call
to phy_state_machine() ? (Or should I call it from the device
driver, instead of expecting the phy framework to do it?)

Regards.