From: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
linux-mm@kvack.org, akpm@linux-foundation.org
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test
Date: Mon, 29 Jan 2024 11:56:49 +0530 [thread overview]
Message-ID: <504f70be-deca-4f7f-b28c-d1ec2cf5a348@kernel.org> (raw)
In-Reply-To: <1b3c1513-826d-4908-93c3-212a6f1b2d74@arm.com>
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) <aneesh.kumar@kernel.org>
>> ---
>> 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.
>> + 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
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
linux-mm@kvack.org, akpm@linux-foundation.org
Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test
Date: Mon, 29 Jan 2024 11:56:49 +0530 [thread overview]
Message-ID: <504f70be-deca-4f7f-b28c-d1ec2cf5a348@kernel.org> (raw)
In-Reply-To: <1b3c1513-826d-4908-93c3-212a6f1b2d74@arm.com>
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) <aneesh.kumar@kernel.org>
>> ---
>> 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.
>> + 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
next prev parent reply other threads:[~2024-01-29 6:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 6:00 [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test Aneesh Kumar K.V (IBM)
2024-01-29 6:00 ` Aneesh Kumar K.V (IBM)
2024-01-29 6:22 ` Anshuman Khandual
2024-01-29 6:22 ` Anshuman Khandual
2024-01-29 6:26 ` Aneesh Kumar K.V [this message]
2024-01-29 6:26 ` Aneesh Kumar K.V
2024-01-29 6:53 ` Anshuman Khandual
2024-01-29 6:53 ` Anshuman Khandual
2024-01-29 8:13 ` Aneesh Kumar K.V
2024-01-29 8:13 ` Aneesh Kumar K.V
2024-02-20 2:46 ` Andrew Morton
2024-02-20 2:46 ` Andrew Morton
2024-02-20 3:33 ` Aneesh Kumar K.V
2024-02-20 3:33 ` Aneesh Kumar K.V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=504f70be-deca-4f7f-b28c-d1ec2cf5a348@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.