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 EEAB0C47422 for ; Mon, 29 Jan 2024 06:53:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41ACB6B0081; Mon, 29 Jan 2024 01:53:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C8EA6B0082; Mon, 29 Jan 2024 01:53:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B8806B0083; Mon, 29 Jan 2024 01:53:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1C4A56B0081 for ; Mon, 29 Jan 2024 01:53:39 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 948D61C128B for ; Mon, 29 Jan 2024 06:53:38 +0000 (UTC) X-FDA: 81731432916.18.839F799 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf15.hostedemail.com (Postfix) with ESMTP id B1797A0007 for ; Mon, 29 Jan 2024 06:53:36 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706511217; a=rsa-sha256; cv=none; b=zJ+o4fDdFg/ZjEE4N+KYzk70+jFj1PiSXnoFixSTkvCMUVys9xIsgfdJ1bJt9XKHT+k1Ry llJeSdgsnvFwutOWJcaRxpXDpSuxUQyFGVdZpOhZK9XEHCGXng64/EGoGJ+ZgnMRvjFXVM nAm5+ypq3r1IT3/GkgyirwlVL8+TlcE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706511217; 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; bh=JD+09+VMjptzNj40BUmExZ9Vj507D05YXfeus9+iRIg=; b=PAQVCWfljNB1orD9NQKVe7NanhaKBDKPBHLdJ66UjPFoIl+B/ywKAKSDPLFl8d6GyRrpzi kmIpLbYoP5EGPw8pU+V8bd2qclt86viW2OWyg7HYduK3fYin89wWkZLM8jrefRTkPcF8R9 LIwqDyTzmbM0ltHlLWeRffCsN3wdjr0= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 423F21FB; Sun, 28 Jan 2024 22:54:19 -0800 (PST) Received: from [10.162.42.11] (a077893.blr.arm.com [10.162.42.11]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D518C3F5A1; Sun, 28 Jan 2024 22:53:33 -0800 (PST) Message-ID: Date: Mon, 29 Jan 2024 12:23:30 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test Content-Language: en-US To: "Aneesh Kumar K.V" , linux-mm@kvack.org, akpm@linux-foundation.org Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org References: <20240129060022.68044-1-aneesh.kumar@kernel.org> <1b3c1513-826d-4908-93c3-212a6f1b2d74@arm.com> <504f70be-deca-4f7f-b28c-d1ec2cf5a348@kernel.org> From: Anshuman Khandual In-Reply-To: <504f70be-deca-4f7f-b28c-d1ec2cf5a348@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B1797A0007 X-Stat-Signature: ohpm9a6dmswuzy7bbr6c8hncc4j3at8e X-HE-Tag: 1706511216-260436 X-HE-Meta: U2FsdGVkX18lVgM5+EDabfuRyLp5VwONOv3YpR8NgFwYQycqzrmQ/ki99ugi1SKrSO3XykLkDyZjNrwdhv/9dk/FVktq267L+TiTXin+/TaHdYLVu8nHyBNl2iDokASwzkgO0GP4MO6DTfsE21zEKRS3J0G0Y9Lz/brTcJAorUw6bQuw28NtkKFoD02LvMSBeb5w4PGmYL/4uAEHxHzXww9qPgtMqDDMPRpVlhpXTDPAv1hxb/5D93tPhk6Hk0w056AcJBD3RSb5bCFTowb76gZqXyhqsgFSQhTZurEPcMD1jxGZSlOQh2tV3k8JWLFy+bZbQtI4j8ZjxkbcjoCpBtZrOw8a2jLyqHP3do9CZdydROGXM2QizOJnZp8AMKwyHlhnbsXMwENGRqeag0UluA0Bs3QKN3ndxKZDbDlYhYuRk0XzJNx3N4uOZlhMyFJfvijF0QwIUbF3nVlu6Q7BwkWxZuV27hokyty41E1kz8QcYqHuyowdYjwePP2ofcKryrxLZK8MVxfFVO25PU/lpI3ck2yAQDPcVOltUP1idWbZbbxghYvcpY2DmIXHBMtjOBRaOPAZ83IyvCCHgad4Py0RSVIULsMIfhws8zWfkmiiT1egn1FbSeOoM+I0HfHCzNqhfGRUUSsWEvHTYIliVv8GXNWgyGeFbbv3Ud1ZbmwiPKVc8UTOtiyWZG7QKxrSjcG7aA7ExSbjo2BfTyxmAGh5xmGkzxCaIv7sxebU73r9wOimpVFHUlbf+wKHWdq6/KVFdfvJ6XcNj6QyKuwRuD8pDeY/60iqivs3w3xubmkcRf0JDuFBkeWmZGzi0YWP6Lr+rv06du4Yyykw/ur/yfzUIty1+EVynmbIBvGZK/xzE7ah8kSN16qjqxFcdBICrbGOqMB2bBZu3i1UqktIyHzjgczpY2Ke9u7bypuD0+iUKtkyfHltnlHO2FidBYZDR9c31AJv9xfxLQ45lrg p2ZCcWAY KoMMWr5Kd8gYSL1H7JU+QSRhd5idZ2sRGK1PSu7xHaQZSUF1sG6eFXFbMXfGtAe7/6XK8kV4Vm8AVljYp06w+9zv+jxQsoxnaqLf6W/smppz6murG8CqRBnAlAVdaF3shgTlySKl87XIiFK+ceEKSVS5f9GXZPxb1VO5/TjEcrZXo7okEwUR+qupz4tBiXxQ6inRdU4oxBB84XnJVB+bJiB1fkIsR9NahcWLSCaI3ShQJMDizopclznCs4g== 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 1/29/24 11:56, Aneesh Kumar K.V wrote: > On 1/29/24 11:52 AM, Anshuman Khandual wrote: >> >> >> On 1/29/24 11:30, Aneesh Kumar K.V (IBM) wrote: >>> Architectures like powerpc add debug checks to ensure we find only devmap >>> PUD pte entries. These debug checks are only done with CONFIG_DEBUG_VM. >>> This patch marks the ptes used for PUD advanced test devmap pte entries >>> so that we don't hit on debug checks on architecture like ppc64 as >>> below. >>> >>> WARNING: CPU: 2 PID: 1 at arch/powerpc/mm/book3s64/radix_pgtable.c:1382 radix__pud_hugepage_update+0x38/0x138 >>> .... >>> NIP [c0000000000a7004] radix__pud_hugepage_update+0x38/0x138 >>> LR [c0000000000a77a8] radix__pudp_huge_get_and_clear+0x28/0x60 >>> Call Trace: >>> [c000000004a2f950] [c000000004a2f9a0] 0xc000000004a2f9a0 (unreliable) >>> [c000000004a2f980] [000d34c100000000] 0xd34c100000000 >>> [c000000004a2f9a0] [c00000000206ba98] pud_advanced_tests+0x118/0x334 >>> [c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48 >>> [c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388 >>> >>> Also >>> >>> kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:202! >>> .... >>> >>> NIP [c000000000096510] pudp_huge_get_and_clear_full+0x98/0x174 >>> LR [c00000000206bb34] pud_advanced_tests+0x1b4/0x334 >>> Call Trace: >>> [c000000004a2f950] [000d34c100000000] 0xd34c100000000 (unreliable) >>> [c000000004a2f9a0] [c00000000206bb34] pud_advanced_tests+0x1b4/0x334 >>> [c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48 >>> [c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388 >>> >>> Fixes: 27af67f35631 ("powerpc/book3s64/mm: enable transparent pud hugepage") >>> Signed-off-by: Aneesh Kumar K.V (IBM) >>> --- >>> mm/debug_vm_pgtable.c | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c >>> index 5662e29fe253..65c19025da3d 100644 >>> --- a/mm/debug_vm_pgtable.c >>> +++ b/mm/debug_vm_pgtable.c >>> @@ -362,6 +362,12 @@ static void __init pud_advanced_tests(struct pgtable_debug_args *args) >>> vaddr &= HPAGE_PUD_MASK; >>> >>> pud = pfn_pud(args->pud_pfn, args->page_prot); >>> + /* >>> + * Some architectures have debug checks to make sure >>> + * huge pud mapping are only found with devmap entries >>> + * For now test with only devmap entries. >>> + */ >> Do you see this behaviour to be changed in powerpc anytime soon ? Otherwise >> these pud_mkdevmap() based work arounds, might be required to stick around >> for longer just to prevent powerpc specific triggers. Given PUD transparent >> huge pages i.e HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD are just supported on x86 >> and powerpc platforms, could not this problem be solved in a more uniform >> manner. >> > > > IIUC pud level transparent hugepages are only supported with devmap entries even > on x86. We don't do anonymous pud hugepage. There are some 'pud_trans_huge(orig_pud) || pud_devmap(orig_pud)' checks in core paths i.e in mm/memory.c which might suggest pud_trans_huge() to exist without also being a devmap. I might be missing something here, but on x86 platform following helpers suggest pud_trans_huge() to exist without being a devmap as well. #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD static inline int pud_trans_huge(pud_t pud) { return (pud_val(pud) & (_PAGE_PSE|_PAGE_DEVMAP)) == _PAGE_PSE; } #endif #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD static inline int pud_devmap(pud_t pud) { return !!(pud_val(pud) & _PAGE_DEVMAP); } #else static inline int pud_devmap(pud_t pud) { return 0; } #endif We might need some more clarity on this regarding x86 platform's pud huge page implementation. > >>> + pud = pud_mkdevmap(pud); >>> set_pud_at(args->mm, vaddr, args->pudp, pud); >>> flush_dcache_page(page); >>> pudp_set_wrprotect(args->mm, vaddr, args->pudp); >>> @@ -374,6 +380,7 @@ static void __init pud_advanced_tests(struct pgtable_debug_args *args) >>> WARN_ON(!pud_none(pud)); >>> #endif /* __PAGETABLE_PMD_FOLDED */ >>> pud = pfn_pud(args->pud_pfn, args->page_prot); >>> + pud = pud_mkdevmap(pud); >>> pud = pud_wrprotect(pud); >>> pud = pud_mkclean(pud); >>> set_pud_at(args->mm, vaddr, args->pudp, pud); >>> @@ -391,6 +398,7 @@ static void __init pud_advanced_tests(struct pgtable_debug_args *args) >>> #endif /* __PAGETABLE_PMD_FOLDED */ >>> >>> pud = pfn_pud(args->pud_pfn, args->page_prot); >>> + pud = pud_mkdevmap(pud); >>> pud = pud_mkyoung(pud); >>> set_pud_at(args->mm, vaddr, args->pudp, pud); >>> flush_dcache_page(page); > > > -aneesh >