[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260126194710.5a154b8c@kernel.org>
Date: Mon, 26 Jan 2026 19:47:10 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: tariqt@...dia.com
Cc: Kery Qi <qikeyu2017@...il.com>, andrew+netdev@...n.ch,
davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
jackm@....mellanox.co.il, ogerlitz@...lanox.com, monis@...lanox.com,
netdev@...r.kernel.org, linux-rdma@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net/mlx4: fix MAC table total count corruption in
__mlx4_unregister_mac()
On Fri, 23 Jan 2026 02:39:07 +0800 Kery Qi wrote:
> In __mlx4_unregister_mac(), when operating in mf_bonded mode
> (SR-IOV with bonding), it appears that the code might be incorrectly
> decrementing table->total instead of dup_table->total when cleaning
> up the duplicate table entry.
>
> If this is the case, it would cause the primary table's total counter
> to be decremented twice (once for itself and once when it should
> decrement the duplicate table), leading to counter corruption.
> Over time, table->total could become negative, which would
> break the "table->total == table->max" fullness check in
> __mlx4_register_mac().
>
> The registration path correctly increments both counters:
> ++table->total;
> if (dup) {
> ...
> ++dup_table->total;
> }
>
> However, the unregistration path seems to have a typo:
> --table->total;
> if (dup) {
> ...
> --table->total; // Should this be --dup_table->total?
Looks legit, Tariq? Are you trying to find/dust off an mlx4 card? :)
Powered by blists - more mailing lists