All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
	netdev@vger.kernel.org, Lukasz Czapnik <lukasz.czapnik@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next] ice: prevent integer overflow
Date: Fri, 20 Mar 2026 19:51:03 +0000	[thread overview]
Message-ID: <20260320195103.GJ74886@horms.kernel.org> (raw)
In-Reply-To: <20260320050544.422640-1-aleksandr.loktionov@intel.com>

On Fri, Mar 20, 2026 at 06:05:44AM +0100, Aleksandr Loktionov wrote:
> From: Lukasz Czapnik <lukasz.czapnik@intel.com>
> 
> In ice_sched_bw_to_rl_profile(), the loop over 64 bits computes the
> scheduler timestamp rate as:
> 
>   ts_rate = div64_long((s64)hw->psm_clk_freq,
>                        pow_result * ICE_RL_PROF_TS_MULTIPLIER);
> 
> where pow_result = BIT_ULL(i). For large values of i, the product
> pow_result * ICE_RL_PROF_TS_MULTIPLIER overflows u64 before being used
> as the divisor, producing incorrect ts_rate values and potentially
> undefined behaviour.
> 
> Fix this by pre-computing ts_freq = hw->psm_clk_freq /
> ICE_RL_PROF_TS_MULTIPLIER once before the loop and then dividing only
> by pow_result inside the loop. The division order avoids the overflow
> while preserving the same mathematical result. Declare ts_freq as s64
> to match the type domain of the surrounding arithmetic and avoid a
> redundant cast at the use site.
> 
> While at it, scope the loop variable i to the for statement itself.
> 
> Fixes: 1ddef455f4a8 ("ice: Add NDO callback to set the maximum per-queue bitrate")
> Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Reviewed-by: Simon Horman <horms@kernel.org>


WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
	netdev@vger.kernel.org, Lukasz Czapnik <lukasz.czapnik@intel.com>
Subject: Re: [PATCH iwl-next] ice: prevent integer overflow
Date: Fri, 20 Mar 2026 19:51:03 +0000	[thread overview]
Message-ID: <20260320195103.GJ74886@horms.kernel.org> (raw)
In-Reply-To: <20260320050544.422640-1-aleksandr.loktionov@intel.com>

On Fri, Mar 20, 2026 at 06:05:44AM +0100, Aleksandr Loktionov wrote:
> From: Lukasz Czapnik <lukasz.czapnik@intel.com>
> 
> In ice_sched_bw_to_rl_profile(), the loop over 64 bits computes the
> scheduler timestamp rate as:
> 
>   ts_rate = div64_long((s64)hw->psm_clk_freq,
>                        pow_result * ICE_RL_PROF_TS_MULTIPLIER);
> 
> where pow_result = BIT_ULL(i). For large values of i, the product
> pow_result * ICE_RL_PROF_TS_MULTIPLIER overflows u64 before being used
> as the divisor, producing incorrect ts_rate values and potentially
> undefined behaviour.
> 
> Fix this by pre-computing ts_freq = hw->psm_clk_freq /
> ICE_RL_PROF_TS_MULTIPLIER once before the loop and then dividing only
> by pow_result inside the loop. The division order avoids the overflow
> while preserving the same mathematical result. Declare ts_freq as s64
> to match the type domain of the surrounding arithmetic and avoid a
> redundant cast at the use site.
> 
> While at it, scope the loop variable i to the for statement itself.
> 
> Fixes: 1ddef455f4a8 ("ice: Add NDO callback to set the maximum per-queue bitrate")
> Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Reviewed-by: Simon Horman <horms@kernel.org>


  reply	other threads:[~2026-03-20 19:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-20  5:05 [Intel-wired-lan] [PATCH iwl-next] ice: prevent integer overflow Aleksandr Loktionov
2026-03-20  5:05 ` Aleksandr Loktionov
2026-03-20 19:51 ` Simon Horman [this message]
2026-03-20 19:51   ` Simon Horman
2026-05-08  6:54 ` [Intel-wired-lan] " Rinitha, SX
2026-05-08  6:54   ` Rinitha, SX

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=20260320195103.GJ74886@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=aleksandr.loktionov@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=lukasz.czapnik@intel.com \
    --cc=netdev@vger.kernel.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.