Re: [PATCH v3 net-next 02/14] net: enetc: extract common helpers for MAC hash filter configuration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but when the exact match MAC filter fails to be programmed, the fallback to hash table (HT) filtering configures the hardware with a corrupted hash bitmask.
--

commit 7a34e5eaa6513d77933432617ababa625bd03ac3
Author: Wei Fang <wei.fang@nxp.com>

    net: enetc: extract common helpers for MAC hash filter configuration
    
    The PSIUMHFR and PSIMMHFR registers in ENETC v4 have the same bit layout
    as in ENETC v1. The only difference between the two hardware generations
    is the register address offsets.
    
    Since the register functionality is identical, the MAC hash filter
    configuration code can be shared between the ENETC v1 and v4 drivers.
    Extract two new common helper functions, enetc_set_si_uc_hash_filter()
    and enetc_set_si_mc_hash_filter(), into enetc_pf_common.c.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> index a97d2e2dd07b7..db2a800a7aaf0 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c

[ ... ]

> @@ -135,7 +108,7 @@ static void enetc_sync_mac_filters(struct enetc_pf *pf)
>  		if (em) {
>  			int err;
>  
> -			enetc_clear_mac_ht_flt(si, 0, UC);
> +			enetc_set_si_uc_hash_filter(si, 0, 0);
>  
>  			err = enetc_set_mac_flt_entry(si, pos, f->mac_addr,
>  						      BIT(0));
> @@ -147,11 +120,15 @@ static void enetc_sync_mac_filters(struct enetc_pf *pf)
>  				 err);
>  		}
>  
> +		bitmap_to_arr64(&hash, f->mac_hash_table,
> +				ENETC_MADDR_HASH_TBL_SZ);
>  		/* hash table filter, clear EM filter for UC entries */
> -		if (i == UC)
> +		if (i == UC) {
>  			enetc_clear_mac_flt_entry(si, pos);
> -
> -		enetc_set_mac_ht_flt(si, 0, i, *f->mac_hash_table);
> +			enetc_set_si_uc_hash_filter(si, 0, hash);
> +		} else {
> +			enetc_set_si_mc_hash_filter(si, 0, hash);
> +		}
>  	}
>  }

[Severity: High]
This isn't a bug introduced by this patch, but when the exact match (EM) MAC
filter fails to be programmed, the fallback to hash table (HT) filtering
appears to configure the hardware with a corrupted hash bitmask.

Because mac_addr and mac_hash_table share a union in struct enetc_mac_filter:

	union {
		char mac_addr[ETH_ALEN];
		DECLARE_BITMAP(mac_hash_table, ENETC_MADDR_HASH_TBL_SZ);
	};

and the exact match path populated mac_addr, doesn't f->mac_hash_table now
just contain the raw bytes of the MAC address?

If so, won't bitmap_to_arr64() (and the prior enetc_set_mac_ht_flt() code)
read the raw MAC address bytes as if they were a bitmap of hash indices?
This seems like it would result in the hardware being programmed with a
corrupted MAC hash filter, leading to silently dropping incoming packets for
the correct MAC address.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703101328.550714-1-wei.fang@oss.nxp.com?part=2