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

[Axel Rasmussen <axelrasmussen@google.com>]

On Tue, Feb 17, 2026 at 12:55 PM Yuanchu Xie <yuanchu@google.com> wrote:
>
> Hi Andrew and Arnd,
>
> On Fri, Feb 13, 2026 at 11:23 AM Andrew Morton
> <akpm@linux-foundation.org> wrote:
> >
> > On Fri, 13 Feb 2026 18:07:04 +0100 "Arnd Bergmann" <arnd@arndb.de> wrote:
> >
> > > On Fri, Feb 13, 2026, at 17:58, Andrew Morton wrote:
> > > > On Fri, 13 Feb 2026 13:38:56 +0100 Arnd Bergmann <arnd@kernel.org> wrote:
> > > >
> > > >> From: Arnd Bergmann <arnd@arndb.de>
> > > >>
> > > >> When the -fsanitize=bounds sanitizer is enabled,
> > > >
> > > > Is this an option in current kernels?
> > >
> > > Yes, this is CONFIG_UBSAN_ARRAY_BOUNDS. The actual warning
> > > only shows up in some configurations with that, so either there
> > > is some other dependency, or an element of chance based on gcc
> > > optimizations.
> >
> > OK, I'll put a cc:stable on this, as people will want to compile older
> > kernels with gcc-16.
> >
> > Aiming for upstreaming into 7.1-rc1 unless it's more urgent than I
> > think.
> >
> > > > Seems a large change just to squish a compiler warning.  People might
> > > > prefer a simple
> > > >
> > > > -   struct ctrl_pos sp, pv;
> > > > +   struct ctrl_pos sp, pv = {};
> > >
> > > Right, that would clearly also shut up the warning.
> > >
> > > To me this seems less intuitive without an extra comment,
> > > since read_ctrl_pos() is meant to initialize the entire
> > > struct, but please pick whichever you find most readable
> > > here.
> >
> > Let's see what the MGLRU maintainers have to say.
>
> I went over the various cases of read_ctrl_pos and couldn't find
> anything wrong (let me know if I'm mistaken), so this seems like a
> mild compiler bug we're trying to work around. Given it's one single
> version of gcc, I'm a fan of the simple `struct ctrl_pos sp, pv = {};`
> with a comment.

Agreed, that simpler change with a comment seems better to me.

I don't necessarily hate the refactor to split up the single /
aggregate cases, but if we were going to do that I'd probably have
aggregate_ctrl_pos call read_ctrl_pos to avoid duplicating the code,
and I'd want to consider marking read_ctrl_pos inline.

But, it does seem like a large delta just to work around a false
positive warning. The simpler change would be easier to backport to
stable too for example. So on balance I'd prefer that.

>
> Thanks,
> Yuanchu