Date:   Tue, 16 Nov 2021 15:53:35 +0200
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     Oleksij Rempel <o.rempel@pengutronix.de>, g@pengutronix.de,
        Woojung Huh <woojung.huh@microchip.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com,
        kernel@pengutronix.de, Jakub Kicinski <kuba@kernel.org>,
        Vivien Didelot <vivien.didelot@gmail.com>
Subject: Re: [RFC PATCH net-next] net: dsa: microchip: implement multi-bridge
 support
Message-ID: <20211116135335.j5mmvpnfzw4hfz67@skbuf>
References: <20211108111034.2735339-1-o.rempel@pengutronix.de>
 <20211110123640.z5hub3nv37dypa6m@skbuf>
 <20211112075823.GJ12195@pengutronix.de>
 <20211115234546.spi7hz2fsxddn4dz@skbuf>
 <20211116083903.GA16121@pengutronix.de>
 <20211116124723.kivonrdbgqdxlryd@skbuf>
 <20211116131657.GC16121@pengutronix.de>
 <YZO0tuMtDUIbRfcC@lunn.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YZO0tuMtDUIbRfcC@lunn.ch>
Precedence: bulk

On Tue, Nov 16, 2021 at 02:40:06PM +0100, Andrew Lunn wrote:
> > > What logging noise?
> > 
> > I get this with current ksz driver:
> > [   40.185928] br0: port 2(lan2) entered blocking state
> > [   40.190924] br0: port 2(lan2) entered listening state
> > [   41.043186] br0: port 2(lan2) entered blocking state
> > [   55.512832] br0: port 1(lan1) entered learning state
> > [   61.272802] br0: port 2(lan2) neighbor 8000.ae:1b:91:58:77:8b lost
> > [   61.279192] br0: port 2(lan2) entered listening state
> > [   63.113236] br0: received packet on lan1 with own address as source address (addr:00:0e:cd:00:cd:be, vlan:0)
> 
> I would guess that transmission from the CPU is broken in this
> case. It could be looking up the destination address in the
> translation table and not finding an entry. So it floods the packet
> out all interfaces, including the CPU. So the CPU receives its own
> packet and gives this warning.
> 
> Flooding should exclude where the frame came from.

I interpret this very differently. If Oleksij is looping lan1 with lan2
and he keeps the MAC addresses the way DSA sets them up by default, i.e.
equal and inherited from the DSA master, then receiving a packet with a
MAC SA (lan2) equal with the address of the receiving interface (lan1)
is absolutely natural. What is not natural is that the bridge attempts
to learn from this packet (the message is printed from br_fdb_update),
which in turn is caused by the fact that the port is allowed to proceed
to the LEARNING state despite there being a loop (which is not detected
by STP because STP is broken as Oleksij describes).