* [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test
@ 2024-01-29 6:00 Aneesh Kumar K.V (IBM)
2024-01-29 6:22 ` Anshuman Khandual
0 siblings, 1 reply; 7+ messages in thread
From: Aneesh Kumar K.V (IBM) @ 2024-01-29 6:00 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: mpe, linuxppc-dev, Aneesh Kumar K.V (IBM)
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.
+ */
+ 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);
--
2.43.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test
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:22 ` Anshuman Khandual
2024-01-29 6:26 ` Aneesh Kumar K.V
0 siblings, 1 reply; 7+ messages in thread
From: Anshuman Khandual @ 2024-01-29 6:22 UTC (permalink / raw)
To: Aneesh Kumar K.V (IBM), linux-mm, akpm; +Cc: mpe, linuxppc-dev
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.
> + 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);
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test
2024-01-29 6:22 ` Anshuman Khandual
@ 2024-01-29 6:26 ` Aneesh Kumar K.V
2024-01-29 6:53 ` Anshuman Khandual
0 siblings, 1 reply; 7+ messages in thread
From: Aneesh Kumar K.V @ 2024-01-29 6:26 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm, akpm; +Cc: mpe, linuxppc-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test
2024-01-29 6:26 ` Aneesh Kumar K.V
@ 2024-01-29 6:53 ` Anshuman Khandual
2024-01-29 8:13 ` Aneesh Kumar K.V
0 siblings, 1 reply; 7+ messages in thread
From: Anshuman Khandual @ 2024-01-29 6:53 UTC (permalink / raw)
To: Aneesh Kumar K.V, linux-mm, akpm; +Cc: mpe, linuxppc-dev
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) <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.
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test
2024-01-29 6:53 ` Anshuman Khandual
@ 2024-01-29 8:13 ` Aneesh Kumar K.V
2024-02-20 2:46 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Aneesh Kumar K.V @ 2024-01-29 8:13 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm, akpm; +Cc: mpe, linuxppc-dev
On 1/29/24 12:23 PM, Anshuman Khandual wrote:
>
>
> 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) <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.
>
> 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.
>
static vm_fault_t create_huge_pud(struct vm_fault *vmf)
{
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && \
defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
struct vm_area_struct *vma = vmf->vma;
/* No support for anonymous transparent PUD pages yet */
if (vma_is_anonymous(vma))
return VM_FAULT_FALLBACK;
if (vma->vm_ops->huge_fault)
return vma->vm_ops->huge_fault(vmf, PUD_ORDER);
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
return VM_FAULT_FALLBACK;
}
-aneesh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test
2024-01-29 8:13 ` Aneesh Kumar K.V
@ 2024-02-20 2:46 ` Andrew Morton
2024-02-20 3:33 ` Aneesh Kumar K.V
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2024-02-20 2:46 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Anshuman Khandual, linux-mm, mpe, linuxppc-dev
On Mon, 29 Jan 2024 13:43:39 +0530 "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
> > 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.
> >
>
> static vm_fault_t create_huge_pud(struct vm_fault *vmf)
> {
> #if defined(CONFIG_TRANSPARENT_HUGEPAGE) && \
> defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
> struct vm_area_struct *vma = vmf->vma;
> /* No support for anonymous transparent PUD pages yet */
> if (vma_is_anonymous(vma))
> return VM_FAULT_FALLBACK;
> if (vma->vm_ops->huge_fault)
> return vma->vm_ops->huge_fault(vmf, PUD_ORDER);
> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> return VM_FAULT_FALLBACK;
> }
cryptic reply, unreplied to.
What's the thinking here? Should we proceed with the patch as-is, or
are changes needed?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] mm/debug_vm_pgtable: Fix BUG_ON with pud advanced test
2024-02-20 2:46 ` Andrew Morton
@ 2024-02-20 3:33 ` Aneesh Kumar K.V
0 siblings, 0 replies; 7+ messages in thread
From: Aneesh Kumar K.V @ 2024-02-20 3:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: Anshuman Khandual, linux-mm, mpe, linuxppc-dev
On 2/20/24 8:16 AM, Andrew Morton wrote:
> On Mon, 29 Jan 2024 13:43:39 +0530 "Aneesh Kumar K.V" <aneesh.kumar@kernel.org> wrote:
>
>>> 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.
>>>
>>
>> static vm_fault_t create_huge_pud(struct vm_fault *vmf)
>> {
>> #if defined(CONFIG_TRANSPARENT_HUGEPAGE) && \
>> defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
>> struct vm_area_struct *vma = vmf->vma;
>> /* No support for anonymous transparent PUD pages yet */
>> if (vma_is_anonymous(vma))
>> return VM_FAULT_FALLBACK;
>> if (vma->vm_ops->huge_fault)
>> return vma->vm_ops->huge_fault(vmf, PUD_ORDER);
>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>> return VM_FAULT_FALLBACK;
>> }
>
> cryptic reply, unreplied to.
>
> What's the thinking here? Should we proceed with the patch as-is, or
> are changes needed?
>
Sorry for the confusion. What i wanted to update with the code was to reiterate
that no architectures currently does anonymous pud hugepage. So restricting
debug_vm_pgtable pud hugepage test to devmap pte entries should be ok w.r.t
these tests.
-aneesh
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-02-20 3:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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:22 ` Anshuman Khandual
2024-01-29 6:26 ` Aneesh Kumar K.V
2024-01-29 6:53 ` Anshuman Khandual
2024-01-29 8:13 ` Aneesh Kumar K.V
2024-02-20 2:46 ` Andrew Morton
2024-02-20 3:33 ` Aneesh Kumar K.V
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).