Message-ID: <20190604221626.4vjtsexoutqzblkl@shell.armlinux.org.uk>
Date:   Tue, 4 Jun 2019 23:16:26 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>
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, 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.

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

Powered by blists - more mailing lists