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 86EE7360EEA for ; Tue, 12 May 2026 13:40:11 +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=1778593211; cv=none; b=GJNyLNpgOtIT8tcB+FhMJ+3OM4GGfF1/LH4aTL1Wl2phms78Ak5YX9mei5K+W3YL7yqGyHYcG3a9jQSA8TFPCBBaIyCsLV4yuTaZo1hEd8zuCsx9FCfJUvcMOW4qt7vZHEZEiN6DEREeM7P6tw1ovIUeogiSeicCwvPt+J2B4Ug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778593211; c=relaxed/simple; bh=F4qgVuWMnMs4LdL+CTRHzQ3J7aBI8hD3jjoHNwwUs1I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Qt0V0RLaDZsaD6778r608QbAk+R0QAAR8+oxxTPZxPcO4V8nyF88cP6Wn53dkvCcaqXIOkxXCq5PVpl7aulnl3NP3WcwHf3pza5RGMAB9QtPnZAxYmbCpimedhHkzT39SQM7wtQOb1U9pkOSYR5S+ldQfxvB9nQUbJ4kDdjKdUk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NoYXvIeT; 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="NoYXvIeT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC950C2BCB0; Tue, 12 May 2026 13:40:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778593211; bh=F4qgVuWMnMs4LdL+CTRHzQ3J7aBI8hD3jjoHNwwUs1I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NoYXvIeT6J3DWltgXSYbRZ0YuRJa3t8mTtBGnYwn+VgeH4rfr05ua+bc9PFROwpmB IAdQkNA4ZhsY6/gVPpMgBwQdOKywRY3CE5SDA+0HFXnI4l9rMbPrcIq25qF3w3c1QY ykErn56aOvvZpartETAvRKCPTrrDS5fajvHFyH7gPKeRmLUpM4u8zXzVANW1I4BAAB fkTGRDUVLeP8IEKjL1YJ1XaOocCPHpOBO+KSP8O3Fp6OPb+wm30slurOFKK7jIqrMG LnFXVKm9WdOqXTuSXY/I5F/Cg2wXZbWrS/ltWGt7v6blPFInT6/GOr86VTsbBah1U8 exdDR2vt2SdGw== Date: Tue, 12 May 2026 15:40:08 +0200 From: Frederic Weisbecker To: Waiman Long Cc: Mike Rapoport , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , 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> <0dc53363-6a5d-4adc-bf8a-fd7bbdd8da81@redhat.com> <26f7a521-3ae4-44ea-90a3-2ff0e1aa9ae2@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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26f7a521-3ae4-44ea-90a3-2ff0e1aa9ae2@redhat.com> Le Mon, May 11, 2026 at 05:36:08PM -0400, Waiman Long a écrit : > On 5/11/26 4:34 AM, Mike Rapoport wrote: > > On Mon, May 11, 2026 at 12:55:39AM -0400, Waiman Long wrote: > > > On 5/10/26 11:02 AM, Mike Rapoport wrote: > > > > 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? > > > My original thought was to defer the freeing to init call. That changes led > > > to the KASAN bug splat listed in the commit log, I think the right window to > > > free memblock memory is currently just too narrow. Do you mean that with the > > > fix patch you sent to Breno, memblock freeing in initcall will work without > > > bug report? > > Yes, with the fix I sent to Breno memblock_free() should work in an > > initcall and "do the right thing". > > Thanks for the confirmation. I have tested your patch with my patch to defer > the memblock_free() to initcall. There is no longer any KASAN splat when > booting up a debug test kernel. You can add the following tag when you send > out your patch. > > Tested-by: Waiman Long Thanks a lot guys! -- Frederic Weisbecker SUSE Labs