linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Gregory Price <gourry@gourry.net>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Joshua Hahn <joshua.hahnjy@gmail.com>, linux-mm@kvack.org
Subject: Re: [bug report] mm/mempolicy: Weighted Interleave Auto-tuning
Date: Tue, 18 Feb 2025 11:41:31 -0500	[thread overview]
Message-ID: <Z7S4O6ThYDSGh49W@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <547331c1-5332-432b-83f0-911b96a79d72@stanley.mountain>

On Mon, Feb 17, 2025 at 10:35:20AM +0300, Dan Carpenter wrote:
> Hello Joshua Hahn,
> 
> Commit aab5f6eb05fd ("mm/mempolicy: Weighted Interleave Auto-tuning")
> from Feb 7, 2025 (linux-next), leads to the following Smatch static
> checker warning:
> 
> 	mm/mempolicy.c:220 mempolicy_set_node_perf()
> 	warn: assigned value is less than '1844674407370955161'
> 
> mm/mempolicy.c
>     209 int mempolicy_set_node_perf(unsigned int node, struct access_coordinate *coords)
>     210 {
>     211         uint64_t *old_bw, *new_bw;
>     212         uint64_t bw_val;
>     213         u8 *old_iw, *new_iw;
>     214 
>     215         /*
>     216          * Bandwidths above this limit cause rounding errors when reducing
>     217          * weights. This value is ~16 exabytes, which is unreasonable anyways.
> 
> I see this comment about exabytes
> 
>     218          */
>     219         bw_val = min(coords->read_bandwidth, coords->write_bandwidth);
>                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> but these values are u32s
> 
> --> 220         if (bw_val > (U64_MAX / 10))
>                               ^^^^^^^^^^^^
> There is no way they're going to be more than U64_MAX / 10.
> 

hm, not sure why we thought these were u64.

Anyway, agreed, pointless check since the condition can't be met.
It's possible we wanted to apply this to sum_bw instead.

Will take a look.

~Gregory


  reply	other threads:[~2025-02-18 16:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17  7:35 Dan Carpenter
2025-02-18 16:41 ` Gregory Price [this message]
2025-02-18 18:31 ` Joshua Hahn

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=Z7S4O6ThYDSGh49W@gourry-fedora-PF4VCD3F \
    --to=gourry@gourry.net \
    --cc=dan.carpenter@linaro.org \
    --cc=joshua.hahnjy@gmail.com \
    --cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox