Re: [PATCH] mm/vmscan: avoid false-positive -Wuninitialized warning, again

From: Arnd Bergmann

Date: Thu Sep 17 2026 - 06:30:11 EST


On Thu, Sep 17, 2026, at 08:03, Andrew Morton wrote:
> On Thu, 17 Sep 2026 07:50:43 +0200 "Arnd Bergmann" <arnd@xxxxxxxx> wrote:
>> On Thu, Sep 17, 2026, at 01:30, Andrew Morton wrote:
>> What I found now is that the __noipa is only needed on top of
>> "mm/mglru: use explicit tier range in read_ctrl_pos()", which was
>> in next-20260915 but disappeared in next-20260916. This patch
>> also removed the min().
>
> So we don't need cc:stable?

Correct

>> I think the reason why __noipa causes the warning about min() is
>> that it prevents the constant propagation into read_ctrl_pos() and
>> in turn the hack that suppresses warning about mixed types in
>> minmax.h when both sides are constant.
>>
>> Is the mglru series currently expected to make it into 7.4?
>
> Yes, "mm/mglru: use explicit tier range in read_ctrl_pos()" is in
> mm-unstable at present.
>
>> If not, I would withdraw my __noipa and hope that the next
>> round of changes to read_ctrl_pos() does not run into this
>> problem again.
>
> OK, I'll drop "mm/vmscan.c: fix min() signedness mismatch" and shall
> rely on "mm/mglru: use explicit tier range in read_ctrl_pos()" to fix
> the min() thing.

Ok

> And I'll stage "mm/vmscan: avoid false-positive -Wuninitialized
> warning, again". ahead of "mm/mglru: use explicit tier range in
> read_ctrl_pos()" to fix the build glitch wihout a bisection hole.
>
> Does that sound sane?

I think the "mm/mglru: use explicit tier range in read_ctrl_pos()"
patch should come first because the -Wuninitialized warning only
happens in some randconfig builds with that, while the "mm/vmscan:
avoid false-positive -Wuninitialized warning, again" patch on
its own would always warn about the min().

Somehow I fear this is not the last we've heard of this bug, and
I wonder reworking read_ctrl_pos() would be better. I tried that
in my original suggestion before adding the initialization, but
that had other problems:
https://lore.kernel.org/all/20260213123902.3466040-1-arnd@xxxxxxxxxx/

I have checked the latest gcc-17 snapshot and see that this still
produces the warning.

I also managed to create a reduced test case, see
https://godbolt.org/z/xofecssz4 but this still doesn't make sense
to me. I do see that gcc creates a both an out-of-line version
of read_ctrl_pos() and also inlines it. Marking it either
__always_inline or noinline avoids the warning.

Arnd