From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB15317B418 for ; Sun, 10 May 2026 15:02:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778425336; cv=none; b=fn41whNNT+EtJwj7kDtH/EsAMNtM+wsBDGQCF0dr3toF2pMfugJSgeRlz+AGkL/d/2C8rYmFuLv7ixbuYCa1pFJcZ+V/xp3nrECQ8S4CEMdeGQwbWotlk7rarp72XEKG+Dku9okb7i52AK+JLdwavVL60WQiZnsytOqLQWaZcVI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778425336; c=relaxed/simple; bh=A2bMYsmmzO3bfo6coUBN7L0qaZ6N0cXyd1Ft76Xb/TQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q/FrZyR4cYo5IIXFB+dvOOPL3wGyZzh9wpGhrd3AkLkS43CihCEM6HfoUx1sn9J3VtFrKtlBN8J1eT0jw4AE833iPZEb9SHms7iDzgVM/zQF/L6k/v/tN4M8WB4FfMSiiHPmxTmKaYIZ/YrMcoDOtBVMCtCuR/wbnuLnbwnt4n0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Rs8bwDqY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Rs8bwDqY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44E6FC2BCB8; Sun, 10 May 2026 15:02:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778425336; bh=A2bMYsmmzO3bfo6coUBN7L0qaZ6N0cXyd1Ft76Xb/TQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Rs8bwDqY6X5ZYJskonmMR5aleB1JCBI1znAy5mrJm1RGHUX4bJPSXFySNJgoYMJGC d/nIN00vBKCrEOVOqUjlQok4zits4RVjX+hhmh/V/RXTeR8U/n/53stfOfgkytn3zA VBfzkJb1WbZ48qmkcfrX3h+pbkgseYdmXliT8rvmSvZ1iA66XcVSk5Ow/DpkqYwFCn BbFQ2HsHh9k+nHm/jiQ5qmezIrPdcIJ/1aQ2XsK2A73T8O0/R4uE7uNu6O3g0XAjOp UEZ4Wtaf2WlWPDVTS1jQ9/H292h+ot383FYK8Emuqgqu7hjjVjQ6pCtOIoQY483UwI ElsVuUAoO1RCQ== Date: Sun, 10 May 2026 18:02:08 +0300 From: Mike Rapoport To: Waiman Long Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Frederic Weisbecker , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/isolation: Don't free memblock allocated cpumasks Message-ID: References: <20260505051821.1107133-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260505051821.1107133-1-longman@redhat.com> Hi Waiman, On Tue, May 05, 2026 at 01:18:21AM -0400, Waiman Long wrote: > 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] > [ 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] > > 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] > [ 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] > > 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 > --- > 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()); Before 59bd1d914bb5 it was a silent leak. housekeeping_init() is called after memblock moves all the memory to buddy, so this would only update memblock.reserved. The comment a few lines above says that we reallocate to be able to kfree() later. Is it possible to delay reallocation until an initcall? > } > } > > -- > 2.53.0 > -- Sincerely yours, Mike.