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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).