From: Rand Deeb <rand.sec96@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Chris Snook <chris.snook@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Christian Marangi <ansuelsmth@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
deeb.rand@confident.ru, lvc-project@linuxtesting.org,
voskresenski.stanislav@confident.ru
Subject: Re: [PATCH] drivers:atlx: Prevent integer overflow in statistics aggregation
Date: Tue, 8 Oct 2024 19:59:09 +0300 [thread overview]
Message-ID: <CAN8dotnMoh9VKd50MQx=FJ9ALhsHp7DMsMNq--EdrbWb8=Vv3w@mail.gmail.com> (raw)
In-Reply-To: <20241007172715.649822ba@kernel.org>
On Tue, Oct 8, 2024 at 3:27 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 7 Oct 2024 12:29:36 +0300 Rand Deeb wrote:
> > The `atl1_inc_smb` function aggregates various RX and TX error counters
> > from the `stats_msg_block` structure. Currently, the arithmetic operations
> > are performed using `u32` types, which can lead to integer overflow when
> > summing large values. This overflow occurs before the result is cast to
> > a `u64`, potentially resulting in inaccurate network statistics.
> >
> > To mitigate this risk, each operand in the summation is explicitly cast to
> > `u64` before performing the addition. This ensures that the arithmetic is
> > executed in 64-bit space, preventing overflow and maintaining accurate
> > statistics regardless of the system architecture.
>
> Thanks for the nice commit message, but honestly I don't think
> the error counters can overflow u32 on an ancient NIC like this.
Hi Jakub,
Thanks for your feedback, much appreciated!
Honestly, when I was investigating this, I had the same thoughts regarding
the possibility of the counters overflowing. However, I want to clarify
that the variables where we store the results of these summations (like
new_rx_errors, new_tx_errors, etc.) are already u64 types. Given that, it
seems logical to cast the operands to u64 before the addition to ensure
consistency and avoid any potential issues during the summation.
Additionally, all counters in the atl1_sft_stats structure are also
defined as u64, which reinforces the rationale for casting the operands in
the summation as well.
Thanks again for your input!
Best regards,
Rand Deeb
next prev parent reply other threads:[~2024-10-08 16:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 9:29 [PATCH] drivers:atlx: Prevent integer overflow in statistics aggregation Rand Deeb
2024-10-08 0:27 ` Jakub Kicinski
2024-10-08 16:59 ` Rand Deeb [this message]
2024-10-08 17:13 ` Keller, Jacob E
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='CAN8dotnMoh9VKd50MQx=FJ9ALhsHp7DMsMNq--EdrbWb8=Vv3w@mail.gmail.com' \
--to=rand.sec96@gmail.com \
--cc=ansuelsmth@gmail.com \
--cc=chris.snook@gmail.com \
--cc=davem@davemloft.net \
--cc=deeb.rand@confident.ru \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=voskresenski.stanislav@confident.ru \
/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).