From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D97D831B83B for ; Wed, 12 Aug 2026 12:33:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786538009; cv=none; b=cxTKOr6hIYYkS3uHOGWcLXyo0GtsLkDONkx3TMwZgK3NE0erpAPPE9cvEXaEP49XNWfGFR0MEztKhhZvTHoq/lcs7BTIJOSndNYaTSZjmuK5sfUUS0u7QI7HnAgbeWzP+ssry1ekd/Q0Uvnvqcdv3FGdL07uldLkZrEuVcp/6CE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786538009; c=relaxed/simple; bh=v61DrLUjg1iBo8OHKps1f0Rel8LoUio5Kg3/2KsArYQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TYsDUGcOVT5vXOEizpXVGBFtwn5CY2fwbjEmkr49qY68b0InSQxdBepbnkvvfqr8Eo4k/TbQBUDVWN4anoFTxkHXcUPpK1eP3sSOJQUsTZHMjb4fn90rSabNNdPXZxb9wAyd6Xx10qcb1RNSP0vjIIV8/xgqFuZh2Js9ozdRItA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=T+ajeYTC; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="T+ajeYTC" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2cede6375caso83985ad.0 for ; Wed, 12 Aug 2026 05:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786538007; x=1787142807; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=S8keOZILRO+hA/w6RNVNhXJ75VzJNzahD3Vhsnf0uDM=; b=T+ajeYTCQfejwFXa8PoAZLUkc4Ye5SdoK9VsbTY3yyT3bzy1M1VV9eB3Cda7vXzXid fgi/V6V7W3nFanROKnpGf5YFdr73LNThzL0HksbV5NqY+oF0UHqT+h6E4uaZ5ZFpWvMD 2rFuK6Le9X3uSIHRrz1qsIzP9isAHwfl+JRmBeAk3L54m6I1GLcJ6/cD4dnATgjRhL4j XOy/2ho/9rm3dy2vm9nmR3gwhLVXHfJlEXZC4UGM7dTWF+bY7TD69vP3Zzb7H9JiCrII SaXy+lXsjiXc5jQ6HovJALpJLf2Zthkz2vlmWFIAUnmuAA2UFE1nSLA3rLeHlJYOhsC6 A7gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786538007; x=1787142807; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=S8keOZILRO+hA/w6RNVNhXJ75VzJNzahD3Vhsnf0uDM=; b=pM79qDHdm4GY8zPEwoGt6sS0vWDkNK0PyAOHTqEIWwxuYvQu4CJpfNEtd6Pr03v7vY blq7rDtlOTY8Y70ATxHDMSCvXuYIFooWDnjXEis4iXUTF4nQ6j8UJ/nBcfuN8vxvnO/I j5MtegJat7QDN/JpH8qhxju3dihoDvCCrIfBSeL+myMhD5KZTVDyq0gfTiNVOmDwcWXW Lz0v46SfQJq16y+8jj1om4DeEaahzXH1cvV9H8iiXffOaz27kkafyX5hVDMGMr7GsYX6 WOMnUsAWSp3laV8mH9L4cTMm6i7iguEscZnrpMVYMjZqiG9XFQnWrNP7U5eKxroDiyRw Qe2g== X-Forwarded-Encrypted: i=1; AHgh+RrF9tGctcpK2y95iNP/hB303FUdUshs3b/VER/rez6mwSOiNhlcdsTzDj0OAkGD1T4MLe724euf9ZA5I10=@vger.kernel.org X-Gm-Message-State: AOJu0YxZ6Kwfp62giLUg9G+FfxH5gl/odBmnHwrmSnAd/P9bFcA2pmDl jfMrBt//S0k5wPJcgtEFRIAuwY0t30SEY3+Y4LtECUXfhAr+jP1t/IdFzw43OIF4kg== X-Gm-Gg: AR+sD13+FEfsyJGNE0w36Kmc4qTK4FJpkdfeO3pwHCYwtKWsaZjqV0sfC+moM3xHiSp 1gA1QpWff8HnuxKl/kxL2R6q2Pomc+crVGbAbXXI194dJRtxN1JnL/U5WxFFXPxRJmNPtmquQIm Ogh7Ztndhd88vY0meB+6ybQSmfQRR6pmurfUgF5B6QT/8zEwc2+yB+ISxxS5eIrW9gwBR0LjRJ7 e5sK2A7b2mdw9/U/ZxOBnt763iFQXlLFtgi/RdOZ8dceJFzRaNGzAMqWaKNfSWgGIBN7FIJE1wp pA91dfgCbmQ+B9/SoaPA23c3jRjARab43v4Z7YKVVegB7MmjsJr7jF3nWvyabB1j6lW9WJa0FAM te19j16SPcnzEi83H1MTm14qqJtrEEf13Cszeg9M/B95/v90NcYdxLm34heCVkk2rQnwjhTLHcH 4GI53zfUphylA9cNx3kdBBMfMfiRGBeMEVeTa8nhL8A2UGUh60nkasLab7a2RSENN7hk8UawA7U mcU+QpkkR/XiqmEBIdYR0g= X-Received: by 2002:a17:903:2acc:b0:2ce:b436:272a with SMTP id d9443c01a7336-2d34aa4449dmr5490875ad.3.1786538006669; Wed, 12 Aug 2026 05:33:26 -0700 (PDT) Received: from google.com (21.168.124.34.bc.googleusercontent.com. [34.124.168.21]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d352218b5bsm5554125ad.70.2026.08.12.05.33.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 05:33:25 -0700 (PDT) Date: Wed, 12 Aug 2026 12:33:19 +0000 From: Pranjal Shrivastava To: Pratyush Yadav Cc: Mike Rapoport , 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> 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? > Hmm.. I added it here because I saw pgalloc_tag_add(..., 1 << order, ..); being called in the post_alloc_hook [1] but digging deeper I see it doesn't set a tag_ref on the tail pages for non-compound high-order pages (i.e. it doesn't loop over 1 << order pages) [2] We seem to clear tag refs which shouldn't be set in the first place, I'll remove the clear_page_tag_ref(page + i); in the tail loop. Thanks, Praan [1] https://elixir.bootlin.com/linux/v7.2-rc3/source/mm/page_alloc.c#L1861 [2] https://elixir.bootlin.com/linux/v7.2-rc3/source/mm/page_alloc.c#L1255