[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20191030.145234.1629187794527849559.davem@davemloft.net>
Date: Wed, 30 Oct 2019 14:52:34 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: Jose.Abreu@...opsys.com
Cc: netdev@...r.kernel.org, Joao.Pinto@...opsys.com,
peppe.cavallaro@...com, alexandre.torgue@...com,
mcoquelin.stm32@...il.com,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 4/9] net: stmmac: selftests: Must remove UC/MC
addresses to prevent false positives
From: Jose Abreu <Jose.Abreu@...opsys.com>
Date: Tue, 29 Oct 2019 15:14:48 +0100
> @@ -499,9 +501,18 @@ static int stmmac_test_hfilt(struct stmmac_priv *priv)
> if (netdev_mc_count(priv->dev) >= priv->hw->multicast_filter_bins)
> return -EOPNOTSUPP;
This test above...
> + dummy_dev = alloc_etherdev(0);
> + if (!dummy_dev)
> + return -ENOMEM;
> +
> + /* Remove all MC addresses */
> + netdev_for_each_mc_addr(ha, priv->dev)
> + dev_mc_add(dummy_dev, ha->addr);
> + dev_mc_flush(priv->dev);
No longer makes any sense now that you're removing all of the MC
addresses.
Also I know it seems that it should be guaranteed that re-adding all of
the previously configured MC addresses should succeed. But I am always
wary when I see error codes ignored like this.
This test makes destructure changes to the device's configuration,
perhaps in a non-restorable fashion if errors occur re-adding the MC
list entries.
Running a test should never even remotely introduce a change in the
device state like that.
I really don't like this, to be honest. I'd hate to be the user who
had this somehow trigger on them and then have to diagnose it. :-/
Powered by blists - more mailing lists