Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 27 Sep 2022 18:27:46 -0700
From:   Kevin Mitchell <kevmitch@arista.com>
To:     Antoine Tenart <atenart@kernel.org>
Cc:     Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: new warning caused by ("net-sysfs: update the queue counts in the
 unregistration path")
Message-ID: <YzOjEqBMtF+Ib72v@chmeee>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk

With the inclusion of d7dac083414e ("net-sysfs: update the queue counts in the
unregistration path"), we have started see the following message during one of
our stress tests that brings an interface up and down while continuously
trying to send out packets on it:

et3_11_1 selects TX queue 0, but real number of TX queues is 0

It seems that this is a result of a race between remove_queue_kobjects() and
netdev_cap_txqueue() for the last packets before setting dev->flags &= ~IFF_UP
in __dev_close_many(). When this message is displayed, netdev_cap_txqueue()
selects queue 0 anyway (the noop queue at this point). As it did before the
above commit, that queue (which I guess is still around due to reference
counting) proceeds to drop the packet and return NET_XMIT_CN. So there doesn't
appear to be a functional change. However, the warning message seems to be
spurious if not slightly confusing.

I'm not exactly sure what the fix for this should be or if there should be
one. In the meantime, we have ignored this message for this test, but was
wondering if there weren't any ideas for a better solution.

Thanks,
Kevin