netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).