Re: [bug report] mm/mempolicy: Weighted Interleave Auto-tuning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux