mm/debug_vm_pgtable: fix alignment for pmd/pud_advanced_tests()
Subsystems (4)
cover mm/debug_vm_pgtable: fix alignment for pmd/pud_advanced_tests()
We sometimes see a "BUG task_struct (Not tainted): Padding overwritten" on s390, directly after running debug_vm_pgtable. This is because of wrong vaddr alignment in pmd/pud_advanced_tests(), leading to memory corruption at least on s390, see patch description.
At first glance, other architectures do not seem to care about vaddr in their xxx_get_and_clear() implementations, so they should not be affected. One exception is sparc, where the addr is passed over to some tlb_batch code, but I'm not sure what implication the wrongly aligned vaddr would have in this case.
Also adding linux-arch, just to make sure.
Gerald Schaefer (1):
mm/debug_vm_pgtable: fix alignment for pmd/pud_advanced_tests()
mm/debug_vm_pgtable.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Signature · 1 line
2.25.1
PATCH 1/1 mm/debug_vm_pgtable: fix alignment for pmd/pud_advanced_tests()
In pmd/pud_advanced_tests(), the vaddr is aligned up to the next pmd/pud entry, and so it does not match the given pmdp/pudp and (aligned down) pfn any more.
For s390, this results in memory corruption, because the IDTE instruction used e.g. in xxx_get_and_clear() will take the vaddr for some calculations, in combination with the given pmdp. It will then end up with a wrong table origin, ending on ...ff8, and some of those wrongly set low-order bits will also select a wrong pagetable level for the index addition. IDTE could therefore invalidate (or 0x20) something outside of the page tables, depending on the wrongly picked index, which in turn depends on the random vaddr.
As result, we sometimes see "BUG task_struct (Not tainted): Padding overwritten" on s390, where one 0x5a padding value got overwritten with 0x7a.
Fix this by aligning down, similar to how the pmd/pud_aligned pfns are calculated.
--- mm/debug_vm_pgtable.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
mm/debug_vm_pgtable.c +2 -2
@@ -193,7 +193,7 @@ static void __init pmd_advanced_tests(struct mm_struct *mm,pr_debug ("Validating PMD advanced\n" );/* Align the address wrt HPAGE_PMD_SIZE */ - vaddr = (vaddr &HPAGE_PMD_MASK ) +HPAGE_PMD_SIZE ; + vaddr &=HPAGE_PMD_MASK ;pgtable_trans_huge_deposit (mm, pmdp, pgtable);
@@ -318,7 +318,7 @@ static void __init pud_advanced_tests(struct mm_struct *mm,pr_debug ("Validating PUD advanced\n" );/* Align the address wrt HPAGE_PUD_SIZE */ - vaddr = (vaddr &HPAGE_PUD_MASK ) +HPAGE_PUD_SIZE ; + vaddr &=HPAGE_PUD_MASK ; pud =pfn_pud (pfn, prot);set_pud_at (mm, vaddr, pudp, pud);
Signature · 1 line
2.25.1
Quoted 17 lines · Gerald Schaefer
In pmd/pud_advanced_tests(), the vaddr is aligned up to the next pmd/pud entry, and so it does not match the given pmdp/pudp and (aligned down) pfn any more.
For s390, this results in memory corruption, because the IDTE instruction used e.g. in
xxx_get_and_clear()will take the vaddr for some calculations, in combination with the given pmdp. It will then end up with a wrong table origin, ending on ...ff8, and some of those wrongly set low-order bits will also select a wrong pagetable level for the index addition. IDTE could therefore invalidate (or0x20) something outside of the page tables, depending on the wrongly picked index, which in turn depends on the random vaddr.As result, we sometimes see "BUG
task_struct(Not tainted): Padding overwritten" on s390, where one0x5apadding value got overwritten with0x7a.
Quoted 6 lines
Fix this by aligning down, similar to how the pmd/pud_aligned pfns are calculated.
Fixes a5c3b9ffb0f40 ("mm/debug_vm_pgtable: add tests validating advanced arch page table helpers")Cc <[email protected]> # v5.9+Signed-off-by Gerald Schaefer <[email protected]>
Did not see any problem on arm64 or x86, builds okay across all supported platforms. It would be great, if folks could test this on remaining platforms i.e arc, riscv etc.
+ Vineet Gupta <[email protected]>
+ Palmer Dabbelt <[email protected]>
+ Paul Walmsley <[email protected]>
Quoted 27 lines
--- mm/debug_vm_pgtable.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)mm/debug_vm_pgtable.c +2
-2@@ -193,7 +193,7 @@ static void __init pmd_advanced_tests(struct mm_struct *mm,pr_debug ("Validating PMD advanced\n" );/* Align the address wrt HPAGE_PMD_SIZE */ - vaddr = (vaddr &HPAGE_PMD_MASK ) +HPAGE_PMD_SIZE ; + vaddr &=HPAGE_PMD_MASK ;pgtable_trans_huge_deposit (mm, pmdp, pgtable);@@ -318,7 +318,7 @@ static void __init pud_advanced_tests(struct mm_struct *mm,pr_debug ("Validating PUD advanced\n" );/* Align the address wrt HPAGE_PUD_SIZE */ - vaddr = (vaddr &HPAGE_PUD_MASK ) +HPAGE_PUD_SIZE ; + vaddr &=HPAGE_PUD_MASK ; pud =pfn_pud (pfn, prot);set_pud_at (mm, vaddr, pudp, pud);
Quoted 18 lines · Gerald Schaefer
In pmd/pud_advanced_tests(), the vaddr is aligned up to the next pmd/pud entry, and so it does not match the given pmdp/pudp and (aligned down) pfn any more.
For s390, this results in memory corruption, because the IDTE instruction used e.g. in
xxx_get_and_clear()will take the vaddr for some calculations, in combination with the given pmdp. It will then end up with a wrong table origin, ending on ...ff8, and some of those wrongly set low-order bits will also select a wrong pagetable level for the index addition. IDTE could therefore invalidate (or0x20) something outside of the page tables, depending on the wrongly picked index, which in turn depends on the random vaddr.As result, we sometimes see "BUG
task_struct(Not tainted): Padding overwritten" on s390, where one0x5apadding value got overwritten with0x7a.
Quoted 6 lines
Fix this by aligning down, similar to how the pmd/pud_aligned pfns are calculated.
Fixes a5c3b9ffb0f40 ("mm/debug_vm_pgtable: add tests validating advanced arch page table helpers")Cc <[email protected]> # v5.9+Signed-off-by Gerald Schaefer <[email protected]>
boot tested on sparc64 with quick run of stress-ng ( --class memory --sequential -1 --timeout 10s -v --pathological --oomable --metrics-brief )
stress-ng: debug: [371408] system: Linux ttip 5.13.0-rc3-00043-gad9f25d33860-dirty #218 SMP Wed May 26 11:55:54 MSK 2021 sparc64
Quoted 27 lines · Anatoly Pugachev
Quoted 18 lines · Gerald Schaefer
In pmd/pud_advanced_tests(), the vaddr is aligned up to the next pmd/pud entry, and so it does not match the given pmdp/pudp and (aligned down) pfn any more.
For s390, this results in memory corruption, because the IDTE instruction used e.g. in
xxx_get_and_clear()will take the vaddr for some calculations, in combination with the given pmdp. It will then end up with a wrong table origin, ending on ...ff8, and some of those wrongly set low-order bits will also select a wrong pagetable level for the index addition. IDTE could therefore invalidate (or0x20) something outside of the page tables, depending on the wrongly picked index, which in turn depends on the random vaddr.As result, we sometimes see "BUG
task_struct(Not tainted): Padding overwritten" on s390, where one0x5apadding value got overwritten with0x7a.Quoted 6 lines
Fix this by aligning down, similar to how the pmd/pud_aligned pfns are calculated.
Fixes a5c3b9ffb0f40 ("mm/debug_vm_pgtable: add tests validating advanced arch page table helpers")Cc <[email protected]> # v5.9+Signed-off-by Gerald Schaefer <[email protected]>
Quoted 9 lines
boot tested on sparc64 with quick run of stress-ng ( --class memory --sequential -1 --timeout 10s -v --pathological --oomable --metrics-brief )
stress-ng: debug: [371408] system: Linux ttip 5.13.0-rc3-00043-gad9f25d33860-dirty #218 SMP Wed May 26 11:55:54 MSK 2021 sparc64Tested-by Anatoly Pugachev <[email protected]>
spac64 does not enable ARCH_HAS_DEBUG_VM_PGTABLE, did you enable it before running the test ? Did the entire test debug_vm_pgtable() run successfully on sparc64 ?
Quoted 3 lines · Anshuman Khandual
spac64 does not enable
ARCH_HAS_DEBUG_VM_PGTABLE, did you enable it before running the test ? Did the entire testdebug_vm_pgtable()run successfully on sparc64 ?
Ahh.. Sorry for the noise then... Thought thatCONFIG_TRANSPARENT_HUGEPAGE would be enough...
Quoted 7 lines · Gerald Schaefer
We sometimes see a "BUG
task_struct(Not tainted): Padding overwritten" on s390, directly after runningdebug_vm_pgtable. This is because of wrong vaddr alignment in pmd/pud_advanced_tests(), leading to memory corruption at least on s390, see patch description.At first glance, other architectures do not seem to care about vaddr in their
xxx_get_and_clear()implementations, so they should not be affected.
IIRC, alignment (regardless up or down) is the only requirement on certain platforms. Probably it should not affect other platforms as this change just aligns the virtual address down.
Quoted 5 lines
One exception is sparc, where the addr is passed over to some
tlb_batchcode, but I'm not sure what implication the wrongly aligned vaddr would have in this case.Also adding linux-arch, just to make sure.
Right. Not sure if this test gets to run on sparc platform for not being currently supported. But we could take a look if there are any reported problems because of vaddr.
Quoted 7 lines
Gerald Schaefer (1):
mm/debug_vm_pgtable: fix alignment for pmd/pud_advanced_tests()mm/debug_vm_pgtable.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)