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 8E89F416860 for ; Thu, 13 Aug 2026 11:38:02 +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=1786621083; cv=none; b=co5qgGMFPYHNuoiCE4pXeYpOTTy4cHHNBt9S1qrKVPXUACFhWb4g7z6wGq97oLho+kNMdvnIDxcY0m/2wzvDB5GfYG5FHqHicdp8UJiuny1lUGEvhbhfbcuTfC2CgSimmV5Cz++V89odkV6UHK/m2TUOzuejnJZxbxuFXYXbOcc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786621083; c=relaxed/simple; bh=4xO7v9vpTwMYy26vGgkDXUvxJapgZNSa2iXa+fvdVbk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=imVeT0upfxLqnwDzFbvk87JnylFfiDShdwbQM2rEYBQogth6gWow0l0dqsgZkxEkiR4ARNeJd+6Jx7qZhi5m3otQqn/xVccmx/8RIfcX+LcaZ+b3k55gTn93YYBQoAsC+9LSfLxZM3onZXJ+hOknwl2FOPWgHL3OBQ/LmNTjtHI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Xr4HrNQw; 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="Xr4HrNQw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 609681F000E9; Thu, 13 Aug 2026 11:37:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786621082; bh=E0q0foin1r7ZJY1ZfoJ0F+Tbh2/pSdHGZVciFlboEyA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Xr4HrNQwh1yloKOrotLUQovwW+pRON76NvZ3uDr+evkMZafPCejupzsd5yBqPJ1UI 8c1Z7UFUcFosV32c+w6CUUBxTlQGVry1vPNCGrZ4hZdeIv5MIq6KaRCuf74zQTgL7P f/bjtoRUhw9dKOgimuT6IBOIGFXYRiy7udigDY2AXqW6VvR71WzkIrRG3OBWiip83n 1WOnqeLkXpb3LbsR1fVpm96w86faUihlVa7V+kU0jXqSfZEI1PnVw2/TM213tS2FrZ jBEVHg85KNMML/cnocL9oX73xBHkE93gLGMGs17bZsag4n2O0hp3IxCaBMlQOiAPZp 4W+30ugtrf2SA== Date: Thu, 13 Aug 2026 14:37:54 +0300 From: Mike Rapoport To: Pratyush Yadav , Suren Baghdasaryan Cc: Pranjal Shrivastava , Pasha Tatashin , 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 Message-ID: References: <20260803113944.3694290-1-praan@google.com> <20260803113944.3694290-2-praan@google.com> <2vxzqzk338y2.fsf@kernel.org> 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: <2vxzqzk338y2.fsf@kernel.org> (added Suren) On Wed, Aug 12, 2026 at 12:54:45PM +0200, Pratyush Yadav wrote: > 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 -- Sincerely yours, Mike.