From: Dan Carpenter <dan.carpenter@linaro.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: oe-kbuild@lists.linux.dev, Yu Zhao <yuzhao@google.com>,
lkp@intel.com, oe-kbuild-all@lists.linux.dev,
linux-kernel@vger.kernel.org,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: mm/vmscan.c:3504 walk_pte_range() error: uninitialized symbol 'dirty'.
Date: Mon, 26 May 2025 15:32:42 +0300 [thread overview]
Message-ID: <aDRfak8sX1Pf53Pg@stanley.mountain> (raw)
In-Reply-To: <20250523152705.2ecae09e834c66e1327d6748@linux-foundation.org>
On Fri, May 23, 2025 at 03:27:05PM -0700, Andrew Morton wrote:
> On Fri, 23 May 2025 13:47:54 +0300 Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head: 088d13246a4672bc03aec664675138e3f5bff68c
> > commit: a52dcec56c5b96250f15efbd7de3d3ea6ce863d9 mm/mglru: fix PTE-mapped large folios
> > config: sparc-randconfig-r073-20250515 (https://download.01.org/0day-ci/archive/20250515/202505152339.fBOfDPsi-lkp@intel.com/config)
> > compiler: sparc64-linux-gcc (GCC) 8.5.0
> >
> > smatch warnings:
> > mm/vmscan.c:3504 walk_pte_range() error: uninitialized symbol 'dirty'.
> > mm/vmscan.c:3595 walk_pmd_range_locked() error: uninitialized symbol 'dirty'.
> > mm/vmscan.c:4215 lru_gen_look_around() error: uninitialized symbol 'dirty'.
> >
> > ...
> >
> > bd74fdaea14602 Yu Zhao 2022-09-18 3484 for (i = pte_index(start), addr = start; addr != end; i++, addr += PAGE_SIZE) {
> > bd74fdaea14602 Yu Zhao 2022-09-18 3485 unsigned long pfn;
> > bd74fdaea14602 Yu Zhao 2022-09-18 3486 struct folio *folio;
> > c33c794828f212 Ryan Roberts 2023-06-12 3487 pte_t ptent = ptep_get(pte + i);
> > bd74fdaea14602 Yu Zhao 2022-09-18 3488
> > bd74fdaea14602 Yu Zhao 2022-09-18 3489 total++;
> > bd74fdaea14602 Yu Zhao 2022-09-18 3490 walk->mm_stats[MM_LEAF_TOTAL]++;
> > bd74fdaea14602 Yu Zhao 2022-09-18 3491
> > 1d4832becdc2cd Yu Zhao 2024-10-19 3492 pfn = get_pte_pfn(ptent, args->vma, addr, pgdat);
> > bd74fdaea14602 Yu Zhao 2022-09-18 3493 if (pfn == -1)
> > bd74fdaea14602 Yu Zhao 2022-09-18 3494 continue;
> > bd74fdaea14602 Yu Zhao 2022-09-18 3495
> > 798c0330c2ca07 Yu Zhao 2024-12-30 3496 folio = get_pfn_folio(pfn, memcg, pgdat);
> > bd74fdaea14602 Yu Zhao 2022-09-18 3497 if (!folio)
> > bd74fdaea14602 Yu Zhao 2022-09-18 3498 continue;
> > bd74fdaea14602 Yu Zhao 2022-09-18 3499
> > 1d4832becdc2cd Yu Zhao 2024-10-19 3500 if (!ptep_clear_young_notify(args->vma, addr, pte + i))
> > 1d4832becdc2cd Yu Zhao 2024-10-19 3501 continue;
> > bd74fdaea14602 Yu Zhao 2022-09-18 3502
> > a52dcec56c5b96 Yu Zhao 2024-12-30 3503 if (last != folio) {
> > a52dcec56c5b96 Yu Zhao 2024-12-30 @3504 walk_update_folio(walk, last, gen, dirty);
>
> Seems to be notabug because last==NULL on the first loop and in this
> case walk_update_folio() will immediately return without touching
> `dirty'. But gee, I can't blame smatch from getting fooled by this.
That's true, but if walk_update_folio() we not inlined then we would
still consider this a bug. It's undefined behavior in the C standard
to pass uninitialized variables to a function call and also the UBSan
checker will detected it as a read at runtime.
In production systems the compiler is going to set
"bool dirty = false;" at the start of the function because everyone
runs with CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO=y. Should I send a patch
which does that explicitly?
regards,
dan carpenter
next prev parent reply other threads:[~2025-05-26 12:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-23 10:47 Dan Carpenter
2025-05-23 22:27 ` Andrew Morton
2025-05-26 12:32 ` Dan Carpenter [this message]
2025-05-28 0:03 ` Andrew Morton
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=aDRfak8sX1Pf53Pg@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=oe-kbuild@lists.linux.dev \
--cc=yuzhao@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