From: Hangbin Liu <hangbin.liu@linux.dev>
To: Nikolay Aleksandrov <razor@blackwall.org>
Cc: Jay Vosburgh <jv@jvosburgh.net>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Hangbin Liu <liuhangbin@kylinos.cn>
Subject: Re: [PATCH net v4 2/2] bonding: fix u32 overflow in compute_gap()
Date: Mon, 24 Aug 2026 09:33:50 +0800 [thread overview]
Message-ID: <aouffvAgf9fK-Sfd@fedora> (raw)
In-Reply-To: <d9b218ed-b7dc-40d3-90a2-24b5cdbe8f73@blackwall.org>
Hi Nikolay,
On Fri, Aug 21, 2026 at 04:12:31PM +0300, Nikolay Aleksandrov wrote:
> Completely untested, but something like:
>
> -static u64 compute_gap(struct slave *slave)
> +static s64 compute_gap(struct slave *slave)
> {
> u64 slave_load = SLAVE_TLB_INFO(slave).load << 3;
> u32 raw_speed = READ_ONCE(slave->speed);
> u64 speed = (u64)raw_speed << 20;
>
> if (raw_speed == (u32)SPEED_UNKNOWN)
> - return 0;
> -
> - if (speed <= slave_load)
> - return 0;
> + return S64_MIN;
>
> - return speed - slave_load;
> + return (s64)speed - (s64)slave_load;
> }
I get what you mean now. I think this is a boundary‑choice problem.
I reject all unknown‑speed and overloaded NICs, while you believe we should
keep overloaded NICs. What if someone argues we ought to retain unknown‑speed
but non‑overloaded NICs (though I do not see how we could compute that)?
In any case, I am fine with your design. If there are no other objections,
I will resend the patch following your plan.
Thanks
Hangbin
>
> Then change the selection variables and comparison:
>
> - u64 max_gap = 0;
> + s64 max_gap = S64_MIN;
>
> ...
>
> - u64 gap = compute_gap(slave);
> + s64 gap = compute_gap(slave);
>
> - if (max_gap <= gap) {
> + if (!least_loaded || max_gap < gap) {
>
> This should choose the slave with smallest gap and put the unknown speed behind all
> slaves with known speeds.
prev parent reply other threads:[~2026-08-24 1:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 5:55 [PATCH net v4 0/2] bonding: fix TLB load-tracking overflow on high-speed NICs Hangbin Liu
2026-08-20 5:55 ` [PATCH net v4 1/2] bonding: convert unbalanced_load to per-cpu state Hangbin Liu
2026-08-20 5:55 ` [PATCH net v4 2/2] bonding: fix u32 overflow in compute_gap() Hangbin Liu
2026-08-21 10:16 ` Nikolay Aleksandrov
2026-08-21 10:42 ` Hangbin Liu
2026-08-21 11:33 ` Nikolay Aleksandrov
2026-08-21 12:58 ` Hangbin Liu
2026-08-21 13:12 ` Nikolay Aleksandrov
2026-08-24 1:33 ` Hangbin Liu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aouffvAgf9fK-Sfd@fedora \
--to=hangbin.liu@linux.dev \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jv@jvosburgh.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuhangbin@kylinos.cn \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.