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

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

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

I previously worked around a false-postive gcc-16 warning in the
get_tier_idx() function, by adding a fake initializer. This happens with
the -fsanitize=bounds sanitizer when the compiler creates a specialized
variant of isolate_folios():

In function 'get_tier_idx',
    inlined from 'isolate_folios.constprop' at mm/vmscan.c:4982:9:
mm/vmscan.c:4934:9: error: 'sp.refaulted' is used uninitialized [-Werror=uninitialized]
 4934 |         read_ctrl_pos(lruvec, type, LRU_TIER_MIN, LRU_TIER_MIN, 2, &sp);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/vmscan.c: In function 'isolate_folios.constprop':
mm/vmscan.c:4946:25: note: 'sp.refaulted' was declared here
 4946 |         struct ctrl_pos sp, pv = {};
      |                         ^~

Adding another "= {}" would solve the problem as well, but to prevent
this from happening again after the next code refactoring, try instead to
prevent this by forbidding interprocedural optimizations on this function.

Link: https://lore.kernel.org/all/20260213123902.3466040-1-arnd@kernel.org/
Fixes: 3de705a43a46 ("mm/vmscan: avoid false-positive -Wuninitialized warning")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 mm/vmscan.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 11387a0fbeeb..626d2fc78cc9 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3274,8 +3274,10 @@ struct ctrl_pos {
 	int gain;
 };
 
