From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
kernel test robot <lkp@intel.com>,
netdev@vger.kernel.org, oe-kbuild-all@lists.linux.dev,
"David S . Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>, Liang Li <liali@redhat.com>,
Vincent Bernat <vincent@bernat.ch>
Subject: Re: [PATCH net 1/4] bonding: fix send_peer_notif overflow
Date: Thu, 20 Apr 2023 22:13:17 -0700 [thread overview]
Message-ID: <6347.1682053997@famine> (raw)
In-Reply-To: <ZEIGCaLWKIY3lDBo@Laptop-X1>
Hangbin Liu <liuhangbin@gmail.com> wrote:
>On Thu, Apr 20, 2023 at 04:21:39PM -0700, Jakub Kicinski wrote:
>> On Thu, 20 Apr 2023 08:59:40 -0700 Jay Vosburgh wrote:
>> > >All errors (new ones prefixed by >>, old ones prefixed by <<):
>> > >
>> > >>> ERROR: modpost: "__umoddi3" [drivers/net/bonding/bonding.ko] undefined!
>> >
>> > I assume this is related to send_peer_notif now being u64 in the
>> > modulus at:
>> >
>> > static bool bond_should_notify_peers(struct bonding *bond)
>> > {
>> > [...]
>> > if (!slave || !bond->send_peer_notif ||
>> > bond->send_peer_notif %
>> > max(1, bond->params.peer_notif_delay) != 0 ||
>> >
>> > but I'm unsure if this is a real coding error, or some issue
>> > with the parisc arch specifically?
>>
>> Coding error, I think.
>> An appropriate helper from linux/math64.h should be used.
>
>It looks define send_peer_notif to u64 is a bit too large, which introduce
>complex conversion for 32bit arch.
>
>For the remainder operation,
>bond->send_peer_notif % max(1, bond->params.peer_notif_delay). u32 % u32 look OK.
>
>But for multiplication operation,
>bond->send_peer_notif = bond->params.num_peer_notif * max(1, bond->params.peer_notif_delay);
>It's u8 * u32. How about let's limit the peer_notif_delay to less than max(u32 / u8),
>then we can just use u32 for send_peer_notif. Is there any realistic meaning
>to set peer_notif_delay to max(u32)? I don't think so.
>
>Jay, what do you think?
I'm fine to limit the peerf_notif_delay range and then use a
smaller type.
num_peer_notif is already limited to 255; I'm going to suggest a
limit to the delay of 300 seconds. That seems like an absurdly long
time for this; I didn't do any kind of science to come up with that
number.
As peer_notif_delay is stored in units of miimon intervals, that
gives a worst case peer_notif_delay value of 300000 if miimon is 1, and
255 * 300000 fits easily in a u32 for send_peer_notif.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
next prev parent reply other threads:[~2023-04-21 5:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-20 8:22 [PATCH net 0/4] bonding: fix send_peer_notif overflow Hangbin Liu
2023-04-20 8:22 ` [PATCH net 1/4] " Hangbin Liu
2023-04-20 14:34 ` kernel test robot
2023-04-20 15:59 ` Jay Vosburgh
2023-04-20 23:21 ` Jakub Kicinski
2023-04-21 3:42 ` Hangbin Liu
2023-04-21 5:13 ` Jay Vosburgh [this message]
2023-04-21 9:55 ` Hangbin Liu
2023-04-26 7:03 ` Hangbin Liu
2023-04-26 21:15 ` Jay Vosburgh
2023-04-20 8:22 ` [PATCH net 2/4] Documentation: bonding: fix the doc of peer_notif_delay Hangbin Liu
2023-04-20 15:52 ` Jay Vosburgh
2023-04-20 8:22 ` [PATCH net 3/4] selftests: forwarding: lib: add netns support for tc rule handle stats get Hangbin Liu
2023-04-20 8:22 ` [PATCH net 4/4] kselftest: bonding: add num_grat_arp test Hangbin Liu
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=6347.1682053997@famine \
--to=jay.vosburgh@canonical.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=liali@redhat.com \
--cc=liuhangbin@gmail.com \
--cc=lkp@intel.com \
--cc=netdev@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=pabeni@redhat.com \
--cc=vincent@bernat.ch \
/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.