Re: [PATCH v2 net 1/1] net: dsa: mv88e6xxx: Verify after ATU Load ops

[Andrew Lunn <andrew@lunn.ch>]

On Wed, Mar 05, 2025 at 03:28:27PM -0500, Joseph Huang wrote:
> ATU Load operations could fail silently if there's not enough space
> on the device to hold the new entry. When this happens, the symptom
> depends on the unknown flood settings. If unknown multicast flood is
> disabled, the multicast packets are dropped when the ATU table is
> full. If unknown multicast flood is enabled, the multicast packets
> will be flooded to all ports. Either way, IGMP snooping is broken
> when the ATU Load operation fails silently.
> 
> Do a Read-After-Write verification after each fdb/mdb add operation
> to make sure that the operation was really successful, and return
> -ENOSPC otherwise.
> 
> Fixes: defb05b9b9b4 ("net: dsa: mv88e6xxx: Add support for fdb_add, fdb_del, and fdb_getnext")
> Signed-off-by: Joseph Huang <Joseph.Huang@garmin.com>
> ---
> V1: https://lore.kernel.org/lkml/20250304235352.3259613-1-Joseph.Huang@garmin.com/
> V2: Add helper function to check the existence of an entry and only
>     call it in mv88e6xxx_port_fdb/mdb_add().

You need to start a new thread for each version of the
patch. Otherwise the tooling does not always recognise it.

> @@ -2847,6 +2870,13 @@ static int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
>  	err = mv88e6xxx_port_db_load_purge(chip, port, addr, vid,
>  					   MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC);
>  	mv88e6xxx_reg_unlock(chip);
> +	if (err)
> +		return err;
> +
> +	mv88e6xxx_reg_lock(chip);
> +	if (!mv88e6xxx_port_db_find(chip, addr, vid))
> +		err = -ENOSPC;
> +	mv88e6xxx_reg_unlock(chip);

unlocking and lock the registers seems to introduce a race
condition. Could another thread delete the just added entry before you
test to see if it was correctly added?

Please hold the lock across the entire operation.

    Andrew

---
pw-bot: cr