-static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier_min,
-			  int tier_max, int gain, struct ctrl_pos *pos)
+/* __noipa works around  gcc-16 warning for uninitizled use of pos->refaulted */
+static __noipa void read_ctrl_pos(struct lruvec *lruvec, int type,
+				  int tier_min, int tier_max, int gain,
+				  struct ctrl_pos *pos)
 {
 	int i;
 	struct lru_gen_folio *lrugen = &lruvec->lrugen;
@@ -4924,7 +4926,7 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
 static int get_tier_idx(struct lruvec *lruvec, int type)
 {
 	int tier;
-	struct ctrl_pos sp, pv = {};
+	struct ctrl_pos sp, pv;
 
 	/*
 	 * To leave a margin for fluctuations, use a larger gain factor (2:3).
@@ -4943,7 +4945,7 @@ static int get_tier_idx(struct lruvec *lruvec, int type)
 
 static int get_type_to_scan(struct lruvec *lruvec, int swappiness)
 {
-	struct ctrl_pos sp, pv = {};
+	struct ctrl_pos sp, pv;
 
 	if (swappiness <= MIN_SWAPPINESS + 1)
 		return LRU_GEN_FILE;
-- 
2.53.0

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

[Andrew Morton]

On Wed, 16 Sep 2026 10:34:46 +0200 Arnd Bergmann <arnd@kernel.org> wrote:

> From: Arnd Bergmann <arnd@arndb.de>
> 
> I previously worked around a false-postive gcc-16 warning in the
> get_tier_idx() function, by adding a fake initializer. This happens with
> the -fsanitize=bounds sanitizer when the compiler creates a specialized
> variant of isolate_folios():
> 
> In function 'get_tier_idx',
>     inlined from 'isolate_folios.constprop' at mm/vmscan.c:4982:9:
> mm/vmscan.c:4934:9: error: 'sp.refaulted' is used uninitialized [-Werror=uninitialized]
>  4934 |         read_ctrl_pos(lruvec, type, LRU_TIER_MIN, LRU_TIER_MIN, 2, &sp);
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> mm/vmscan.c: In function 'isolate_folios.constprop':
> mm/vmscan.c:4946:25: note: 'sp.refaulted' was declared here
>  4946 |         struct ctrl_pos sp, pv = {};
>       |                         ^~
> 
> Adding another "= {}" would solve the problem as well, but to prevent
> this from happening again after the next code refactoring, try instead to
> prevent this by forbidding interprocedural optimizations on this function.
>
> Link: https://lore.kernel.org/all/20260213123902.3466040-1-arnd@kernel.org/
> Fixes: 3de705a43a46 ("mm/vmscan: avoid false-positive -Wuninitialized warning")

I believe we want older kernel to compile properly with gcc-16, so I'm
suggesting this be backported?

Perhaps we should have done that with 3de705a43a46 also.

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

[Andrew Morton]

On Wed, 16 Sep 2026 10:34:46 +0200 Arnd Bergmann <arnd@kernel.org> wrote:

> From: Arnd Bergmann <arnd@arndb.de>
> 
> I previously worked around a false-postive gcc-16 warning in the
> get_tier_idx() function, by adding a fake initializer. This happens with
> the -fsanitize=bounds sanitizer when the compiler creates a specialized
> variant of isolate_folios():
> 
> In function 'get_tier_idx',
>     inlined from 'isolate_folios.constprop' at mm/vmscan.c:4982:9:
> mm/vmscan.c:4934:9: error: 'sp.refaulted' is used uninitialized [-Werror=uninitialized]
>  4934 |         read_ctrl_pos(lruvec, type, LRU_TIER_MIN, LRU_TIER_MIN, 2, &sp);
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> mm/vmscan.c: In function 'isolate_folios.constprop':
> mm/vmscan.c:4946:25: note: 'sp.refaulted' was declared here
>  4946 |         struct ctrl_pos sp, pv = {};
>       |                         ^~
> 
> Adding another "= {}" would solve the problem as well, but to prevent
> this from happening again after the next code refactoring, try instead to
> prevent this by forbidding interprocedural optimizations on this function.
> 
> ...
>
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -3274,8 +3274,10 @@ struct ctrl_pos {
>  	int gain;
>  };
>  
> -static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier_min,
> -			  int tier_max, int gain, struct ctrl_pos *pos)
> +/* __noipa works around  gcc-16 warning for uninitizled use of pos->refaulted */
> +static __noipa void read_ctrl_pos(struct lruvec *lruvec, int type,
> +				  int tier_min, int tier_max, int gain,
> +				  struct ctrl_pos *pos)
>  {
>  	int i;
>  	struct lru_gen_folio *lrugen = &lruvec->lrugen;

Current code has changed here somewhat, but I expect the error is still
there.  I fixed that "uninitizled" while in there.  Altered patch is
below.


--- a/mm/vmscan.c~mm-vmscan-avoid-false-positive-wuninitialized-warning-again
+++ a/mm/vmscan.c
@@ -3195,8 +3195,12 @@ struct ctrl_pos {
 	int gain;
 };
 
-static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier, int gain,
-			  struct ctrl_pos *pos)
+/*
+ * __noipa works around  gcc-16 warning for uninitialized use of
+ * pos->refaulted
+ */
+static __noipa void read_ctrl_pos(struct lruvec *lruvec, int type, int tier,
+			  int gain, struct ctrl_pos *pos)
 {
 	int i;
 	struct lru_gen_folio *lrugen = &lruvec->lrugen;
@@ -4802,7 +4806,7 @@ static int scan_folios(unsigned long nr_
 static int get_tier_idx(struct lruvec *lruvec, int type)
 {
 	int tier;
-	struct ctrl_pos sp, pv = {};
+	struct ctrl_pos sp, pv;
 
 	/*
 	 * To leave a margin for fluctuations, use a larger gain factor (2:3).
@@ -4821,7 +4825,7 @@ static int get_tier_idx(struct lruvec *l
 
 static int get_type_to_scan(struct lruvec *lruvec, int swappiness)
 {
-	struct ctrl_pos sp, pv = {};
+	struct ctrl_pos sp, pv;
 
 	if (swappiness <= MIN_SWAPPINESS + 1)
 		return LRU_GEN_FILE;
_

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

[Andrew Morton]

On Wed, 16 Sep 2026 16:28:16 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> >
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -3274,8 +3274,10 @@ struct ctrl_pos {
> >  	int gain;
> >  };
> >  
> > -static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier_min,
> > -			  int tier_max, int gain, struct ctrl_pos *pos)
> > +/* __noipa works around  gcc-16 warning for uninitizled use of pos->refaulted */
> > +static __noipa void read_ctrl_pos(struct lruvec *lruvec, int type,
> > +				  int tier_min, int tier_max, int gain,
> > +				  struct ctrl_pos *pos)
> >  {
> >  	int i;
> >  	struct lru_gen_folio *lrugen = &lruvec->lrugen;
> 
> Current code has changed here somewhat, but I expect the error is still
> there.  I fixed that "uninitizled" while in there.  Altered patch is
> below.


Then the build blew up in unexpected ways.  gcc-15.2.0.

The failure looks like a legit min() signedness thing which has been
there quite a while.  I'm thinking that __noipa surfaced this for some
reason?

  CC      mm/vmscan.o
In file included from <command-line>:
mm/vmscan.c: In function 'read_ctrl_pos':
././include/linux/compiler_types.h:702:45: error: call to '__compiletime_assert_798' declared with attribute error: min(tier, 4U - 1) signedness error
  702 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |                                             ^

I'll queue a fix to switch this to min_t (yuck) for now.  It would of
course be better to use more appropriate types in this code.  Unless
tiers can be negative!


From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm/vmscan.c: fix min() signedness mismatch
Date: Wed Sep 16 04:21:22 PM PDT 2026

A __noipa conversion from Arnd [1] somehow revealed a longstanding min()
error in read_ctrl_pos().  Plug it with min_t().

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Barry Song <baohua@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kairui Song <kasong@tencent.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Wei Xu <weixugc@google.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/vmscan.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/vmscan.c~mm-vmscanc-fix-min-signedness-mismatch
+++ a/mm/vmscan.c
@@ -3205,7 +3205,7 @@ static void read_ctrl_pos(struct lruvec
 	pos->gain = gain;
 	pos->refaulted = pos->total = 0;
 
-	for (i = tier % MAX_NR_TIERS; i <= min(tier, MAX_NR_TIERS - 1); i++) {
+	for (i = tier % MAX_NR_TIERS; i <= min_t(unsigned int, tier, MAX_NR_TIERS - 1); i++) {
 		pos->refaulted += lrugen->avg_refaulted[type][i] +
 				  atomic_long_read(&lrugen->refaulted[hist][type][i]);
 		pos->total += lrugen->avg_total[type][i] +
_

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

[Baoquan He]

On 09/16/26 at 04:30pm, Andrew Morton wrote:
> On Wed, 16 Sep 2026 16:28:16 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > >
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -3274,8 +3274,10 @@ struct ctrl_pos {
> > >  	int gain;
> > >  };
> > >  
> > > -static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier_min,
> > > -			  int tier_max, int gain, struct ctrl_pos *pos)
> > > +/* __noipa works around  gcc-16 warning for uninitizled use of pos->refaulted */
> > > +static __noipa void read_ctrl_pos(struct lruvec *lruvec, int type,
> > > +				  int tier_min, int tier_max, int gain,
> > > +				  struct ctrl_pos *pos)
> > >  {
> > >  	int i;
> > >  	struct lru_gen_folio *lrugen = &lruvec->lrugen;
> > 
> > Current code has changed here somewhat, but I expect the error is still
> > there.  I fixed that "uninitizled" while in there.  Altered patch is
> > below.
> 
> 
> Then the build blew up in unexpected ways.  gcc-15.2.0.
> 
> The failure looks like a legit min() signedness thing which has been
> there quite a while.  I'm thinking that __noipa surfaced this for some
> reason?
> 
>   CC      mm/vmscan.o
> In file included from <command-line>:
> mm/vmscan.c: In function 'read_ctrl_pos':
> ././include/linux/compiler_types.h:702:45: error: call to '__compiletime_assert_798' declared with attribute error: min(tier, 4U - 1) signedness error
>   702 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>       |                                             ^
> 
> I'll queue a fix to switch this to min_t (yuck) for now.  It would of
> course be better to use more appropriate types in this code.  Unless
> tiers can be negative!

I drafted one to change 'tier' as 'unsigned int'. While in mm-new this
issue has gone away because Kairui's patch change 'tier' to 'tier_min'
and 'tier_max' and remove min().

commit b447513eee2f ("mm/mglru: use explicit tier range in read_ctrl_pos()")

I personally think your one line change is better for backporting to
stable tree.

From: Baoquan He <hebaoquan@kylinos.cn>
Subject: [PATCH] mm/vmscan: fix min() signedness mismatch in read_ctrl_pos()

read_ctrl_pos() declares 'tier' as int, but MAX_NR_TIERS is 4U, so
min(tier, MAX_NR_TIERS - 1) compares int with unsigned int and min()
reports a signedness error:

  error: min(tier, 4U - 1) signedness error

'tier' is never negative, it is a tier index or MAX_NR_TIERS to mean
all tiers. Make it unsigned int, then min() compares two unsigned
values and no min_t() needed.

Signed-off-by: Baoquan He <hebaoquan@kylinos.cn>
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index f11491ee9ed5..1844d92a6732 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3195,10 +3195,10 @@ struct ctrl_pos {
 	int gain;
 };
 
-static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier, int gain,
-			  struct ctrl_pos *pos)
+static void read_ctrl_pos(struct lruvec *lruvec, int type, unsigned int tier,
+			  int gain, struct ctrl_pos *pos)
 {
-	int i;
+	unsigned int i;
 	struct lru_gen_folio *lrugen = &lruvec->lrugen;
 	int hist = lru_hist_from_seq(lrugen->min_seq[type]);
 
@@ -4801,7 +4801,7 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
 
 static int get_tier_idx(struct lruvec *lruvec, int type)
 {
-	int tier;
+	unsigned int tier;
 	struct ctrl_pos sp, pv = {};
 
 	/*

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

[Arnd Bergmann]

On Thu, Sep 17, 2026, at 01:30, Andrew Morton wrote:
> On Wed, 16 Sep 2026 16:28:16 -0700 Andrew Morton  <akpm@linux-foundation.org> wrote:
>> >
>> > --- a/mm/vmscan.c
>> > +++ b/mm/vmscan.c
>> > @@ -3274,8 +3274,10 @@ struct ctrl_pos {
>> >  	int gain;
>> >  };
>> >  
>> > -static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier_min,
>> > -			  int tier_max, int gain, struct ctrl_pos *pos)
>> > +/* __noipa works around  gcc-16 warning for uninitizled use of pos->refaulted */
>> > +static __noipa void read_ctrl_pos(struct lruvec *lruvec, int type,
>> > +				  int tier_min, int tier_max, int gain,
>> > +				  struct ctrl_pos *pos)
>> >  {
>> >  	int i;
>> >  	struct lru_gen_folio *lrugen = &lruvec->lrugen;
>> 
>> Current code has changed here somewhat, but I expect the error is still
>> there.  I fixed that "uninitizled" while in there.  Altered patch is
>> below.
>
>
> Then the build blew up in unexpected ways.  gcc-15.2.0.
>
> The failure looks like a legit min() signedness thing which has been
> there quite a while.  I'm thinking that __noipa surfaced this for some
> reason?

Right, I now saw the same thing here on the current linux-next.

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().

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?
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.

     Arnd

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

[Andrew Morton]

On Thu, 17 Sep 2026 07:50:43 +0200 "Arnd Bergmann" <arnd@arndb.de> wrote:

> On Thu, Sep 17, 2026, at 01:30, Andrew Morton wrote:
> > On Wed, 16 Sep 2026 16:28:16 -0700 Andrew Morton  <akpm@linux-foundation.org> wrote:
> >> >
> >> > --- a/mm/vmscan.c
> >> > +++ b/mm/vmscan.c
> >> > @@ -3274,8 +3274,10 @@ struct ctrl_pos {
> >> >  	int gain;
> >> >  };
> >> >  
> >> > -static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier_min,
> >> > -			  int tier_max, int gain, struct ctrl_pos *pos)
> >> > +/* __noipa works around  gcc-16 warning for uninitizled use of pos->refaulted */
> >> > +static __noipa void read_ctrl_pos(struct lruvec *lruvec, int type,
> >> > +				  int tier_min, int tier_max, int gain,
> >> > +				  struct ctrl_pos *pos)
> >> >  {
> >> >  	int i;
> >> >  	struct lru_gen_folio *lrugen = &lruvec->lrugen;
> >> 
> >> Current code has changed here somewhat, but I expect the error is still
> >> there.  I fixed that "uninitizled" while in there.  Altered patch is
> >> below.
> >
> >
> > Then the build blew up in unexpected ways.  gcc-15.2.0.
> >
> > The failure looks like a legit min() signedness thing which has been
> > there quite a while.  I'm thinking that __noipa surfaced this for some
> > reason?
> 
> Right, I now saw the same thing here on the current linux-next.
> 
> 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?

> 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.

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?

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

[Arnd Bergmann]

On Thu, Sep 17, 2026, at 08:03, Andrew Morton wrote:
> On Thu, 17 Sep 2026 07:50:43 +0200 "Arnd Bergmann" <arnd@arndb.de> 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@kernel.org/

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

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

[Arnd Bergmann]

On Thu, Sep 17, 2026, at 12:15, Arnd Bergmann wrote:
> On Thu, Sep 17, 2026, at 08:03, Andrew Morton wrote:

> 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.

I now reported this as a gcc bug at

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127454

Let's see what they think.

    Arnd

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

[David Laight]

On Wed, 16 Sep 2026 23:03:30 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu, 17 Sep 2026 07:50:43 +0200 "Arnd Bergmann" <arnd@arndb.de> wrote:
> 
> > On Thu, Sep 17, 2026, at 01:30, Andrew Morton wrote:  
> > > On Wed, 16 Sep 2026 16:28:16 -0700 Andrew Morton  <akpm@linux-foundation.org> wrote:  
> > >> >
> > >> > --- a/mm/vmscan.c
> > >> > +++ b/mm/vmscan.c
> > >> > @@ -3274,8 +3274,10 @@ struct ctrl_pos {
> > >> >  	int gain;
> > >> >  };
> > >> >  
> > >> > -static void read_ctrl_pos(struct lruvec *lruvec, int type, int tier_min,
> > >> > -			  int tier_max, int gain, struct ctrl_pos *pos)
> > >> > +/* __noipa works around  gcc-16 warning for uninitizled use of pos->refaulted */
> > >> > +static __noipa void read_ctrl_pos(struct lruvec *lruvec, int type,
> > >> > +				  int tier_min, int tier_max, int gain,
> > >> > +				  struct ctrl_pos *pos)
> > >> >  {
> > >> >  	int i;
> > >> >  	struct lru_gen_folio *lrugen = &lruvec->lrugen;  
> > >> 
> > >> Current code has changed here somewhat, but I expect the error is still
> > >> there.  I fixed that "uninitizled" while in there.  Altered patch is
> > >> below.  
> > >
> > >
> > > Then the build blew up in unexpected ways.  gcc-15.2.0.
> > >
> > > The failure looks like a legit min() signedness thing which has been
> > > there quite a while.  I'm thinking that __noipa surfaced this for some
> > > reason?  
> > 
> > Right, I now saw the same thing here on the current linux-next.
> > 
> > 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?
> 
> > 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.
> 
> 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've don't remember seeing that last patch, but I have looked at
that function before and it is entirely horrible.

It really does need to inlined to avoid really horrid code generation.

But, in reality, it all ought to be reworked to avoid having a function
that is called to either process one entry or all four.

David