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 DB1F22C027F for ; Thu, 27 Nov 2025 05:05:12 +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=1764219912; cv=none; b=YP1MEMcK/ga1Gt03QDkYqTF9d/BCgJiDhhMTMDPNCBjfIrDyYrglBF6F/sD4IwdBUCI9eMZxFTpBMcHmrmhEceXTxLJTlSMltpyISCqR3ZXZjMRCFL95BY6uQfGYJhGZ2hCZMAo1dxsVjAHjUfdkjlF9xWFK8s6mgjkpU1xl5pA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764219912; c=relaxed/simple; bh=0JRSyQXSjczKq5XdXn3CWvx8+zdnsFfxK+TfDYlXczY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=n4OCloHesguVeD93O2j6OjTTFj9hMJFTnPk7DT/o066Ch241ItaiqdLliVLtiLjj9aBJFdtp4zWQ5L9xtiuycRU10JOfWleqXLyrcKP7lFM4ScNYR7BgPYO+fdZXdQUOu0uSZaMqNLBg8EMj7aFhYPylkQPtEFRhHjPaVlWa7QI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C6gjVPPd; 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="C6gjVPPd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98277C4CEF8; Thu, 27 Nov 2025 05:05:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764219912; bh=0JRSyQXSjczKq5XdXn3CWvx8+zdnsFfxK+TfDYlXczY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=C6gjVPPdP/VVRhfNC+VDHXi2GkriaQ59zF9dvrRLavOayKedKO5VbJRufDpzaSKcT 18Yctoq4Bqz+A3ymRbCPtfV0a8OX0gaSH+Bm6w4VQzsKXgtFzCgKm5ydaL5PtJQ29h tAfGWpMBVJbutynfBiW2hC33t3Pjdnc9gI26HN9BHIfQdB+IRyFb8YI4OTAELjHoms YU3d6pfUEf5aVjmhCea6buNTMXzYuBplHMU86HuFKkimf1lNCq9yQdgXLx+zpo27ue WRk7CmXmcxExayuBj/MLwXSztWFz37wHyVxg1s6TYpUsgDjvdYx+b1Swxhj+lI21p7 Al/h8msq0yXNQ== Date: Thu, 27 Nov 2025 07:05:04 +0200 From: Mike Rapoport To: Usama Arif Cc: Kiryl Shutsemau , Andrew Morton , changyuanl@google.com, graf@amazon.com, leitao@debian.org, thevlad@meta.com, pratyush@kernel.org, dave.hansen@linux.intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH] mm/memblock: only mark/clear KHO scratch memory when needed Message-ID: References: <20251126072051.546700-1-usamaarif642@gmail.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: On Wed, Nov 26, 2025 at 11:43:21AM +0000, Usama Arif wrote: > > On 26/11/2025 10:40, Kiryl Shutsemau wrote: > > On Wed, Nov 26, 2025 at 07:20:51AM +0000, Usama Arif wrote: > >> @@ -1126,8 +1126,11 @@ int __init_memblock memblock_reserved_mark_noinit(phys_addr_t base, phys_addr_t > >> */ > >> __init int memblock_mark_kho_scratch(phys_addr_t base, phys_addr_t size) > >> { > >> - return memblock_setclr_flag(&memblock.memory, base, size, 1, > >> - MEMBLOCK_KHO_SCRATCH); > >> + if (IS_ENABLED(CONFIG_MEMBLOCK_KHO_SCRATCH) && is_kho_boot()) > > > > It makes me wounder why CONFIG_MEMBLOCK_KHO_SCRATCH exists? It seems to > > be a proxy for CONFIG_KEXEC_HANDOVER which is the only option that > > selects it and does it always. > > > > Can we make s/CONFIG_MEMBLOCK_KHO_SCRATCH/CONFIG_KEXEC_HANDOVER/ and > > remove IS_ENABLED() from this check? Just is_kho_boot() is enough. > > > > > > Thats a very good point! I imagine it might have been for maybe debug purposes? > > Looking at the code, CONFIG_MEMBLOCK_KHO_SCRATCH shouldnt be needed. I guess > this might be a good time to clean it up. If Mike is happy for it to be replaced > with CONFIG_KEXEC_HANDOVER (and removed where needed), happy to send that > for review instead of this. Yeah, let's kill CONFIG_MEMBLOCK_KHO_SCRATCH and use CONFIG_KEXEC_HANDOVER where needed. IS_ENABLED() is not needed in the check because with CONFIG_MEMBLOCK_KHO_SCRATCH=n both mark_kho_scratch() and clear_kho_scratch() are empty stubs, so it's enough to check is_kho_boot(). > Thanks > Usama -- Sincerely yours, Mike.