From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BEAB8CA5FE3 for ; Sat, 3 Oct 2026 07:59:45 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4hxdNH5CKJz2y1W; Sat, 03 Oct 2026 17:59:43 +1000 (AEST) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=172.234.252.31 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1791014383; cv=none; b=AUxuT1rRFvXOmnIRz7YpwZv40a2HRYOZCCRb2ItS/2cewGeMyQmb9GMW/I82KB2jTtviDoYsrGeExcPZiVd7MEEgaAqHpTm1bBMi8966urtvqWpk1sD/SZKLAoevbGC2eOhh/Gx7JFgE+WfUZ+sIyBe8W5Kahxo53c9B9ySa9lx+1cdD3cnzZ/8WvFEfjV9UpGmWlUqeGByXjLqiixWoxJrIDlDfT1SckY55pRmgUzxu1/k5g+GZ95c2vPJodIhoqk8SKkr4gu1NN3y40Vmo4VJwI+ufIOumJhejCk5p/66dVNfB2Wo8dNEPpyemAriFvW++6N+c5nRH020KpCKY8g== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1791014383; c=relaxed/relaxed; bh=q9kqnwZJAXRfho77Yt6ZBil51mcAO7in4pebx6oB4fI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B3hQU5N5kVk/ya133eVexpIooZ5/1craV3zKWXE8xm3awVaBcVbldeca7BuvaQGYyVbq6Cbfpr1uEEfnAZCDT7KJxf3BqaPgHm2vo3RKNBIxjIsnwrFKduHOXLcUNb/ynB91Gl9JV1IAPZlXK7vn4+vQyec4iMNW2kxod5KHENI6l3MsFO/WtTZuJvhVw1SbGTRfwsHukxgU9MAEsmeieiMXjZMPSL24upkw7nSM7kxldVshYkl2xI0mcMKstSKxpsq+P6S8esl9+UhOItjx8Lg/deVP7YYKUfKGiryrEGa5Pw1uQQ9wE4DpGQduOtAb4PSL/Mn09vjMPR3p8K7s2A== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=RxaGWxF3; dkim-atps=neutral; spf=pass (client-ip=172.234.252.31; helo=sea.source.kernel.org; envelope-from=rppt@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=RxaGWxF3; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=172.234.252.31; helo=sea.source.kernel.org; envelope-from=rppt@kernel.org; receiver=lists.ozlabs.org) Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) (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 lists.ozlabs.org (Postfix) with ESMTPS id 4hxdNG4dZvz2xr2 for ; Sat, 03 Oct 2026 17:59:42 +1000 (AEST) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id C501340454; Sat, 3 Oct 2026 07:59:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C4E41F0089C; Sat, 3 Oct 2026 07:59:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791014379; bh=q9kqnwZJAXRfho77Yt6ZBil51mcAO7in4pebx6oB4fI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=RxaGWxF3L4YTsdWVZArvggDDeEJeU5k2/xlxIc3gGpz9W2LTy5PnXLsH5+kmuA34l k8k51YV/fJQ4zDkpUft0AkWeshphy5QyCqQfcNbiUSKgGpciheKBpVzcofbgs97eE+ wrOA+at67oZyPaecBMS1VaV3N/LOSsqgz2V6KBGkG3g4Ovu6kMPODYpET/eI9SE27J qSflSFBiZUZIj5pjUMyuBrQaWTon+QBk3OhV4WDI/09aTJJ+EEuygjRW4EYljdZ278 U9nho+HEBe2izjuNJGGYvx0UqAnGrAKxpPaS9uwbTu330E801mo+wf4ghP1FOIUDDd yf8LCtugigeuw== Date: Sat, 3 Oct 2026 09:59:32 +0200 From: Mike Rapoport To: Sourabh Jain Cc: kexec@lists.infradead.org, Aditya Gupta , Alexander Graf , Andrew Morton , Baoquan He , "Christophe Leroy (CS GROUP)" , Hari Bathini , Madhavan Srinivasan , Mahesh Salgaonkar , Michael Ellerman , Nicholas Piggin , Pasha Tatashin , Pratyush Yadav , "Ritesh Harjani (IBM)" , Shivang Upadhyay , Shrikanth Hegde , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v1 1/2] kho: check scratch vs CMA alignment at runtime Message-ID: References: <20260928083226.107807-1-sourabhjain@linux.ibm.com> <20260928083226.107807-2-sourabhjain@linux.ibm.com> X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260928083226.107807-2-sourabhjain@linux.ibm.com> Hi, On Mon, Sep 28, 2026 at 02:02:25PM +0530, Sourabh Jain wrote: > KHO requires the scratch alignment to be at least CMA_MIN_ALIGNMENT_BYTES, > and this is currently enforced with a static_assert(). > > That assertion breaks the build on powerpc once CONFIG_KEXEC_HANDOVER is > enabled together with CONFIG_TRANSPARENT_HUGEPAGE or CONFIG_HUGETLB_PAGE: > > kernel/liveupdate/kexec_handover.c:49:39: error: expression in static assertion is not constant > 49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES); > ./include/linux/build_bug.h:80:56: note: in definition of macro '__static_assert' > 80 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg) > | ^~~~ > kernel/liveupdate/kexec_handover.c:49:1: note: in expansion of macro 'static_assert' > 49 | static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES); > > CMA_MIN_ALIGNMENT_BYTES depends on pageblock_order, which is not a > compile-time constant with certain configs, such as > CONFIG_HUGETLB_PAGE_SIZE_VARIABLE on powerpc. The next patch in this > series enables KHO on powerpc, so the alignment must be checked at > runtime instead. > > Replace the static_assert() with a runtime check at the start of > kho_reserve_scratch(), before any scratch memory is reserved. If the > scratch alignment is smaller than the CMA minimum alignment, warn once > and disable KHO rather than continue with a misaligned reservation. Can we keep static_assert() for everything !powerpc please? Like something along these lines: #ifndef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE #define check_scratch_alignment static_assert(...) #else static inline bool check_scratch_alignment() { ... } #endif > Cc: Aditya Gupta > Cc: Alexander Graf > Cc: Andrew Morton > Cc: Baoquan He > Cc: Christophe Leroy (CS GROUP) > Cc: Hari Bathini > Cc: Madhavan Srinivasan > Cc: Mahesh Salgaonkar > Cc: Michael Ellerman > Cc: Mike Rapoport > Cc: Nicholas Piggin > Cc: Pasha Tatashin > Cc: Pratyush Yadav > Cc: Ritesh Harjani (IBM) > Cc: Shivang Upadhyay > Cc: Shrikanth Hegde > Cc: linux-kernel@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Signed-off-by: Sourabh Jain > --- > kernel/liveupdate/kexec_handover.c | 23 +++++++++++++++-------- > 1 file changed, 15 insertions(+), 8 deletions(-) > > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c > index 7c4d86daf86d..dc76dd6b74da 100644 > --- a/kernel/liveupdate/kexec_handover.c > +++ b/kernel/liveupdate/kexec_handover.c > @@ -39,15 +39,7 @@ > #include "../kexec_internal.h" > #include "kexec_handover_internal.h" > > -/* > - * This is the minimal alignment required by deferred struct page init. > - * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks > - * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them. > - * If KHO scratch is not aligned to that value, buddy can access uninitialized > - * struct pages, which can cause a crash. > - */ > #define SCRATCH_ALIGNMENT_BYTES (PAGE_SIZE * MAX_ORDER_NR_PAGES) > -static_assert(SCRATCH_ALIGNMENT_BYTES >= CMA_MIN_ALIGNMENT_BYTES); > > /* The magic token for preserved pages */ > #define KHO_PAGE_MAGIC 0x4b484f50U /* ASCII for 'KHOP' */ > @@ -836,6 +828,21 @@ static void __init kho_reserve_scratch(void) > if (!kho_enable) > return; > > + /* > + * This is the minimal alignment required by deferred struct page init. > + * deferred_init_memmap_chunk frees memory to the buddy allocator, which looks > + * at the neighboring pages (up to MAX_PAGE_ORDER) to merge them. > + * If KHO scratch is not aligned to that value, buddy can access uninitialized > + * struct pages, which can cause a crash. > + */ > + if (WARN_ON_ONCE(SCRATCH_ALIGNMENT_BYTES < CMA_MIN_ALIGNMENT_BYTES)) { > + pr_err("scratch alignment %lu < CMA minimum %lu, disabling\n", > + (unsigned long)SCRATCH_ALIGNMENT_BYTES, > + (unsigned long)CMA_MIN_ALIGNMENT_BYTES); > + kho_enable = false; > + return; > + } > + > scratch_size_update(); > > /* FIXME: deal with node hot-plug/remove */ > -- > 2.55.0 > -- Sincerely yours, Mike.