Re: [PATCH net-next v7 12/12] net: dsa: add driver for MaxLinear GSW1xx switch family

[Vladimir Oltean]

On Tue, Nov 04, 2025 at 08:03:07AM +0000, Sverdlin, Alexander wrote:
> The remaining failing test cases are:
> TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address   [FAIL]
>         reception succeeded, but should have failed
> TEST: VLAN over vlan_filtering=1 bridged port: Unicast IPv4 to unknown MAC address, allmulti   [FAIL]
>         reception succeeded, but should have failed
> 
> So far I didn't notice any problems with untagged read-word IP traffic over
> GSW145 ports.
> 
> Do you have a suggestion what could I check further regarding the failing
> test cases? As I understood, all of them pass on your side?

These failures mean that the test thinks the port implements IFF_UNICAST_FLT,
yet it doesn't drop unregistered traffic.

	[ $no_unicast_flt = true ] && should_receive=true || should_receive=false
	check_rcv $rcv_if_name "Unicast IPv4 to unknown MAC address" \
		"$smac > $UNKNOWN_UC_ADDR1, ethertype IPv4 (0x0800)" \
		$should_receive "$test_name"

But DSA doesn't report IFF_UNICAST_FLT for this switch, because it doesn't fulfill
the dsa_switch_supports_uc_filtering() requirements. So should_receive should have
been true, and the question becomes why does this code snippet set no_unicast_flt=false:

vlan_over_bridged_port()
{
	local no_unicast_flt=true
	local vlan_filtering=$1
	local skip_ptp=false

	# br_manage_promisc() will not force a single vlan_filtering port to
	# promiscuous mode, so we should still expect unicast filtering to take
	# place if the device can do it.
	if [ $(has_unicast_flt $h2) = yes ] && [ $vlan_filtering = 1 ]; then
		no_unicast_flt=false
	fi

Because IFF_UNICAST_FLT is not a UAPI-visible property, has_unicast_flt() does
an indirect check: it creates a macvlan upper with a different MAC address than
the physical interface's, and this results in a dev_uc_add() in the kernel.
If the unicast address is non-empty but the device doesn't have IFF_UNICAST_FLT,
__dev_set_rx_mode() makes the interface promiscuous, which has_unicast_flt()
then tests.

Something along this path is going wrong, because $(has_unicast_flt $h2)
returns yes, so $h2 didn't become promiscuous when adding the macvlan upper.

Could it be that $h2 needs to be up for has_unicast_flt() to work, and it's not?
I'm looking at __dev_set_rx_mode() in the kernel:

	/* dev_open will call this function so the list will stay sane. */
	if (!(dev->flags&IFF_UP))
		return;

	... the code below is skipped

	if (!(dev->priv_flags & IFF_UNICAST_FLT)) {
		/* Unicast addresses changes may only happen under the rtnl,
		 * therefore calling __dev_set_promiscuity here is safe.
		 */
		if (!netdev_uc_empty(dev) && !dev->uc_promisc) {
			__dev_set_promiscuity(dev, 1, false);
			dev->uc_promisc = true;
		} else if (netdev_uc_empty(dev) && dev->uc_promisc) {
			__dev_set_promiscuity(dev, -1, false);
			dev->uc_promisc = false;
		}
	}