linux-kernel - Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY

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: <e69e9b50-3223-d5d4-e003-dd04e741387d@gmail.com>
Date:   Mon, 20 Mar 2017 09:41:52 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Roger Quadros <rogerq@...com>, Andrew Lunn <andrew@...n.ch>
Cc:     davem@...emloft.net, kyle.roeschley@...com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] net: phy: Don't miss phy_suspend() on PHY_HALTED for
 PHYs with interrupts

On 03/16/2017 12:46 AM, Roger Quadros wrote:
> On 15/03/17 17:49, Andrew Lunn wrote:
>> On Wed, Mar 15, 2017 at 05:00:08PM +0200, Roger Quadros wrote:
>>> Andrew,
>>>
>>> On 15/03/17 16:08, Andrew Lunn wrote:
>>>> On Wed, Mar 15, 2017 at 03:51:27PM +0200, Roger Quadros wrote:
>>>>> Since commit 3c293f4e08b5 ("net: phy: Trigger state machine on state change and not polling.")
>>>>> phy_suspend() doesn't get called as part of phy_stop() for PHYs using
>>>>> interrupts because the phy state machine is never triggered after a phy_stop().
>>>>>
>>>>> Explicitly trigger the PHY state machine so that it can
>>>>> see the new PHY state (HALTED) and suspend the PHY.
>>>>>
>>>>> Signed-off-by: Roger Quadros <rogerq@...com>
>>>>
>>>> Hi Roger
>>>>
>>>> This seems sensible. It mirrors what phy_start() does.
>>>>
>>>> Reviewed-by: Andrew Lunn <andrew@...n.ch>
>>>
>>> The reason for this being an RFC was the following comment just before
>>> where I add the phy_trigger_machine()
>>>
>>>         /* Cannot call flush_scheduled_work() here as desired because
>>>          * of rtnl_lock(), but PHY_HALTED shall guarantee phy_change()
>>>          * will not reenable interrupts.
>>>          */
>>>
>>> Is this comment still applicable? If yes, is it OK to call
>>> phy_trigger_machine() there?
>>
>> Humm, good question.
>>
>> My _guess_ would be, calling it with sync=True could
>> deadlock. sync=False is probably safe. But lets see what Florian says.
> 
> I agree that we should use phy_trigger_machine() with sync=False.
> 
>>
>>>
>>>>
>>>> It does however lead to a follow up question. Are there other places
>>>> phydev->state is changed and it is missing a phy_trigger_machine()?
>>>>
>>>
>>> One other place I think we should add phy_trigger_machine() is phy_start_aneg().
>>
>> Humm, that might get us into a tight loop.
>>
>> phy_start_aneg() kicks the phy driver to start autoneg and sets
>> phydev->state = PHY_AN.
>>
>> phy_trigger_machine() triggers the state machine immediately. 
>>
>> In state PHY_AN, we check if aneg is done. If not, it sets needs_aneg
>> = true. At the end of the state machine, this then calls
>> phy_start_aneg(), and it all starts again.
>>
>> We are missing the 1s delay we have with polling. So for
>> phy_start_aneg(), we might need a phy_delayed_trigger_machine(), which
>> waits a second before doing anything?
> 
> I think that should do the trick.
> 
> How about this?

This sounds like a possible fix indeed, however I would like to better
assess the impact on non interrupt driven PHYs before rolling such a change.

> 
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 8fef03b..162061c 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -630,6 +630,10 @@ int phy_start_aneg(struct phy_device *phydev)
>  
>  out_unlock:
>  	mutex_unlock(&phydev->lock);
> +
> +	if (!err)
> +		queue_delayed_work(system_power_efficient_wq, &phydev->state_queue, HZ);
> +
>  	return err;
>  }
>  EXPORT_SYMBOL(phy_start_aneg);
> 


-- 
Florian