The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Mike Rapoport <rppt@kernel.org>
Cc: linux-kernel@vger.kernel.org, Waiman Long <longman@redhat.com>
Subject: [PATCH] sched/isolation: Don't free memblock allocated cpumasks
Date: Tue,  5 May 2026 01:18:21 -0400	[thread overview]
Message-ID: <20260505051821.1107133-1-longman@redhat.com> (raw)

When testing a v7.1 kernel with commit 59bd1d914bb5 ("memblock: warn when
freeing reserved memory before memory map is initialized"), the following
warning was hit when there was a "nohz_full" kernel boot parameter.

[    0.080911] Cannot free reserved memory because of deferred initialization of the memory map
[    0.080911] WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0
  :
[    0.080945] Call Trace:
[    0.080947]  <TASK>
[    0.080949]  memblock_phys_free+0xcb/0x100
[    0.080953]  housekeeping_init+0x14c/0x170
[    0.080957]  start_kernel+0x207/0x450
[    0.080961]  x86_64_start_reservations+0x24/0x30
[    0.080965]  x86_64_start_kernel+0xda/0xe0
[    0.080967]  common_startup_64+0x13e/0x141
[    0.080972]  </TASK>

The commit states that freeing of reserved memory before the memory
map is fully initialized in deferred_init_memmap() would cause access
to uninitialized struct pages and may crash when accessing spurious
list pointers. However, if the memblock_free() call is deferred to
the start of initcall processing in the bootup process, for instance,
the following KASAN warning can appear.

[    8.514775] BUG: KASAN: use-after-free in memblock_isolate_range+0x4ac/0x650
[    8.514775] Read of size 8 at addr ffff88a07fe6a000 by task swapper/0/1
  :
[    8.514775] Call Trace:
[    8.514775]  <TASK>
[    8.514775]  kasan_report+0xb2/0x1b0
[    8.514775]  memblock_isolate_range+0x4ac/0x650
[    8.514775]  memblock_phys_free+0xc4/0x190
[    8.514775]  housekeeping_late_init+0x257/0x280
[    8.514775]  do_one_initcall+0xaa/0x470
[    8.514775]  do_initcalls+0x1b4/0x1f0
[    8.514775]  kernel_init_freeable+0x4b5/0x550
[    8.514775]  kernel_init+0x1c/0x150
[    8.514775]  ret_from_fork+0x5dc/0x8e0
[    8.514775]  ret_from_fork_asm+0x1a/0x30
[    8.514775]  </TASK>

It is likely that memblock_discard() may discard memblock data needed
for memblock_free(). One workaround for now to avoid these warning/bug
messages is to keep the memblock allocated cpumasks even if they are
no longer needed until the memblock subsystem is properly updated to
handle memblock_free().

On most systems, memory occuipied by a cpumask is pretty small. So not
much memory will be wasted if the memblock cpumasks are not freed.

Signed-off-by: Waiman Long <longman@redhat.com>
---
 kernel/sched/isolation.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index ef152d401fe2..ad9b1a1104e3 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -189,7 +189,13 @@ void __init housekeeping_init(void)
 		WARN_ON_ONCE(cpumask_empty(omask));
 		cpumask_copy(nmask, omask);
 		RCU_INIT_POINTER(housekeeping.cpumasks[type], nmask);
-		memblock_free(omask, cpumask_size());
+
+		/*
+		 * TODO: Don't free memblock allocated cpumasks until the
+		 * memblock subystem is able to handle the memblock_free()
+		 * properly.
+		 */
+		// memblock_free(omask, cpumask_size());
 	}
 }
 
-- 
2.53.0


             reply	other threads:[~2026-05-05  5:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-05  5:18 Waiman Long [this message]
2026-05-06 13:25 ` [PATCH] sched/isolation: Don't free memblock allocated cpumasks Valentin Schneider
2026-05-06 14:02   ` Waiman Long
2026-05-08 14:19 ` Breno Leitao
2026-05-10 14:45   ` Mike Rapoport
2026-05-10 15:02 ` Mike Rapoport
2026-05-11  4:55   ` Waiman Long
2026-05-11  8:34     ` Mike Rapoport
2026-05-11 21:36       ` Waiman Long

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=20260505051821.1107133-1-longman@redhat.com \
    --to=longman@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=frederic@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.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