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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9426EC5AD49 for ; Fri, 6 Jun 2025 08:04:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CF876B007B; Fri, 6 Jun 2025 04:04:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A73E6B0088; Fri, 6 Jun 2025 04:04:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFF1E6B0089; Fri, 6 Jun 2025 04:04:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D171D6B007B for ; Fri, 6 Jun 2025 04:04:49 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 77396140723 for ; Fri, 6 Jun 2025 08:04:49 +0000 (UTC) X-FDA: 83524239498.28.7664B80 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf27.hostedemail.com (Postfix) with ESMTP id A8FB840011 for ; Fri, 6 Jun 2025 08:04:47 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qV4jtDv+; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749197087; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xBRokSnlcCHdaBMq6kQQ3GNFB/Ro65vdXeMklGW+M5g=; b=D6QpTxTFwTGV5PcJ937sQD5tRiYI52sx5JXlmmXaqGITUWeZkKFZt7ElO8f+VQ5mvLEvBZ Di+999cabIb60uu2ZKja5v2xWH1s4hbWCUhQyNiPs5zxiZpUFlaZJujbDmNdaxB93qWIBC DV+oLCOaM6K/wcIIARUlu3Yz0voVzc8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749197087; a=rsa-sha256; cv=none; b=fI+DuZbE+Rm+zrW4yEiXi1nn1H9fnACK6avcewtQ46c0M0/72MhIy+ut0Idbmgs03wqYxk YZ11IeTf39c/DdaOZCY8HOwwlhCjVjsN9ws962txS3rPuMCDGEToxpzEVmPp3kPsVjsp7K DSnkCI7Frgt1tOV9J77V7NbXJm4+08I= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qV4jtDv+; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6940B4A658; Fri, 6 Jun 2025 08:04:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7EB2C4CEEB; Fri, 6 Jun 2025 08:04:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749197086; bh=/eAbsE62fKUCaEC3zAvD15WyaOeeMA6jncyNVQwRldg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qV4jtDv+PQOS1Z54jDelm+RkHP6SZV4PHiNcZ7pa3FEoaNtqdWNmfGY+gApAqOlfr wGx1+FACRrsQAzZ7HF9ROT3Oc5yRqgeEgYkSwrTVslT3taQMq7DRWpcBnKbjam0jkh FzS4NAgwzQCOJUMLwIGww+BNzcXdv9D8Bu/UY5PY8mAeCL0jBg78dfowP/RdmO1GY/ 8j3RSNfj4DPOJccGvQK70atOh8UnIKDqhJUl+2qw041PRIdtXhzL7igODq4SbPy5HR 5rPxt5E3JOIiJPjdgUc338VwGktz2mCgS5JNdfiK6ss7hQbT9oVG4g04Klb/wQr2zS TmnoqI11hBOfQ== Date: Fri, 6 Jun 2025 11:04:39 +0300 From: Mike Rapoport To: Pratyush Yadav Cc: Alexander Graf , Changyuan Lyu , Pasha Tatashin , Andrew Morton , Baoquan He , Pratyush Yadav , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] kho: initialize tail pages for higher order folios properly Message-ID: References: <20250605171143.76963-1-pratyush@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250605171143.76963-1-pratyush@kernel.org> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A8FB840011 X-Stat-Signature: x4r1ue36hx6ikf5673fccphqkqpowram X-Rspam-User: X-HE-Tag: 1749197087-292473 X-HE-Meta: U2FsdGVkX18iu5Lz3t57JxRyNvUiLteSVnbxPrRYw56G1BWO7pR3+xKjB7qbatdXaUgWxrP2wrUB5RwPeoD69hchGUWAcWjb3+p8y1GY8Uzgq53AzYiqsfncsjHk6H2D3CcCHhULFH7sOLseZxj0is4BGGDTe4KtOoslavbQMgBxE3ozsiezyW4OeD2ZzyvVT2q43mUEz/75NkN19O03Ef6QI1d2NWE38iaOXH6rI/GOfFggkIv9qxQOdGuULQJNbdLgIhR5vlpG2//m/Mxxooik66iYRqTHyqNlUFQugf/LmTjVrTuWfC+BEfR23sPZyeXA1LhKkuWFxcjV7hUDf6N4Jou1vnykCfouLTj6pUf9CYXlX1BgRMp574Qe6FqDo0IAwNxu18FO5UReK5S67eeCI8v53Mgpy4Lwv943ACTzd9vL+/BlYJAYZbspvPGwc3mB2B9edyFiA5KgYH/tVMRKiXaB1iaY5YkVzAJYrZQVu2USPt2pv1/kmekmB1DDGjeA6YOP8KkMYrwUebZY+q532jaQxtf6Z3hZjjNpo5JhqHMIwrGCC35q1bdT7dd9iRetUesjGDdU/Co8q6oeu4eSm1HuBOSnBiiusKXpYza50uFoQjPbrOShEh4IgnfcRhFRM8LRHZOzpbPz+PlVOZFVpUrRbgd+KtASxIfHYfWRaKYuAbfZA3Ox3P3HZrcMW49kkUU+asaUZWiOCmMUEozk30teFs0AwSS+Gte6VLoXa7oXmuvCu54ZNO+JBPyIzJFQiijQwwnm6RN6hfF7I4M4M50XweLOPDlTBphA+2HeWPWV5B2ptEf4fMUgQ5XbftlDMRpWCCf4I9HwuYBEIjSel+WC9d+8Q5oBGQW/Y4AbbKHAkpOevtDV+vO3eOlA/7DP4pUxPPKELvqKVxTEaEBLigZpyR/jj8nvNeQTL2a4RpwpQtFIqvOpCJ2uwkER9PNS1OC6dYApysY9mnP bVXCeafY Thpect+lIHRkAszBgPaV8ugvCs598EkZwahqA+NT2nYi8hs9CxVCgj4mdT9v1hdvx0PSP6o7USdo6oUZOl9rA6dlAFLhF4RiG/x5OX6PjORt3TZpd4noOdpBdrjuX0/ltAXj5meTGguF30/SVX19HQ8JSFgFmMJGcKJYNl3f2cL9/HXHdhu/SxOad3R/trcqFLGfRLmL9Cz2Z4+bz7mHnrKA09LMPq9UvmndKKI+0vzd4RMT5thAI4OHQ+D7Bsh4l+obR X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jun 05, 2025 at 07:11:41PM +0200, Pratyush Yadav wrote: > From: Pratyush Yadav > > Currently, when restoring higher order folios, kho_restore_folio() only > calls prep_compound_page() on all the pages. That is not enough to > properly initialize the folios. The managed page count does not > get updated, the reserved flag does not get dropped, and page count does > not get initialized properly. > > Restoring a higher order folio with it results in the following BUG with > CONFIG_DEBUG_VM when attempting to free the folio: > > BUG: Bad page state in process test pfn:104e2b > page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x104e2b > flags: 0x2fffff80000000(node=0|zone=2|lastcpupid=0x1fffff) > raw: 002fffff80000000 0000000000000000 00000000ffffffff 0000000000000000 > raw: ffffffffffffffff 0000000000000000 00000001ffffffff 0000000000000000 > page dumped because: nonzero _refcount > [...] > Call Trace: > > dump_stack_lvl+0x4b/0x70 > bad_page.cold+0x97/0xb2 > __free_frozen_pages+0x616/0x850 > [...] > > Combine the path for 0-order and higher order folios, initialize the > tail pages with a count of zero, and call adjust_managed_page_count() to > account for all the pages instead of just missing them. > > In addition, since all the KHO-preserved pages get marked with > MEMBLOCK_RSRV_NOINIT by deserialize_bitmap(), the reserved flag is not > actually set (as can also be seen from the flags of the dumped page in > the logs above). So drop the ClearPageReserved() calls. > > Fixes: fc33e4b44b271 ("kexec: enable KHO support for memory preservation") > Signed-off-by: Pratyush Yadav > --- > > Side note: get_maintainers.pl for KHO only lists kexec@ as the mailing list. > Since KHO has a bunch of MM bits as well, should we also add linux-mm@ to its > MAINTAINERS entry? > > Adding linux-mm@ to this patch at least, in case MM people have an opinion on > this. > > kernel/kexec_handover.c | 29 +++++++++++++++++------------ > 1 file changed, 17 insertions(+), 12 deletions(-) > > diff --git a/kernel/kexec_handover.c b/kernel/kexec_handover.c > index eb305e7e61296..5214ab27d1f8d 100644 > --- a/kernel/kexec_handover.c > +++ b/kernel/kexec_handover.c > @@ -157,11 +157,21 @@ static int __kho_preserve_order(struct kho_mem_track *track, unsigned long pfn, > } > > /* almost as free_reserved_page(), just don't free the page */ > -static void kho_restore_page(struct page *page) > +static void kho_restore_page(struct page *page, unsigned int order) > { > - ClearPageReserved(page); So now we don't clear PG_Reserved even on order-0 pages? ;-) > - init_page_count(page); > - adjust_managed_page_count(page, 1); > + unsigned int i, nr_pages = (1 << order); Can you please declare 'i' inside the loop, looks nicer IMHO. > + > + /* Head page gets refcount of 1. */ > + set_page_count(page, 1); ClearPageReserved(page) here? > + > + /* For higher order folios, tail pages get a page count of zero. */ > + for (i = 1; i < nr_pages; i++) > + set_page_count(page + i, 0); and here? > + > + if (order > 0) > + prep_compound_page(page, order); > + > + adjust_managed_page_count(page, nr_pages); > } > > /** > @@ -179,15 +189,10 @@ struct folio *kho_restore_folio(phys_addr_t phys) > return NULL; > > order = page->private; > - if (order) { > - if (order > MAX_PAGE_ORDER) > - return NULL; > - > - prep_compound_page(page, order); > - } else { > - kho_restore_page(page); > - } > + if (order > MAX_PAGE_ORDER) > + return NULL; > > + kho_restore_page(page, order); > return page_folio(page); > } > EXPORT_SYMBOL_GPL(kho_restore_folio); > -- > 2.47.1 > -- Sincerely yours, Mike.