linux-kernel - Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support

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: <20180831152131.GN30658@n2100.armlinux.org.uk>
Date:   Fri, 31 Aug 2018 16:21:31 +0100
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Antoine Tenart <antoine.tenart@...tlin.com>, davem@...emloft.net,
        kishon@...com, gregory.clement@...tlin.com, jason@...edaemon.net,
        sebastian.hesselbarth@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
        maxime.chevallier@...tlin.com, miquel.raynal@...tlin.com,
        nadavh@...vell.com, stefanc@...vell.com, ymarkman@...vell.com,
        mw@...ihalf.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net-next v3 02/10] net: mvpp2: phylink support

On Fri, Aug 31, 2018 at 04:37:21PM +0200, Andrew Lunn wrote:
> > Can you see any down-sides to moving the netif_carrier_off() in
> > mvneta_open() to phylink_start() ?
> 
> This sounds like a good idea.
> 
> What happens on the resume path?

Suspend/resume should be safe, because we force the link down when
phylink_stop() is called.

Looking at mvneta again, mvneta_stop_dev() is called in the suspend
path, which then calls phylink_stop().  This causes us to call
mac_link_down() and netif_carrier_off().  So, at the point of suspend,
the netdev carrier is set down and the mac taken down.

When resuming, mvneta_start_dev() calls phylink_start(), which undoes
the changes above, calling mac_link_up() if the link is now up.

So, as long as netdevs don't mess with the carrier state in their
suspend/resume functions, and they call phylink_start()/phylink_stop()
there, everything will work as intended - and that's really the key
issue here.

> I've not looked at any code.... Just thinking aloud. Can we suspend
> with the link up? When we resume, so long as we were not doing WoL,
> the link is down. If phylink_start() is not called, we have this miss
> match again.

It depends what you mean by "link up".  Are you talking about the PHYs
link to the external world (which is normally what's responsible for
handling WOL) or are you talking about keeping the MAC and its rings
alive so it can process packets while suspended.

If the former, that's the responsibility of phylib to manage, if the
latter, the netdev must not call phylink_stop() in its suspend function.

Either way, not messing with the netdev's carrier state is key.

The only exception to this is that the carrier should be down at open()
time.  However, I don't see anything in net/core that fiddles with the
carrier state for a net device, so the default state at boot should be
carrier-off.

I think some questions for Antoine are:

- what is the state of the carrier at the start of mvpp2_start() ?
- when does the missing call to mac_link_up() occur - is it the first
  time the netdev is brought up, or a subsequent time?
- is the carrier always off at the end of mvpp2_stop()?

Having a local reproducer may help, so if you can point to a DT fragment
and set of steps to reproduce, it could be helpful.

Thanks.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up