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 4D1BAC369C2 for ; Wed, 16 Apr 2025 12:42:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B6D36B002A; Wed, 16 Apr 2025 08:41:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 665D26B002B; Wed, 16 Apr 2025 08:41:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 554B06B002C; Wed, 16 Apr 2025 08:41:59 -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 378A16B002A for ; Wed, 16 Apr 2025 08:41:59 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 55961AFDCE for ; Wed, 16 Apr 2025 12:41:59 +0000 (UTC) X-FDA: 83339869158.30.3287D45 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id 341984000D for ; Wed, 16 Apr 2025 12:41:56 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="R3V+osM/"; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744807317; a=rsa-sha256; cv=none; b=ZxzzPhlVws4Bb0OwhjyM6F2f+jOrbrzBgSssYGF/XVHZ/Xq8fCJ/YFFZoYamS9FYra/fTt 18QKVxTuzHyAHswMK4MzFRd3fzNc62IhkmwtQar5HDlxvxApNOmZ2qiCy/Q1JK67UWpfV8 H9Uq/yh3fGOOfSH1Hxb8vuPxQXFqQSk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="R3V+osM/"; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744807317; 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=dwsf2a+LAeqnu6EO1zimyir940pvQziq2A6xZuIziWs=; b=U971pDhxexCLQXQnEBg88Wv0CaGxK/3XqJdDOMw8ZIXOEcEDpobUfA8/8Ex8hiw3934LYI Qm1n2I/TWWi6sBQb60n78xI1Nf3egkCD23gORYdrG5RnckPuAaWpaSO5tKGYoebNvafiHm sKupoBE7JzyhFq17ra1wcuM9qesDdtM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=dwsf2a+LAeqnu6EO1zimyir940pvQziq2A6xZuIziWs=; b=R3V+osM/35c6CJLXnCxO9rd9YF mPiqXkqMd34Lab6bF4vHeTMnnRWggeMyYoYJgcXMTak/W8L4GOX5X+41Bg97VQCBU1VFdyQXzJZf+ Ugzs/XZlXikcENVE6rB6BSLHNi+D0j1U+CEqU5OZRMIG1vqSsk2pgR604F7gPk053S5E5qvfr1O4+ Ntzgzr3UxSgTaqeEo/eL29uL8JfDTkb9bC46fd/NM8j2h3qEYF8uOGnKa+TUqapFI+adgfZrQeFNe CUsVfEreUUwctEGkpq7AZUZBEo5LcLKd+VRU8hwv9tvlBOFHxmDkBUI01aiGO871cGgGA/ju//TQ/ W9IZZ0SA==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1u525P-0000000A7kU-0pso; Wed, 16 Apr 2025 12:41:51 +0000 Date: Wed, 16 Apr 2025 13:41:51 +0100 From: Matthew Wilcox To: Petr =?utf-8?B?VmFuxJtr?= Cc: linux-kernel@vger.kernel.org, Kevin Brodsky , Andrew Morton , linux-mm@kvack.org, x86@kernel.org, xen-devel@lists.xenproject.org, linux-arch@vger.kernel.org Subject: Re: Regression from a9b3c355c2e6 ("asm-generic: pgalloc: provide generic __pgd_{alloc,free}") with CONFIG_DEBUG_VM_PGFLAGS=y and Xen Message-ID: References: <202541612720-Z_-deOZTOztMXHBh-arkamar@atlas.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202541612720-Z_-deOZTOztMXHBh-arkamar@atlas.cz> X-Rspamd-Queue-Id: 341984000D X-Stat-Signature: zzqdafgr9co8wpf8861rwm9psndxfqde X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1744807316-460029 X-HE-Meta: U2FsdGVkX1/TgKjGW4J/VPBuoFTcu2U3uVjSDstFzHGVP+bHI0lQVvP2dn9eBHKmtAixnyHWHMQ9+5dAlvtSZbux3w2NOSdVRlk24rpMuVb1jLdyjDayl9bcDkRD+UgHYxIgxKVAYz/I4Ok426RAsNgf9RZZ6TmGVFOi+AfYKF136y4zn0gFLEwQatz16yMzLDnxEt2LK8V+Bv9wxwVr3sK6YjJz1qnXN+GEQf3dTUQ6tBXJ/kUI3aVqLVb1zetsBZinUNpGiozG4/v7WhrDQmbqzFJZodtP4FS1E6Yrk7Eyv2+yaxhE5dPkpGajnzg+9TxxTj/Mg2GTCDq0Knx545nCS2r73ZIfe2e5+tOSv46KRtB40PmflqAp+XuZtcLB//5SqzP7h93RNrZdI7BsGm+tcwNK3Ua7vPxCJG+aHjA+5O5Ep+rRGouDs+rn24v31/aYPJSEXqaBCkVPR+zBVqwpqPh4fU5rws6gzpMkucZtl5vMw0vxZKiUAdhEi538RZfykCglcspsFPf8WPB7MUjA/HnmMDTp5Ta1hYvwcOVW397f1OOxTvBKhCE7adZ3IOIIzjRDNJD96f2ISFUSCF/G/55AOCXDK4Czl4CIgn3uUH+Hm0rmMVZhqaB8ukEZLZG1JMotgtPj3wIpRDaLnLyeD3mpmZO3dBAODUZc5ISE1mciW+t9g+KH1iiUsmE0pmcrHbBCs6QWukihCYAELzeBvqgt/HUylkPtHxlCxyDJM1t8POs94JsZvK3MQDwwYlSsLYLBm1UYQMOJlJl2d5WVkjmwxsfiaAodtNk33/JCQgdprhOvzJtfJRCVtRA2rXWNcE/4BxeHDt6SQIoYWLGtTAeS/2GqwqjV91XZc4pnaQatty19vv8Ux3xuhHFuufkxYMHUFSMNqqKOud+EYOyMkAacqZGTPvOLvRopLv1NWH2/lEJCnzAHj6QrMd8qJl5whFWRktNtZ97Mozi cPiZHL/C d7qCmDKR6XpCIWveA3/Eii5FtfWThp4E8cs9CzYn8KVZMl6Y58klGWAAQgq+Q8J2UL7B/bidnKhB4IgEgYRpbgENeNHVMoW63ZSXaOCKcVn9F4rkzn5fkzQ4j9kuheTtOtWtgyUUQ3YGPezHpWUBkQg+cvQqhsbdMF+KOT1ma27Xp0D5dCb25/Jz9davMwgFH8Qvx8DqCXic6grO34G7DzJgRtF/s7utAxRDbSfjJylfJTUrsioWCAFrtFPVVg+ArgTUOwgnc7wlfwdtkFIlEOGXOE1Wf6GzHSehe2+oFVRvwuUQ= 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 Wed, Apr 16, 2025 at 02:07:20PM +0200, Petr Vaněk wrote: > I have discovered a regression introduced in commit a9b3c355c2e6 > ("asm-generic: pgalloc: provide generic __pgd_{alloc,free}") [1,2] in > kernel version 6.14. The problem occurs when the x86 kernel is > configured with CONFIG_DEBUG_VM_PGFLAGS=y and is run as a PV Dom0 in Xen > 4.19.1. During the startup, the kernel panics with the error log below. You also have to have CONFIG_MITIGATION_PAGE_TABLE_ISOLATION enabled to hit this problem, otherwise we allocate an order-0 page. > The commit changed PGD allocation path. In the new implementation > _pgd_alloc allocates memory with __pgd_alloc, which indirectly calls > > alloc_pages_noprof(gfp | __GFP_COMP, order); > > This is in contrast to the old behavior, where __get_free_pages was > used, which indirectly called > > alloc_pages_noprof(gfp_mask & ~__GFP_HIGHMEM, order); > > The key difference is that the new allocator can return a compound page. > When xen_pin_page is later called on such a page, it call > TestSetPagePinned function, which internally uses the PF_NO_COMPOUND > macro. This macro enforces VM_BUG_ON_PGFLAGS if PageCompound is true, > triggering the panic when CONFIG_DEBUG_VM_PGFLAGS is enabled. I suspect the right thing to do here is to change the PF_NO_COMPOUND to PF_HEAD. Probably for all of these: /* Xen */ PAGEFLAG(Pinned, pinned, PF_NO_COMPOUND) TESTSCFLAG(Pinned, pinned, PF_NO_COMPOUND) PAGEFLAG(SavePinned, savepinned, PF_NO_COMPOUND); PAGEFLAG(Foreign, foreign, PF_NO_COMPOUND); PAGEFLAG(XenRemapped, xen_remapped, PF_NO_COMPOUND) TESTCLEARFLAG(XenRemapped, xen_remapped, PF_NO_COMPOUND) Could you give that a try?