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

[David Laight]

On Wed, 16 Sep 2026 23:03:30 -0700
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 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:  
> > > On Wed, 16 Sep 2026 16:28:16 -0700 Andrew Morton  <akpm@xxxxxxxxxxxxxxxxxxxx> 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