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 C9B24C369AB for ; Tue, 15 Apr 2025 07:49:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60F9D2801CE; Tue, 15 Apr 2025 03:49:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 59A5D2800C7; Tue, 15 Apr 2025 03:49:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43ACC2801CE; Tue, 15 Apr 2025 03:49:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 242AF2800C7 for ; Tue, 15 Apr 2025 03:49:24 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BA3E4B229E for ; Tue, 15 Apr 2025 07:49:24 +0000 (UTC) X-FDA: 83335503048.21.A94B7EC Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) by imf17.hostedemail.com (Postfix) with ESMTP id CDAFE4000C for ; Tue, 15 Apr 2025 07:49:22 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=tEttmYOD; spf=pass (imf17.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.173 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744703363; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ByW6HPxFcxRsglwqIKn+qgCgO3dW6iqP67Paz1bTeZ4=; b=ZwpbKGjrLgwigFMawReJRg1Fg6MWESys+Nl7TQXr5jVlYyQ6QD/qZv+RVKzLklnqNFSAWN QwXofeJTD7cBrY9jNM5fTAY4ulsJ/0JookG6kcnzljvfNpxAbBjHFnhlaJQyZOiiDk0w0Z RJbTRKHJlC5HwTXk42g7jmoFeSAIdS0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744703363; a=rsa-sha256; cv=none; b=ENa1oQ1VyAANYnF9RU1fjptuxbMaK9Vth2WePvZ7Z0HVCqowJilHaKVBuhHlrvfH56kgN0 4yQdSBXK9eFNbqH57QMeF1ywhHZaz/+oORX8CJOa6jzLNvG5mp8UeFRVM8xHGGkD6Dxo1n d0n/VQRiftk5fQB07QTWTpoOX5yoz0Y= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=tEttmYOD; spf=pass (imf17.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.173 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1744703360; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ByW6HPxFcxRsglwqIKn+qgCgO3dW6iqP67Paz1bTeZ4=; b=tEttmYODW/NrdlmG+LFlwQw/fO7aX2fQeE2M4L98pNGv8kYuv03jWouMZmPMpykJ20JlVG 20nwjNHc7fjIu3TPdkVHvFlOALBwI5KqUs1sElNqdmBGY/EpWJQAdayZuCryMolMteSTDz FwbzJe2LJZ3s+EwI1uE+GzHcngIpYdg= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: [PATCH] mm, hugetlb: Reset mapping to TAIL_MAPPING before restoring vmemmap X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Tue, 15 Apr 2025 15:48:39 +0800 Cc: Oscar Salvador , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vlastimil Babka , Matthew Wilcox Content-Transfer-Encoding: quoted-printable Message-Id: <543686EA-CA72-4883-858B-15804FDB96F3@linux.dev> References: <20250415054705.370412-1-osalvador@suse.de> To: David Hildenbrand X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: CDAFE4000C X-Stat-Signature: rq4sfebczhn9r6agoqx3sqwg935ssdr1 X-HE-Tag: 1744703362-362323 X-HE-Meta: U2FsdGVkX1/pRO62Vw+Hc7LFAU4nv8oAipVaCgtnFjpUcxjgPsCwFU6NLpFu75MZSu81z30fnkDSKitWpXS43zhnfFrsUlgCXILCDEEIA0Wn13mr5Ru5Nfvbv7S6/cM+An67++KG2GPtX13lLN8quZYYifBxGl4CxcJR1PK9xmBx+xN+YdfXHykCfSdYzUzmnyUihCK2PVFrfHmV7Ms6I8lR2yke9aVSQo1Mx2dwNySJYEyWfY9/eI/G4T+tLhYrH/QrNmx24Wx/EbZ8hqWtv94zs+yHTPx4Tl02IvnZb7vycM3fgbQtO05q/IX2f09c7udMsksSLi1xct1D1T1FtAQcz8UNxQYdvbxEnT4TNNCk8f3Zf5SxEJGdQy2PiQrxYBkVchP3YFGt1gHu6fqIVNgyZBpG1vsYg+pSIVclxHiitpKebrXT6Nrl/hb5SL8cRY2tbAm4xSCCcGu2gYzXVbmEEZouqCzUp+9JA3zzYtw3MOxYa1gmXAzoYb0YbmrBjXI6LIhgklARybTTXHqIJFm9Pi1o6e70rGXFh2YopUxrO6iWmKwcdFfUVdFxbu87UyFQd4NmL7LiQTvJxDQnEICQVj+FTN82q6hGbuAXQC7u1MymAbQTvmIo2IlmmYufpCTWv5KKioF3Uq/nJeJBRdPYcQEwnU+ikh4cebF0SpQuVsrJt9R0lnBiUJfhVjeEZM9bik55sQet/ncD3ThWs3xv/CqktbD0vYC9HKBPS/IByr4LrNDqoQY6whFcybVk4jM3rolfIFY/LrTtpeWB0l6kBTcy3y+NmcuNhamovd6pPkBJvA+BfJRVachJXEwbgfTBPcUaxpB+/7e6fYDh5A56x3GvRI2toZlOL9nLkQHsAthL8fx2euMuBz1uxbWLAuJJQQBCTAzBV3f7+HcT4JegmMbWkmsDLwCZVt1pgq7WF4h/dw1WTZ3jrOCoyLivtAlumpi6Pvde/yqVZQh vDBfAV6I IYa6rwTLnb0aEk/6TBfYNYQIBzbJlv3GFfR6mBUgFWR2Guh3J/QZGlM5hS86eVCQpeO7As6CSX8TqzRfB5ACpYpwLcaXFWEiPhXeY4wMcGNJRmsUJXvGaJufA4RnBZXNeVSbtIo6PvPWn0h+LgMG/SZTKBNGioAHI8ScrrbGhUgJr5LV67PTNDQYN4PXPXjC/vFFOHEPlxBRz+RTXc3mA+cOpuFQWKTDUy9O7leVFEPQAV1r2wJ2SRnLW0O8LPRHTMbIYJKhViaN7LUe/HNaJfI04FQ== 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 Apr 15, 2025, at 15:32, David Hildenbrand wrote: >=20 > On 15.04.25 09:23, David Hildenbrand wrote: >> On 15.04.25 07:47, Oscar Salvador wrote: >>> commit 4eeec8c89a0c ("mm: move hugetlb specific things in folio to = page[3]") >>> shifted hugetlb specific stuff, and now mapping overlaps = _hugetlb_cgroup field. >>>=20 >>> _hugetlb_cgroup is set to NULL when preparing the hugetlb page in >>> init_new_hugetlb_folio(). >>> For a better picture, this is page->mapping before and after the = comming >>> for the first three tail pages: >>>=20 >>> before: >>> page: fffff51a44358040 0000000000000000 >>> page: fffff51a44358080 0000000000000000 >>> page: fffff51a443580c0 dead000000000400 >>>=20 >>> after: >>> page: fffff1f0042b0040 0000000000000000 >>> page: fffff1f0042b0080 fffff1f0042b0090 >>> page: fffff1f0042b00c0 0000000000000000 >>>=20 >>> Tail#2 has fffff1f0042b0090 because of the _deferred_list = initialization, >>> which was also shifted, but that is not a problem. >>>=20 >>> For HVO, upon restoring that gets copied in some tail pages = (reset_struct_pages) >>> and so those tail pages will not have TAIL_MAPPING set and the check >>> in free_tail_page_prepare() will fail: >>>=20 >>> kernel: BUG: Bad page state in process kworker/0:3 pfn:10ac40 >>> kernel: page does not match folio >>> kernel: page: refcount:0 mapcount:0 mapping:0000000000000000 = index:0x0 pfn:0x10ac40 >>> kernel: flags: 0x17ffffc0000000(node=3D0|zone=3D2|lastcpupid=3D0x1ff= fff) >>> kernel: raw: 0017ffffc0000000 fffff1f0042b0000 0000000000000000 = 0000000000000000 >>> kernel: raw: 0000000000000000 0000000000000000 00000000ffffffff = 0000000000000000 >>> kernel: page dumped because: corrupted mapping in tail page >>>=20 >>> Reset _hugetlb_cgroup to TAIL_MAPPING before restoring so tail pages = have the >>> right value. >> Hi, >> To handle that for ordinary hugtlb alloc/free I added in that patch = in free_tail_page_prepare(): >> case 3: >> /* the third tail page: hugetlb specifics overlap ->mappings */ >> if (IS_ENABLED(CONFIG_HUGETLB_PAGE)) >> break; >> fallthrough; >> default: >> if (page->mapping !=3D TAIL_MAPPING) { >> bad_page(page, "corrupted mapping in tail page"); >> goto out; >> } >> break; >> } >> Now I am confused why that check doesn't catch that? >> Apparently only a problem with HVO? Because I recall testing the = ordinary alloc/free. >=20 > Ah, reading about the HVO hackery in the comment above = NR_RESET_STRUCT_PAGE, might the following fix it? Yes. And the Fixes tag should be Fixes: 4eeec8c89a0c ("mm: move hugetlb specific things in folio to = page[3]") Thanks. >=20 >=20 > diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c > index 9a99dfa3c4958..27245e86df250 100644 > --- a/mm/hugetlb_vmemmap.c > +++ b/mm/hugetlb_vmemmap.c > @@ -238,11 +238,11 @@ static void vmemmap_remap_pte(pte_t *pte, = unsigned long addr, > * struct page, the special metadata (e.g. page->flags or = page->mapping) > * cannot copy to the tail struct page structs. The invalid value will = be > * checked in the free_tail_page_prepare(). In order to avoid the = message > - * of "corrupted mapping in tail page". We need to reset at least 3 = (one > - * head struct page struct and two tail struct page structs) struct = page > + * of "corrupted mapping in tail page". We need to reset at least 4 = (one > + * head struct page struct and three tail struct page structs) struct = page > * structs. > */ > -#define NR_RESET_STRUCT_PAGE 3 > +#define NR_RESET_STRUCT_PAGE 4 > static inline void reset_struct_pages(struct page *start) > { >=20 > --=20 > Cheers, >=20 > David / dhildenb