[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4d02c697-aad9-87af-4879-abfff38ee67c@gmail.com>
Date: Mon, 21 Mar 2022 19:07:13 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org
Cc: Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH net-next] net: dsa: fix missing host-filtered multicast
addresses
On 3/21/2022 5:37 PM, Vladimir Oltean wrote:
> DSA ports are stacked devices, so they use dev_mc_add() to sync their
> address list to their lower interface (DSA master). But they are also
> hardware devices, so they program those addresses to hardware using the
> __dev_mc_add() sync and unsync callbacks.
>
> Unfortunately both cannot work at the same time, and it seems that the
> multicast addresses which are already present on the DSA master, like
> 33:33:00:00:00:01 (added by addrconf.c as in6addr_linklocal_allnodes)
> are synced to the master via dev_mc_sync(), but not to hardware by
> __dev_mc_sync().
>
> This happens because both the dev_mc_sync() -> __hw_addr_sync_one()
> code path, as well as __dev_mc_sync() -> __hw_addr_sync_dev(), operate
> on the same variable: ha->sync_cnt, in a way that causes the "sync"
> method (dsa_slave_sync_mc) to no longer be called.
>
> To fix the issue we need to work with the API in the way in which it was
> intended to be used, and therefore, call dev_uc_add() and friends for
> each individual hardware address, from the sync and unsync callbacks.
>
> Fixes: 5e8a1e03aa4d ("net: dsa: install secondary unicast and multicast addresses as host FDB/MDB")
> Link: https://lore.kernel.org/netdev/20220321163213.lrn5sk7m6grighbl@skbuf/
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
--
Florian
Powered by blists - more mailing lists