From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 A03182D0C9A for ; Wed, 14 Jan 2026 18:42:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768416150; cv=none; b=pZQw1xzN3edUyKZWg2dyR+/7pQCTIl7jCocfe70hdF+Rk6JbE+cZGx05BRHop3ky9mA3yZ9/n7lBqIR0su+BHzYrkd4zbOr7dotiHA/87ZuAyo/s60/FYFCERbFRe/RYtpX76I/iWbAv1/jlavdMmo/1/8whHU3iTvCkBb2cEMc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768416150; c=relaxed/simple; bh=ycsyR+UpdbT5i32Mze2qlwVxIhWj61Ue122fNAYGHY0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=F+cLUo9bceRnpMNHaJfHX4+x406JkzVzpTafrZXMFe/QU/lKR7vqJRA1pZT+vW7Sgv+23n2/07nJt2z5+UPvAqTzaWjGN8FeNH23R8SfJdVUGxzsHTBN4e9a5OEd7Zf4zoClUL2p31L92RwiOSVwPOZIPlQxxdU7cXR/A1I+/1A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ixSrRuMj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ixSrRuMj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B409C4CEF7; Wed, 14 Jan 2026 18:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768416150; bh=ycsyR+UpdbT5i32Mze2qlwVxIhWj61Ue122fNAYGHY0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ixSrRuMj11g7YibcuR9ajWVVm3hwT2dwBpFnZ4aM4ryqzWSCkw9oXmRW6zfsIgTCP jahC1f4rIshZtEZluXbRp/sCICEQOAPBcF9OadgwyNs/jEupj5lVVWX5O1epJEj0TM D681YQbymK9TlZhbbH5aGzvWA7pWz9Ak9RG70/bM6V3TuJ12TnE+4/XwAL3Q21xneu NFij89IbSZ5Lq6779M9VT/TZCQUM7ppogVxMlx4xqQ6BRugL8KReK5fGXg+WsN+FLC AdH9yQFF2eMHSm5lewA1h/3LAqm5B17N0KoqzBS1UfcUBCPpKzh6I8bgvYe3uMUZTJ 48N8FVxcJKwAQ== From: Pratyush Yadav To: Suren Baghdasaryan Cc: Pratyush Yadav , ranxiaokai627@163.com, graf@amazon.com, rppt@kernel.org, pasha.tatashin@soleen.com, akpm@linux-foundation.org, kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ran.xiaokai@zte.com.cn Subject: Re: [PATCH v2] kho: init alloc tags when restoring pages from reserved memory In-Reply-To: (Suren Baghdasaryan's message of "Wed, 14 Jan 2026 09:59:10 -0800") References: <20260113033403.161869-1-ranxiaokai627@163.com> <2vxztswoi16k.fsf@kernel.org> Date: Wed, 14 Jan 2026 18:42:26 +0000 Message-ID: <2vxzpl7chw8d.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 14 2026, Suren Baghdasaryan wrote: > On Wed, Jan 14, 2026 at 8:55=E2=80=AFAM Pratyush Yadav wrote: >> >> Hi Ran, >> >> On Tue, Jan 13 2026, ranxiaokai627@163.com wrote: >> >> > From: Ran Xiaokai >> > >> > Memblock pages (including reserved memory) should have their allocation >> > tags initialized to CODETAG_EMPTY via clear_page_tag_ref() before being >> > released to the page allocator. When kho restores pages through >> > kho_restore_page(), missing this call causes mismatched >> > allocation/deallocation tracking and below warning message: >> > alloc_tag was not set >> > WARNING: include/linux/alloc_tag.h:164 at ___free_pages+0xb8/0x260, CP= U#1: swapper/0/1 >> > RIP: 0010:___free_pages+0xb8/0x260 >> > kho_restore_vmalloc+0x187/0x2e0 >> > kho_test_init+0x3c4/0xa30 >> > do_one_initcall+0x62/0x2b0 >> > kernel_init_freeable+0x25b/0x480 >> > kernel_init+0x1a/0x1c0 >> > ret_from_fork+0x2d1/0x360 >> > >> > Add missing clear_page_tag_ref() annotation in kho_restore_page() to >> > fix this. >> > >> > Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservatio= n") >> > Signed-off-by: Ran Xiaokai >> > Reviewed-by: Mike Rapoport (Microsoft) >> > Reviewed-by: Suren Baghdasaryan >> > --- >> > kernel/liveupdate/kexec_handover.c | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/ke= xec_handover.c >> > index cd6b3fb9dcae..2d47f2c50bd8 100644 >> > --- a/kernel/liveupdate/kexec_handover.c >> > +++ b/kernel/liveupdate/kexec_handover.c >> > @@ -268,6 +268,7 @@ static struct page *kho_restore_page(phys_addr_t p= hys, bool is_folio) >> > else >> > kho_init_pages(page, nr_pages); >> > >> > + clear_page_tag_ref(page); >> >> You are only clearing the tag for the head page. The tail pages are >> still un-initialized. Is that intentional? > > In the case of a compound page we set the tag only on the head page, > so this is correct. > >> >> What about non-compound pages (the ones you get from >> kho_restore_pages(), aka when is_folio is false)? Do we need to clear >> the tag on all pages in that case? > > In the case of kho_restore_pages() we call split_page() which calls Not since 7b71205ae112 ("kho: fix restoring of contiguous ranges of order-0 pages"). That commit removed the split_pages() call and open-coded the page initialization logic tailored for KHO. So I think you do need to initialize the tags for kho_restore_pages(). I sent a patch [0] simplifying the page init logic a bit. I need to do a v2 but it is a very simple change so I can get that done tomorrow. I think it would be good to base your series on that since that would make it easier for you to modify only the kho_restore_pages() path and the end result would be cleaner. [0] https://lore.kernel.org/linux-mm/20251223104448.195589-1-pratyush@kerne= l.org/ > pgalloc_tag_split() and that propagates the tag from the head page to > all the tail pages being split from it. However now that I'm looking > at it, I'm not sure pgalloc_tag_split() works correctly if the tag > reference of the head page is CODETAG_EMPTY. In summary, this patch is > fine but there might be a bug inside pgalloc_tag_split() if the tag > reference is CODETAG_EMPTY. > > I'll analyze and reproduce that case. If it indeed has the issue I > think it's easy to fix it by creating a specialized alloc_tag object > with alloc_tag->ct=3DCODETAG_EMPTY and make __pgalloc_tag_get() return > it if the page's tag reference is CODETAG_EMPTY. > >> >> > adjust_managed_page_count(page, nr_pages); >> > return page; >> > }