linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Arnd Bergmann <arnd@arndb.de>, Kairui Song <kasong@tencent.com>,
	Qi Zheng <qi.zheng@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Barry Song <baohua@kernel.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
	David Hildenbrand <david@kernel.org>,
	Michal Hocko <mhocko@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Koichiro Den <koichiro.den@canonical.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [v2] mm/vmscan: avoid false-positive -Wuninitialized warning
Date: Tue, 14 Apr 2026 22:05:32 +0100	[thread overview]
Message-ID: <20260414220532.3c89dfa3@pumpkin> (raw)
In-Reply-To: <20260414065206.3236176-1-arnd@kernel.org>

On Tue, 14 Apr 2026 08:51:58 +0200
Arnd Bergmann <arnd@kernel.org> wrote:

> From: Arnd Bergmann <arnd@arndb.de>
> 
> When the -fsanitize=bounds sanitizer is enabled, gcc-16 sometimes runs
> into a corner case in the read_ctrl_pos() pos function, where it sees
> possible undefined behavior from the 'tier' index overflowing, presumably
> in the case that this was called with a negative tier:
> 
> In function 'get_tier_idx',
>     inlined from 'isolate_folios' at mm/vmscan.c:4671:14:
> mm/vmscan.c: In function 'isolate_folios':
> mm/vmscan.c:4645:29: error: 'pv.refaulted' is used uninitialized [-Werror=uninitialized]
> 
> Part of the problem seems to be that read_ctrl_pos() has unusual calling
> conventions since commit 37a260870f2c ("mm/mglru: rework type selection")
> where passing MAX_NR_TIERS makes it accumulate all tiers but passing a
> smaller positive number makes it read a single tier instead.

We've had issues with that code before, might have been related to the min().
Unless that function is inlined (and the compiler generates a sane loop)
the generated code will be completely horrid.

If this code is executed in any kind of 'hot path' it should really be
done differently.
It isn't as though there are many callers; and one want to process
all the tiers - but not in the same way.

The code isn't even that readable.

	David

> 
> Shut up the warning by adding a fake initialization to the two instances
> of this variable that can run into that corner case.
> 
> Link: https://lore.kernel.org/all/CAJHvVcjtFW86o5FoQC8MMEXCHAC0FviggaQsd5EmiCHP+1fBpg@mail.gmail.com/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: replace the earlier more invasive cleanup with a trivial
>     workaround
> ---
>  mm/vmscan.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index d3312c51f3f2..f829435d2807 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4760,7 +4760,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).
> @@ -4779,7 +4779,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;



      parent reply	other threads:[~2026-04-14 21:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14  6:51 Arnd Bergmann
2026-04-14 19:15 ` Axel Rasmussen
2026-04-14 20:59 ` Barry Song
2026-04-14 21:05 ` David Laight [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260414220532.3c89dfa3@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=dave@stgolabs.net \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kasong@tencent.com \
    --cc=koichiro.den@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=qi.zheng@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox