Message-ID: <CA+h21hrkQkBocwigiemhN_H+QJ3yWZaJt+aoBWhZiW3BNNQOXw@mail.gmail.com>
Date:   Wed, 5 Jun 2019 01:44:08 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Ioana Ciornei <ioana.ciornei@....com>
Subject: Re: Cutting the link on ndo_stop - phy_stop or phy_disconnect?

On Wed, 5 Jun 2019 at 01:16, Russell King - ARM Linux admin
<linux@...linux.org.uk> wrote:
>
> On Wed, Jun 05, 2019 at 01:03:27AM +0300, Vladimir Oltean wrote:
> > On Wed, 5 Jun 2019 at 00:48, Russell King - ARM Linux admin
> > <linux@...linux.org.uk> wrote:
> > >
> > > On Tue, Jun 04, 2019 at 02:37:31PM -0700, Florian Fainelli wrote:
> > > > The firmware/boot loader transition to a full fledged OS with a switch
> > > > is a tricky one to answer though, and there are no perfect answers
> > > > AFAICT. If your SW is totally hosed, you might want the switch to
> > > > forward traffic between all LAN ports (excluding WAN, otherwise you
> > > > expose your home devices to the outside world, whoops).
> > > >
> > > > If your SW is fully operational, then the questions are:
> > > >
> > > > - do you want a DSA like behavior in your boot loader, in that all ports
> > > > are separated but fully usable or do you want a dumb switch model where
> > > > any port can forward to the CPU/management port, without any tags or
> > > > anything (unmanaged mode)
> > > >
> > > > - what happens during bootloader to OS handover, should the switch be
> > > > held in reset so as to avoid any possible indirect DMA into main memory
> > > > as much as power saving? Should nothing happen and let the OS wipe out
> > > > clean the setting left by the boot loader?
> > > >
> > > > All of these are in the realm of policy and trade offs as far as
> > > > initializing/disruption goes, so there are no hard and fast answers.
> > >
> > > For a switch, there are four stages, not two:
> > >
> > > 1. The out-of-reset state, which from what I've seen seems to be to
> > >    behave like a dumb switch.
> > >
> > > 2. The boot loader state, which is generally the same as the
> > >    out-of-reset state.
> > >
> > > 3. The OS-booting state, which for a DSA switch in Linux isolates each
> > >    port from each other.
> > >
> > > 4. The OS-booted state, which depends on the system configuration.
> > >
> > > If you are setting up a switch in a STP environment, you _have_ to be
> > > aware of all of those states, and plan your network accordingly.
> > > While it's possible to argue that the boot loader should isolate the
> > > ports, it may be that the system gets hosed to the point that the boot
> > > loader is unable to run - then you have a switch operating in a STP
> > > environment acting as a dumb switch.
> > >
> > > The same actually goes for many switches - consider your typical DSL
> > > router integrated with a four port switch.  By default, that switch
> > > forwards traffic between each port.  If you've setup the ports to be
> > > isolated, each time the router is rebooted (e.g., due to a
> > > configuration change) it will forward traffic between all ports until
> > > the routers OS has finished booting and applied the switch
> > > configuration.
> > >
> > > What I'm basically saying is that if you're going to the point of
> > > using such hardware in a STP environment, you _must_ pay attention
> > > to the behaviour of the hardware through all phases of its operation
> > > and consider the consequences should it fail in any of those phases.
> > >
> > > --
> > > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> > > According to speedtest.net: 11.9Mbps down 500kbps up
> >
> > Hi Russell,
> >
> > The dumb switch was just an example. The absolute same thing (unwanted
> > PHY connection) applies to regular NICs. I am not aware of any setting
> > that makes the MAC ignore frames as long as they observe the
> > appropriate MII spec. And the hardware will go on to process those
> > frames, potentially calling into the operating system and making it
> > susceptible to denial of service.
>
> Having authored several network device drivers, and worked on several
> others, I think you have a misunderstanding somewhere.
>

You caught me.

But even ignoring the NIC case, isn't the PHY state machine
inconsistent with itself? It is ok with callink phy_suspend upon
ndo_stop, but it won't call phy_suspend after phy_connect, when the
netdev is implicitly stopped?

> It is not expected that the MAC will be "alive" while the network
> interface is down - it is expected that the MAC will be disabled, and
> memory necessary for buffer rings etc will not be claimed.
>
> > That is unless you set up your
> > buffer rings/queues/whatever in the ndo_open/ndo_close callbacks.
>
> So yes, that is what is expected - so that when the interface is down,
> the memory needed for the buffer rings and packet buffers is given
> back to the system for other uses.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up

Regards,
-Vladimir

Powered by blists - more mailing lists