From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 F1D2A331EBB for ; Wed, 12 Aug 2026 10:54:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786532090; cv=none; b=llaFnz6R9s3nTE8dG0CjTEZW794sna3TObz8zcj/gxYwVAzitFL4rftvm1bvagBsMjq9viPQyDVJIWv6FT0rfwXWij9zUpgd2kXA4UML4JH6e1h0yg80lS/IvgIlcmSgyzT2nTbxLBEWFdNaC38zEsQIF4L8d0ClKZaf1r2Pml4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786532090; c=relaxed/simple; bh=C6Xl/LQktzj4+sLbQnVRvvhJrCBMWDax3O88yD5t0I4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=aEt+9QOmv+3P/eTG71aN8nBYyNXf0HTIz6/taOJiPIpME4y716cJoKzvxzIur2Cl01JrRohpinawSszKgNNYyipl5CCqBJXKy69XYI00Hl5F3tv8rPLNBbv0dwASqk1uHKxKezQHuKr87lM/mGQ/Mi1XNRr9SbEGoTLc/2fubC8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e4Kol6Pv; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e4Kol6Pv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DF661F000E9; Wed, 12 Aug 2026 10:54:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786532088; bh=gcj6Nn0OFnz4GVFzatZ7HMT0a0oMws6ttw7Nr/ddbvA=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=e4Kol6PvyyOtzPhPagi2RlBVhqqAA7P1Cs2LzWOU5K1eCStNaPc4a99nRCN1UdI6M vVZzjgAnLWr9tk7FkTojT23M+CeDDUgNibnxOMEvO/aH/86z7TvLYW1sJmAFChKosU jOb4iwX4pOZjt0f4Sk/0O9kKwQ5P0C3SKbEgXXQ1cuPk+BJrDgvIMJiZZD1MltiHN7 p8Sw1hpDwgA0fBhzysexJXQoMAwQxwdXSngbgu/YZtBpNHSvr7VumdzRLyG7LUhRnd xhP939zAnPaZvj+3SVQDPxWI33MKbkpvx8+Zpl75fN9mjfoa89wePPk5BNR9FlrEPp +1+GaVfGdRPyA== From: Pratyush Yadav To: Pranjal Shrivastava Cc: Mike Rapoport , Pasha Tatashin , Pratyush Yadav , Alexander Graf , Samiullah Khawaja , David Matlack , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/2] kho: Introduce a helper to init high order pages In-Reply-To: <20260803113944.3694290-2-praan@google.com> (Pranjal Shrivastava's message of "Mon, 3 Aug 2026 11:39:42 +0000") References: <20260803113944.3694290-1-praan@google.com> <20260803113944.3694290-2-praan@google.com> Date: Wed, 12 Aug 2026 12:54:45 +0200 Message-ID: <2vxzqzk338y2.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Aug 03 2026, Pranjal Shrivastava wrote: > The current KHO restoration logic assumes all multi-page blocks are > split into independent 4KB pages. Break out a helper to prepare for > supporting high-order non-compound pages. > > Extract kho_init_high_order_page() to handle the refcount pattern > where only the head page is refcounted. Use the helper for folio > restoration that requires a similar refcount logic. > > Reviewed-by: Samiullah Khawaja > Signed-off-by: Pranjal Shrivastava > --- > kernel/liveupdate/kexec_handover.c | 29 +++++++++++++++++++---------- > 1 file changed, 19 insertions(+), 10 deletions(-) > > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c > index 4834a809985a..e836efd98795 100644 > --- a/kernel/liveupdate/kexec_handover.c > +++ b/kernel/liveupdate/kexec_handover.c > @@ -357,6 +357,24 @@ int kho_radix_walk_tree(struct kho_radix_tree *tree, > } > EXPORT_SYMBOL_GPL(kho_radix_walk_tree); > > +/* For physically contiguous pages. */ > +static void kho_init_high_order_page(struct page *page, unsigned int order) > +{ > + unsigned long nr_pages = (1UL << order); > + > + /* Head page gets refcount of 1. */ > + set_page_count(page, 1); > + /* Clear head page's codetag to avoid accounting mismatch. */ > + clear_page_tag_ref(page); > + > + /* For high-order blocks, tail pages get a page count of zero. */ > + for (unsigned long i = 1; i < nr_pages; i++) { > + set_page_count(page + i, 0); > + /* Clear each page's codetag to avoid accounting mismatch. */ > + clear_page_tag_ref(page + i); > + } That's sneaky... The patch _almost_ looks like pure code movement, but then adds this little change. I'm not saying this is intentionally sneaky or anything of the sort, but these kind of things are easy to miss during code movement and should get a patch of their own or at least be called out in the commit message. I don't know how page tags work, but IIRC when the change was originally added by Ran, he said that we don't need to clear the tag for tail pages. That held true for folios, does it not hold true for non-compound high-order pages? > +} > + > /* For physically contiguous 0-order pages. */ > static void kho_init_pages(struct page *page, unsigned long nr_pages) > { > @@ -369,16 +387,7 @@ static void kho_init_pages(struct page *page, unsigned long nr_pages) > > static void kho_init_folio(struct page *page, unsigned int order) > { > - unsigned long nr_pages = (1 << order); > - > - /* Head page gets refcount of 1. */ > - set_page_count(page, 1); > - /* Clear head page's codetag to avoid accounting mismatch. */ > - clear_page_tag_ref(page); > - > - /* For higher order folios, tail pages get a page count of zero. */ > - for (unsigned long i = 1; i < nr_pages; i++) > - set_page_count(page + i, 0); > + kho_init_high_order_page(page, order); > > if (order > 0) > prep_compound_page(page, order); -- Regards, Pratyush Yadav