From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 0333E81ACA for ; Mon, 11 May 2026 04:55:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778475355; cv=none; b=CNTvRrWTnFtHpXTwIvL7SB9kLYi2onyHN7y33Em/PAOxWTvQcLWR38aatlTbllN7oc20DFSkH8MZi7+pZZ8FGNjk220VqllbHKqTSdTsucB5FvOeJUMqkjzlI+6MRDwfdC3Ghz7iFP5DlMwQxyjW6/RPF6oG4uHCPKsVgU3TyVA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778475355; c=relaxed/simple; bh=7MbRJHjlAMwJGRDlYpOi80j285QdSbSq9YQT1JI9PsY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kTiSW8OdFFw2QcFRyMG9JW9wSdhEl1TSKE+InjsAyllws93C5C4KuIOa16HVa5SI9JaqOPwOk4oGwGcPvZIbvDLoNE7kqJbzS4WtEwXlsGymjzjPXkxU4BuOs49scviA0QHJLevyPOgtp8dwlzprc5nwREed6mR0BmzM1IcH77k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=HS7LP3sv; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HS7LP3sv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778475352; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RMtVfv0DGhCFiTX9GwmR9hDe90IdbATmcKZTAU81O8E=; b=HS7LP3svvx97HE9gSYLKvynT+UcbQEytLDgjDkuRq8ebgAenFG4QKVlLBqvZmaHobVdSil w3XP0HgQ/oqg7pXy50Sz8FbqqyLAGY9WA87mhtgV8JQ5jSRLLzCzIr4+SLgXGIqnFl/Bjw 7EWVMcdD7kP7iqTUoVzXPh3hKwCGzAc= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-232-B6oA_WL5M3q9o9ruECVTEA-1; Mon, 11 May 2026 00:55:47 -0400 X-MC-Unique: B6oA_WL5M3q9o9ruECVTEA-1 X-Mimecast-MFC-AGG-ID: B6oA_WL5M3q9o9ruECVTEA_1778475345 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id BC1441800344; Mon, 11 May 2026 04:55:44 +0000 (UTC) Received: from [10.2.16.21] (unknown [10.2.16.21]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 72EA330001BE; Mon, 11 May 2026 04:55:40 +0000 (UTC) Message-ID: <0dc53363-6a5d-4adc-bf8a-fd7bbdd8da81@redhat.com> Date: Mon, 11 May 2026 00:55:39 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] sched/isolation: Don't free memblock allocated cpumasks To: Mike Rapoport 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 References: <20260505051821.1107133-1-longman@redhat.com> Content-Language: en-US From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 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? If so, I can send another patch to defer memblock freeing after the fix patch is merged as the KASAN bug is more serious than the memblock warning. I will do some testing tomorrow with your fix patch. Cheers, Longman