* [PATCH] sparc64: fix hugetlb for sun4u
@ 2025-07-16 1:24 Anthony Yznaga
2025-07-16 6:18 ` John Paul Adrian Glaubitz
` (3 more replies)
0 siblings, 4 replies; 26+ messages in thread
From: Anthony Yznaga @ 2025-07-16 1:24 UTC (permalink / raw)
To: sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
An attempt to exercise sparc hugetlb code in a sun4u-based guest
running under qemu results in the guest hanging due to being stuck
in a trap loop. This is due to invalid hugetlb TTEs being installed
that do not have the expected _PAGE_PMD_HUGE and page size bits set.
Although the breakage has gone apparently unnoticed for several years,
fix it now so there is the option to exercise sparc hugetlb code under
qemu. This can be useful because sun4v support in qemu does not support
linux guests currently and sun4v-based hardware resources may not be
readily available.
Fix tested with a 6.15.2 and 6.16-rc6 kernels by running libhugetlbfs
tests on a qemu guest running Debian 13.
Fixes: c7d9f77d33a7 ("sparc64: Multi-page size support")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Yznaga <anthony.yznaga@oracle.com>
---
arch/sparc/mm/hugetlbpage.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
index 80504148d8a5..2048b5c42ca8 100644
--- a/arch/sparc/mm/hugetlbpage.c
+++ b/arch/sparc/mm/hugetlbpage.c
@@ -22,6 +22,26 @@
static pte_t sun4u_hugepage_shift_to_tte(pte_t entry, unsigned int shift)
{
+ unsigned long hugepage_size = _PAGE_SZ4MB_4U;
+
+ pte_val(entry) = pte_val(entry) & ~_PAGE_SZALL_4U;
+
+ switch (shift) {
+ case HPAGE_256MB_SHIFT:
+ hugepage_size = _PAGE_SZ256MB_4U;
+ pte_val(entry) |= _PAGE_PMD_HUGE;
+ break;
+ case HPAGE_SHIFT:
+ pte_val(entry) |= _PAGE_PMD_HUGE;
+ break;
+ case HPAGE_64K_SHIFT:
+ hugepage_size = _PAGE_SZ64K_4U;
+ break;
+ default:
+ WARN_ONCE(1, "unsupported hugepage shift=%u\n", shift);
+ }
+
+ pte_val(entry) = pte_val(entry) | hugepage_size;
return entry;
}
--
2.47.1
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-07-16 1:24 [PATCH] sparc64: fix hugetlb for sun4u Anthony Yznaga
@ 2025-07-16 6:18 ` John Paul Adrian Glaubitz
2025-07-16 8:41 ` John Paul Adrian Glaubitz
2025-07-25 5:59 ` John Paul Adrian Glaubitz
` (2 subsequent siblings)
3 siblings, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-07-16 6:18 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Tue, 2025-07-15 at 18:24 -0700, Anthony Yznaga wrote:
> An attempt to exercise sparc hugetlb code in a sun4u-based guest
> running under qemu results in the guest hanging due to being stuck
> in a trap loop. This is due to invalid hugetlb TTEs being installed
> that do not have the expected _PAGE_PMD_HUGE and page size bits set.
> Although the breakage has gone apparently unnoticed for several years,
> fix it now so there is the option to exercise sparc hugetlb code under
> qemu. This can be useful because sun4v support in qemu does not support
> linux guests currently and sun4v-based hardware resources may not be
> readily available.
It has actually been observed for a long time that newer kernels are
unstable on sun4u while there are no stability issues on sun4v.
I'm not sure though whether the Debian kernel enables hugetlb by default.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-07-16 6:18 ` John Paul Adrian Glaubitz
@ 2025-07-16 8:41 ` John Paul Adrian Glaubitz
2025-07-16 16:47 ` Anthony Yznaga
2025-07-24 10:52 ` John Paul Adrian Glaubitz
0 siblings, 2 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-07-16 8:41 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Wed, 2025-07-16 at 08:18 +0200, John Paul Adrian Glaubitz wrote:
> On Tue, 2025-07-15 at 18:24 -0700, Anthony Yznaga wrote:
> > An attempt to exercise sparc hugetlb code in a sun4u-based guest
> > running under qemu results in the guest hanging due to being stuck
> > in a trap loop. This is due to invalid hugetlb TTEs being installed
> > that do not have the expected _PAGE_PMD_HUGE and page size bits set.
> > Although the breakage has gone apparently unnoticed for several years,
> > fix it now so there is the option to exercise sparc hugetlb code under
> > qemu. This can be useful because sun4v support in qemu does not support
> > linux guests currently and sun4v-based hardware resources may not be
> > readily available.
>
> It has actually been observed for a long time that newer kernels are
> unstable on sun4u while there are no stability issues on sun4v.
Just as a heads-up: I'm currently building a Debian kernel with this patch
and see if this fixes the stability issues we're seeing on UltraSPARC machines.
> I'm not sure though whether the Debian kernel enables hugetlb by default.
We do.
I'll report back.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-07-16 8:41 ` John Paul Adrian Glaubitz
@ 2025-07-16 16:47 ` Anthony Yznaga
2025-07-24 10:52 ` John Paul Adrian Glaubitz
1 sibling, 0 replies; 26+ messages in thread
From: Anthony Yznaga @ 2025-07-16 16:47 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
On 7/16/25 1:41 AM, John Paul Adrian Glaubitz wrote:
> Hi Anthony,
>
> On Wed, 2025-07-16 at 08:18 +0200, John Paul Adrian Glaubitz wrote:
>> On Tue, 2025-07-15 at 18:24 -0700, Anthony Yznaga wrote:
>>> An attempt to exercise sparc hugetlb code in a sun4u-based guest
>>> running under qemu results in the guest hanging due to being stuck
>>> in a trap loop. This is due to invalid hugetlb TTEs being installed
>>> that do not have the expected _PAGE_PMD_HUGE and page size bits set.
>>> Although the breakage has gone apparently unnoticed for several years,
>>> fix it now so there is the option to exercise sparc hugetlb code under
>>> qemu. This can be useful because sun4v support in qemu does not support
>>> linux guests currently and sun4v-based hardware resources may not be
>>> readily available.
>>
>> It has actually been observed for a long time that newer kernels are
>> unstable on sun4u while there are no stability issues on sun4v.
>
> Just as a heads-up: I'm currently building a Debian kernel with this patch
> and see if this fixes the stability issues we're seeing on UltraSPARC machines.
If it's the use of hugetlb that is causing problems then this patch
should help.
>
>> I'm not sure though whether the Debian kernel enables hugetlb by default.
>
> We do.
>
> I'll report back.
>
> Adrian
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-07-16 8:41 ` John Paul Adrian Glaubitz
2025-07-16 16:47 ` Anthony Yznaga
@ 2025-07-24 10:52 ` John Paul Adrian Glaubitz
1 sibling, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-07-24 10:52 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Wed, 2025-07-16 at 10:41 +0200, John Paul Adrian Glaubitz wrote:
> > It has actually been observed for a long time that newer kernels are
> > unstable on sun4u while there are no stability issues on sun4v.
>
> Just as a heads-up: I'm currently building a Debian kernel with this patch
> and see if this fixes the stability issues we're seeing on UltraSPARC machines.
I'm still testing here. There are some still some issues with newer kernels on
sun4u with the code crashing in ext4, but I'm going to perform stresstests with
a patch 4.19.325 kernel now.
I will also try to bisect the other crash regression in sun4u that was introduced
sometime between 4.19.x and 6.x.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-07-16 1:24 [PATCH] sparc64: fix hugetlb for sun4u Anthony Yznaga
2025-07-16 6:18 ` John Paul Adrian Glaubitz
@ 2025-07-25 5:59 ` John Paul Adrian Glaubitz
2025-07-25 20:46 ` John Paul Adrian Glaubitz
2025-08-08 21:31 ` John Paul Adrian Glaubitz
3 siblings, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-07-25 5:59 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Tue, 2025-07-15 at 18:24 -0700, Anthony Yznaga wrote:
> An attempt to exercise sparc hugetlb code in a sun4u-based guest
> running under qemu results in the guest hanging due to being stuck
> in a trap loop. This is due to invalid hugetlb TTEs being installed
> that do not have the expected _PAGE_PMD_HUGE and page size bits set.
> Although the breakage has gone apparently unnoticed for several years,
> fix it now so there is the option to exercise sparc hugetlb code under
> qemu. This can be useful because sun4v support in qemu does not support
> linux guests currently and sun4v-based hardware resources may not be
> readily available.
>
> Fix tested with a 6.15.2 and 6.16-rc6 kernels by running libhugetlbfs
> tests on a qemu guest running Debian 13.
>
> Fixes: c7d9f77d33a7 ("sparc64: Multi-page size support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Anthony Yznaga <anthony.yznaga@oracle.com>
> ---
> arch/sparc/mm/hugetlbpage.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
> index 80504148d8a5..2048b5c42ca8 100644
> --- a/arch/sparc/mm/hugetlbpage.c
> +++ b/arch/sparc/mm/hugetlbpage.c
> @@ -22,6 +22,26 @@
>
> static pte_t sun4u_hugepage_shift_to_tte(pte_t entry, unsigned int shift)
> {
> + unsigned long hugepage_size = _PAGE_SZ4MB_4U;
> +
> + pte_val(entry) = pte_val(entry) & ~_PAGE_SZALL_4U;
> +
> + switch (shift) {
> + case HPAGE_256MB_SHIFT:
> + hugepage_size = _PAGE_SZ256MB_4U;
> + pte_val(entry) |= _PAGE_PMD_HUGE;
> + break;
> + case HPAGE_SHIFT:
> + pte_val(entry) |= _PAGE_PMD_HUGE;
> + break;
> + case HPAGE_64K_SHIFT:
> + hugepage_size = _PAGE_SZ64K_4U;
> + break;
> + default:
> + WARN_ONCE(1, "unsupported hugepage shift=%u\n", shift);
> + }
> +
> + pte_val(entry) = pte_val(entry) | hugepage_size;
> return entry;
> }
>
Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-07-16 1:24 [PATCH] sparc64: fix hugetlb for sun4u Anthony Yznaga
2025-07-16 6:18 ` John Paul Adrian Glaubitz
2025-07-25 5:59 ` John Paul Adrian Glaubitz
@ 2025-07-25 20:46 ` John Paul Adrian Glaubitz
2025-07-25 21:09 ` John Paul Adrian Glaubitz
2025-08-08 21:31 ` John Paul Adrian Glaubitz
3 siblings, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-07-25 20:46 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Tue, 2025-07-15 at 18:24 -0700, Anthony Yznaga wrote:
> An attempt to exercise sparc hugetlb code in a sun4u-based guest
> running under qemu results in the guest hanging due to being stuck
> in a trap loop. This is due to invalid hugetlb TTEs being installed
> that do not have the expected _PAGE_PMD_HUGE and page size bits set.
> Although the breakage has gone apparently unnoticed for several years,
> fix it now so there is the option to exercise sparc hugetlb code under
> qemu. This can be useful because sun4v support in qemu does not support
> linux guests currently and sun4v-based hardware resources may not be
> readily available.
>
> Fix tested with a 6.15.2 and 6.16-rc6 kernels by running libhugetlbfs
> tests on a qemu guest running Debian 13.
>
> Fixes: c7d9f77d33a7 ("sparc64: Multi-page size support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Anthony Yznaga <anthony.yznaga@oracle.com>
> ---
> arch/sparc/mm/hugetlbpage.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
> index 80504148d8a5..2048b5c42ca8 100644
> --- a/arch/sparc/mm/hugetlbpage.c
> +++ b/arch/sparc/mm/hugetlbpage.c
> @@ -22,6 +22,26 @@
>
> static pte_t sun4u_hugepage_shift_to_tte(pte_t entry, unsigned int shift)
> {
> + unsigned long hugepage_size = _PAGE_SZ4MB_4U;
> +
> + pte_val(entry) = pte_val(entry) & ~_PAGE_SZALL_4U;
> +
> + switch (shift) {
> + case HPAGE_256MB_SHIFT:
> + hugepage_size = _PAGE_SZ256MB_4U;
> + pte_val(entry) |= _PAGE_PMD_HUGE;
> + break;
> + case HPAGE_SHIFT:
> + pte_val(entry) |= _PAGE_PMD_HUGE;
> + break;
> + case HPAGE_64K_SHIFT:
> + hugepage_size = _PAGE_SZ64K_4U;
> + break;
> + default:
> + WARN_ONCE(1, "unsupported hugepage shift=%u\n", shift);
> + }
> +
> + pte_val(entry) = pte_val(entry) | hugepage_size;
> return entry;
> }
>
I have compiled a 4.19.325 kernel with the patched applied on top and booted
that kernel onto an UltraSPARC IIIi machine. I cannot test a current kernel
at the moment as newer kernels do not run stable on sun4u machines at the
moment.
I will try to bisect this problem within the next days. Currently, I don't have
serial access to this machine, so I cannot easily reboot it when the kernel
crashes but this should be resolved within the next days.
Here is the output from /proc/cpuinfo:
root@raverin:/home/glaubitz/libhugetlbfs# cat /proc/cpuinfo
cpu : TI UltraSparc IIIi (Jalapeno)
fpu : UltraSparc IIIi integrated FPU
pmu : ultra3i
prom : OBP 4.22.33 2007/06/18 12:45
type : sun4u
ncpus probed : 1
ncpus active : 1
D$ parity tl1 : 0
I$ parity tl1 : 0
Cpu0ClkTck : 000000005995f5c0
cpucaps : flush,stbar,swap,muldiv,v9,ultra3,mul32,div32,v8plus,vis,vis2
MMU Type : Cheetah+
MMU PGSZs : 8K,64K,512K,4MB
root@raverin:/home/glaubitz/libhugetlbfs#
I allocated 25 huge pages:
root@raverin:/home/glaubitz/libhugetlbfs# echo 25 > /proc/sys/vm/nr_hugepages
root@raverin:/home/glaubitz/libhugetlbfs# hugeadm --pool-list
Size Minimum Current Maximum Default
65536 0 0 0
8388608 25 25 25 *
268435456 0 0 0
2147483648 0 0 0
root@raverin:/home/glaubitz/libhugetlbfs#
The testsuite then passed without any problems:
root@raverin:/home/glaubitz/libhugetlbfs# make check
PASS
zero_filesize_segment (8M: 64):
test_root (8M: 64): PASS
meminfo_nohuge (8M: 64): PASS
gethugepagesize (8M: 64): PASS
gethugepagesizes (8M: 64): PASS
HUGETLB_VERBOSE=1 empty_mounts (8M: 64): PASS
HUGETLB_VERBOSE=1 large_mounts (8M: 64): PASS
find_path (8M: 64): PASS
unlinked_fd (8M: 64): PASS
readback (8M: 64): PASS
truncate (8M: 64): PASS
shared (8M: 64): PASS
mprotect (8M: 64): PASS
mlock (8M: 64): PASS
misalign (8M: 64): PASS
fallocate_basic.sh (8M: 64): PASS
fallocate_align.sh (8M: 64): PASS
ptrace-write-hugepage (8M: 64): PASS
icache-hygiene (8M: 64): PASS
slbpacaflush (8M: 64): Bad configuration: Atleast online 2 cpus are required
straddle_4GB_static (8M: 64): PASS
huge_at_4GB_normal_below_static (8M: 64): FAIL Wrong address with MAP_FIXED normal
huge_below_4GB_normal_above_static (8M: 64): PASS
map_high_truncate_2 (8M: 64): PASS
misaligned_offset (8M: 64): PASS (inconclusive)
truncate_above_4GB (8M: 64): PASS
brk_near_huge (8M: 64): Fatal glibc error: malloc.c:2601 (sysmalloc): assertion failed:
task-size-overrun (8M: 64): PASS
stack_grow_into_huge (8M: 64): PASS
corrupt-by-cow-opt (8M: 64): PASS
noresv-preserve-resv-page (8M: 64): PASS
noresv-regarded-as-resv (8M: 64): PASS
readahead_reserve.sh (8M: 64): PASS
madvise_reserve.sh (8M: 64): PASS
fadvise_reserve.sh (8M: 64): PASS
mremap-expand-slice-collision.sh (8M: 64): PASS
mremap-fixed-normal-near-huge.sh (8M: 64): PASS
mremap-fixed-huge-near-normal.sh (8M: 64): PASS
set shmmax limit to 67108864
shm-perms (8M: 64): PASS
private (8M: 64): PASS
fork-cow (8M: 64): PASS
direct (8M: 64): Bad configuration: Failed to open direct-IO file: Invalid argument
malloc (8M: 64): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (8M: 64): SKIPPED
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes HUGETLB_RESTRICT_EXE=unknown:none malloc (8M: 64): SKIPPED
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes HUGETLB_RESTRICT_EXE=unknown:malloc malloc (8M: 64): SKIPPED
malloc_manysmall (8M: 64): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (8M: 64): SKIPPED
GLIBC_TUNABLES=glibc.malloc.tcache_count=0 heapshrink (8M: 64): PASS
GLIBC_TUNABLES=glibc.malloc.tcache_count=0 LD_PRELOAD=libheapshrink.so heapshrink (8M: 64): PASS
GLIBC_TUNABLES=glibc.malloc.tcache_count=0 LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes heapshrink (8M: 64): SKIPPED
GLIBC_TUNABLES=glibc.malloc.tcache_count=0 LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes heapshrink (8M: 64): SKIPPED
GLIBC_TUNABLES=glibc.malloc.tcache_count=0 LD_PRELOAD=libheapshrink.so HUGETLB_MORECORE=yes HUGETLB_MORECORE_SHRINK=yes heapshrink (8M: 64): SKIPPED
GLIBC_TUNABLES=glibc.malloc.tcache_count=0 LD_PRELOAD=libhugetlbfs.so libheapshrink.so HUGETLB_MORECORE=yes HUGETLB_MORECORE_SHRINK=yes heapshrink (8M: 64): SKIPPED
HUGETLB_VERBOSE=1 HUGETLB_MORECORE=yes heap-overflow (8M: 64): SKIPPED
HUGETLB_VERBOSE=0 linkhuge_nofd (8M: 64):
LD_PRELOAD=libhugetlbfs.so HUGETLB_VERBOSE=0 linkhuge_nofd (8M: 64):
HUGETLB_VERBOSE=0 xB.linkhuge_nofd (8M: 64):
HUGETLB_VERBOSE=0 xBDT.linkhuge_nofd (8M: 64):
HUGETLB_MINIMAL_COPY=no HUGETLB_VERBOSE=0 xB.linkhuge_nofd (8M: 64):
HUGETLB_MINIMAL_COPY=no HUGETLB_VERBOSE=0 xBDT.linkhuge_nofd (8M: 64):
HUGETLB_ELFMAP=no HUGETLB_VERBOSE=0 xB.linkhuge_nofd (8M: 64):
HUGETLB_ELFMAP=no HUGETLB_VERBOSE=0 xBDT.linkhuge_nofd (8M: 64):
linkhuge (8M: 64):
LD_PRELOAD=libhugetlbfs.so linkhuge (8M: 64):
xB.linkhuge (8M: 64):
xBDT.linkhuge (8M: 64):
HUGETLB_MINIMAL_COPY=no xB.linkhuge (8M: 64):
HUGETLB_MINIMAL_COPY=no xBDT.linkhuge (8M: 64):
HUGETLB_ELFMAP=no xB.linkhuge (8M: 64):
HUGETLB_ELFMAP=no xBDT.linkhuge (8M: 64):
HUGETLB_SHARE=1 xB.linkshare (8M: 64):
HUGETLB_SHARE=1 xBDT.linkshare (8M: 64):
HUGETLB_SHARE=1 xB.linkshare (8M: 64):
HUGETLB_SHARE=1 xBDT.linkshare (8M: 64):
HUGETLB_SHARE=0 xB.linkhuge (8M: 64):
HUGETLB_SHARE=1 xB.linkhuge (8M: 64):
HUGETLB_SHARE=0 xBDT.linkhuge (8M: 64):
HUGETLB_SHARE=1 xBDT.linkhuge (8M: 64):
linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=R linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=W linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=RW linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=no linkhuge_rw (8M: 64):
HUGETLB_MINIMAL_COPY=no HUGETLB_ELFMAP=R linkhuge_rw (8M: 64):
HUGETLB_MINIMAL_COPY=no HUGETLB_ELFMAP=W linkhuge_rw (8M: 64):
HUGETLB_MINIMAL_COPY=no HUGETLB_ELFMAP=RW linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=R HUGETLB_SHARE=0 linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=R HUGETLB_SHARE=1 linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=W HUGETLB_SHARE=0 linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=W HUGETLB_SHARE=1 linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=RW HUGETLB_SHARE=0 linkhuge_rw (8M: 64):
HUGETLB_ELFMAP=RW HUGETLB_SHARE=1 linkhuge_rw (8M: 64):
chunk-overcommit (8M: 64): PASS
alloc-instantiate-race shared (8M: 64): Bad configuration: Atleast online 2 cpus are required
alloc-instantiate-race private (8M: 64): Bad configuration: Atleast online 2 cpus are required
truncate_reserve_wraparound (8M: 64): PASS
truncate_sigbus_versus_oom (8M: 64): PASS
get_huge_pages (8M: 64): PASS
shmoverride_linked (8M: 64): PASS
HUGETLB_SHM=yes shmoverride_linked (8M: 64): PASS
LD_PRELOAD=libhugetlbfs.so shmoverride_unlinked (8M: 64): PASS
LD_PRELOAD=libhugetlbfs.so HUGETLB_SHM=yes shmoverride_unlinked (8M: 64): PASS
quota.sh (8M: 64): PASS
counters.sh (8M: 64): PASS
mmap-gettest 10 25 (8M: 64): PASS
mmap-cow 24 25 (8M: 64): PASS
set shmmax limit to 209715200
shm-fork 10 12 (8M: 64): PASS
set shmmax limit to 209715200
shm-fork 10 25 (8M: 64): PASS
set shmmax limit to 209715200
shm-getraw 25 /dev/full (8M: 64): PASS
fallocate_stress.sh (8M: 64): PASS
********** TEST SUMMARY
* 8M
* 32-bit 64-bit
* Total testcases: 0 111
* Skipped: 0 9
* PASS: 0 57
* FAIL: 0 1
* Killed by signal: 0 1
* Bad configuration: 0 4
* Expected FAIL: 0 0
* Unexpected PASS: 0 0
* Test not present: 0 39
* Strange test result: 0 0
**********
root@raverin:/home/glaubitz/libhugetlbfs#
Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-07-25 20:46 ` John Paul Adrian Glaubitz
@ 2025-07-25 21:09 ` John Paul Adrian Glaubitz
0 siblings, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-07-25 21:09 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi again,
On Fri, 2025-07-25 at 22:46 +0200, John Paul Adrian Glaubitz wrote:
> slbpacaflush (8M: 64): Bad configuration: Atleast online 2 cpus are required
> straddle_4GB_static (8M: 64): PASS
> huge_at_4GB_normal_below_static (8M: 64): FAIL Wrong address with MAP_FIXED normal
> huge_below_4GB_normal_above_static (8M: 64): PASS
> map_high_truncate_2 (8M: 64): PASS
> misaligned_offset (8M: 64): PASS (inconclusive)
> truncate_above_4GB (8M: 64): PASS
> brk_near_huge (8M: 64): Fatal glibc error: malloc.c:2601 (sysmalloc): assertion failed:
> (...)
> fallocate_stress.sh (8M: 64): PASS
> ********** TEST SUMMARY
> * 8M
> * 32-bit 64-bit
> * Total testcases: 0 111
> * Skipped: 0 9
> * PASS: 0 57
> * FAIL: 0 1
> * Killed by signal: 0 1
> * Bad configuration: 0 4
> * Expected FAIL: 0 0
> * Unexpected PASS: 0 0
> * Test not present: 0 39
> * Strange test result: 0 0
> **********
> root@raverin:/home/glaubitz/libhugetlbfs#
>
> Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Ah, I noticed that huge_at_4GB_normal_below_static fails.
Does that test require at least 4 GB of RAM? If yes, it's not surprising
the test fails as this machine have only 2 GB of physical memory and just
1 GB of swap space:
root@raverin:/home/glaubitz/libhugetlbfs# free -h
total used free shared buff/cache available
Mem: 2.0Gi 591Mi 896Mi 1.1Mi 792Mi 1.4Gi
Swap: 976Mi 3.0Mi 973Mi
root@raverin:/home/glaubitz/libhugetlbfs#
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-07-16 1:24 [PATCH] sparc64: fix hugetlb for sun4u Anthony Yznaga
` (2 preceding siblings ...)
2025-07-25 20:46 ` John Paul Adrian Glaubitz
@ 2025-08-08 21:31 ` John Paul Adrian Glaubitz
2025-08-08 22:15 ` Anthony Yznaga
3 siblings, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-08 21:31 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Tue, 2025-07-15 at 18:24 -0700, Anthony Yznaga wrote:
> An attempt to exercise sparc hugetlb code in a sun4u-based guest
> running under qemu results in the guest hanging due to being stuck
> in a trap loop. This is due to invalid hugetlb TTEs being installed
> that do not have the expected _PAGE_PMD_HUGE and page size bits set.
> Although the breakage has gone apparently unnoticed for several years,
> fix it now so there is the option to exercise sparc hugetlb code under
> qemu. This can be useful because sun4v support in qemu does not support
> linux guests currently and sun4v-based hardware resources may not be
> readily available.
>
> Fix tested with a 6.15.2 and 6.16-rc6 kernels by running libhugetlbfs
> tests on a qemu guest running Debian 13.
>
> Fixes: c7d9f77d33a7 ("sparc64: Multi-page size support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Anthony Yznaga <anthony.yznaga@oracle.com>
> ---
> arch/sparc/mm/hugetlbpage.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
> index 80504148d8a5..2048b5c42ca8 100644
> --- a/arch/sparc/mm/hugetlbpage.c
> +++ b/arch/sparc/mm/hugetlbpage.c
> @@ -22,6 +22,26 @@
>
> static pte_t sun4u_hugepage_shift_to_tte(pte_t entry, unsigned int shift)
> {
> + unsigned long hugepage_size = _PAGE_SZ4MB_4U;
> +
> + pte_val(entry) = pte_val(entry) & ~_PAGE_SZALL_4U;
> +
> + switch (shift) {
> + case HPAGE_256MB_SHIFT:
> + hugepage_size = _PAGE_SZ256MB_4U;
> + pte_val(entry) |= _PAGE_PMD_HUGE;
> + break;
> + case HPAGE_SHIFT:
> + pte_val(entry) |= _PAGE_PMD_HUGE;
> + break;
> + case HPAGE_64K_SHIFT:
> + hugepage_size = _PAGE_SZ64K_4U;
> + break;
> + default:
> + WARN_ONCE(1, "unsupported hugepage shift=%u\n", shift);
> + }
> +
> + pte_val(entry) = pte_val(entry) | hugepage_size;
> return entry;
> }
>
So, I have to admit that I'm not an expert on Linux kernel memory management and
don't exactly know what the difference between HugeTLB and Transparent Huge Pages
is. Could someone enlighten me?
The reason I am asking is because while this patch seems to fix HugeTLB support,
we're still seeing TLB-related crashes on sun4u which are triggered when both
CONFIG_TRANSPARENT_HUGEPAGE and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS are set.
I previously thought that HugeTLB and THP are the same, but it seems like that's
not the case.
Enabling both these options leads to the following backtrace during boot:
[ 29.858572] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 29.858580] rcu: (detected by 0, t=2109 jiffies, g=-1155, q=3 ncpus=1)
[ 29.858586] rcu: All QSes seen, last rcu_sched kthread activity 2109 (4294939474-4294937365), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 29.858595] rcu: rcu_sched kthread starved for 2109 jiffies! g-1155 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
[ 29.858603] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
[ 29.858606] rcu: RCU grace-period kthread stack dump:
[ 29.858609] task:rcu_sched state:R running task stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x07000000
[ 29.858626] Call Trace:
[ 29.858629] [<0000000000c0a234>] schedule+0x14/0x160
[ 29.858646] [<0000000000c11194>] schedule_timeout+0x54/0xe0
[ 29.858657] [<00000000004fbd40>] rcu_gp_fqs_loop+0x140/0x6c0
[ 29.858669] [<000000000050003c>] rcu_gp_kthread+0x23c/0x2a0
[ 29.858678] [<000000000049b788>] kthread+0xe8/0x120
[ 29.858688] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
[ 29.858700] [<0000000000000000>] 0x0
[ 29.858705] rcu: Stack dump where RCU GP kthread last ran:
[ 29.858710] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #32 VOLUNTARY
[ 29.858719] TSTATE: 0000004411001603 TPC: 00000000004db400 TNPC: 00000000004db404 Y: 0000137d Not tainted
[ 29.858725] TPC: <console_flush_all+0x360/0x4c0>
[ 29.858738] g0: 00000000004db400 g1: 0000000000000000 g2: 0000000000000000 g3: 00000000017fd000
[ 29.858743] g4: fff0000000180000 g5: fff000023d194000 g6: fff0000000158000 g7: 000000000000000e
[ 29.858748] o0: 00000000017fd1e0 o1: 0000000000000000 o2: 0000000000000000 o3: 00000000017fc5d0
[ 29.858752] o4: 0000000000000000 o5: 000000000185d7e8 sp: fff000000015a901 ret_pc: 00000000004db3f0
[ 29.858757] RPC: <console_flush_all+0x350/0x4c0>
[ 29.858764] l0: 00000000017fc5d0 l1: 0000000000000000 l2: 0000000000000000 l3: 000000000143b538
[ 29.858769] l4: 0000000000000000 l5: 0000000000000001 l6: 00000000015c20b0 l7: 0000000001536308
[ 29.858773] i0: 0000000000000000 i1: fff000000015b2b8 i2: fff000000015b2b3 i3: 0000000000000000
[ 29.858778] i4: 00000000017fd1e0 i5: 0000000000000001 i6: fff000000015aa01 i7: 00000000004db5e8
[ 29.858782] I7: <console_unlock+0x88/0x120>
[ 29.858790] Call Trace:
[ 29.858793] [<00000000004db5e8>] console_unlock+0x88/0x120
[ 29.858801] [<00000000004dc128>] vprintk_emit+0x1e8/0x280
[ 29.858809] [<000000000042a34c>] _printk+0x20/0x30
[ 29.858819] [<00000000004dc66c>] register_console+0x34c/0x580
[ 29.858828] [<0000000000920358>] serial_core_register_port+0x898/0x8c0
[ 29.858835] [<000000000092555c>] su_probe+0x15c/0x3e0
[ 29.858844] [<0000000000936d88>] platform_probe+0x28/0x80
[ 29.858851] [<0000000000934338>] really_probe+0xb8/0x340
[ 29.858863] [<0000000000934764>] driver_probe_device+0x24/0x120
[ 29.858872] [<0000000000934a0c>] __driver_attach+0x8c/0x1a0
[ 29.858879] [<000000000093232c>] bus_for_each_dev+0x4c/0xa0
[ 29.858887] [<0000000000933668>] bus_add_driver+0x148/0x220
[ 29.858894] [<0000000000935634>] driver_register+0x74/0x120
[ 29.858903] [<0000000001635e3c>] sunsu_init+0x180/0x1dc
[ 29.858915] [<00000000004347b0>] do_one_initcall+0x30/0x240
[ 29.858924] [<000000000160d014>] kernel_init_freeable+0x244/0x2b8
Running the apt package manager results in a minute-long hang and this backtrace:
[ 112.800879] systemd-journald[154]: Time jumped backwards, rotating.
[ 123.148552] kernel BUG at fs/ext4/inode.c:1174!
[ 123.208162] \|/ ____ \|/
[ 123.208162] "@'/ .. \`@"
[ 123.208162] /_| \__/ |_\
[ 123.208162] \__U_/
[ 123.401513] apt(881): Kernel bad sw trap 5 [#1]
[ 123.461051] CPU: 0 UID: 0 PID: 881 Comm: apt Not tainted 6.16.0+ #32 VOLUNTARY
[ 123.557129] TSTATE: 0000004411001603 TPC: 000000000075eda8 TNPC: 000000000075edac Y: 00000000 Not tainted
[ 123.686379] TPC: <ext4_block_write_begin+0x408/0x480>
[ 123.752813] g0: 0000000000000000 g1: 0000000000000001 g2: 0000000000000000 g3: 0000000000000000
[ 123.867186] g4: fff0000007eb8140 g5: fff000023d194000 g6: fff000000a130000 g7: 0000000000000001
[ 123.981565] o0: 0000000000000023 o1: 0000000000d74b28 o2: 0000000000000496 o3: 0000000000101cca
[ 124.095948] o4: 0000000001568800 o5: 0000000000000000 sp: fff000000a133161 ret_pc: 000000000075eda0
[ 124.214890] RPC: <ext4_block_write_begin+0x400/0x480>
[ 124.281219] l0: fff00000029ce828 l1: 0000000000113cca l2: fff00000029ce6c0 l3: 0000000000001000
[ 124.395608] l4: 0000000000000002 l5: 0000000000080000 l6: 0000000000012000 l7: 0000000000000001
[ 124.509978] i0: 0000000000000000 i1: 000c0000003bfa00 i2: 0000000000001fc0 i3: 0000000000680000
[ 124.624351] i4: 0000000000000000 i5: 0000000000000000 i6: fff000000a133251 i7: 0000000000762518
[ 124.738729] I7: <ext4_da_write_begin+0x158/0x300>
[ 124.800487] Call Trace:
[ 124.832506] [<0000000000762518>] ext4_da_write_begin+0x158/0x300
[ 124.911429] [<00000000005b84ac>] generic_perform_write+0x8c/0x240
[ 124.991491] [<000000000074ae30>] ext4_buffered_write_iter+0x50/0x120
[ 125.074997] [<0000000000695420>] vfs_write+0x2a0/0x400
[ 125.142468] [<00000000006956c4>] ksys_write+0x44/0xe0
[ 125.208805] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
[ 125.285437] Disabling lock debugging due to kernel taint
[ 125.355205] Caller[0000000000762518]: ext4_da_write_begin+0x158/0x300
[ 125.439843] Caller[00000000005b84ac]: generic_perform_write+0x8c/0x240
[ 125.525624] Caller[000000000074ae30]: ext4_buffered_write_iter+0x50/0x120
[ 125.614836] Caller[0000000000695420]: vfs_write+0x2a0/0x400
[ 125.688035] Caller[00000000006956c4]: ksys_write+0x44/0xe0
[ 125.760093] Caller[0000000000406274]: linux_sparc_syscall+0x34/0x44
[ 125.842442] Caller[0000000000000000]: 0x0
[ 125.895052] Instruction DUMP:
[ 125.895055] 110035d2
[ 125.933938] 7ff35910
[ 125.964823] 90122328
[ 125.995700] <91d02005>
[ 126.026582] 80a06000
[ 126.057466] 02480010
[ 126.088347] d45fa7cf
[ 126.119224] d85fa7cf
[ 126.150125] 9736a000
[ 126.181088]
After applying this patch to fix HugeTLB support on sun4u, the backtrace during boot changes to:
[ 29.860234] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 29.860241] rcu: (detected by 0, t=2109 jiffies, g=-1151, q=3 ncpus=1)
[ 29.860247] rcu: All QSes seen, last rcu_sched kthread activity 2109 (4294939474-4294937365), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 29.860256] rcu: rcu_sched kthread starved for 2109 jiffies! g-1151 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
[ 29.860263] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
[ 29.860266] rcu: RCU grace-period kthread stack dump:
[ 29.860269] task:rcu_sched state:R running task stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x07000000
[ 29.860285] Call Trace:
[ 29.860288] [<0000000000c0a2f4>] schedule+0x14/0x160
[ 29.860305] [<0000000000c11254>] schedule_timeout+0x54/0xe0
[ 29.860317] [<00000000004fbe00>] rcu_gp_fqs_loop+0x140/0x6c0
[ 29.860329] [<00000000005000fc>] rcu_gp_kthread+0x23c/0x2a0
[ 29.860338] [<000000000049b848>] kthread+0xe8/0x120
[ 29.860347] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
[ 29.860359] [<0000000000000000>] 0x0
[ 29.860364] rcu: Stack dump where RCU GP kthread last ran:
[ 29.860368] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #33 VOLUNTARY
[ 29.860378] TSTATE: 0000004411001603 TPC: 00000000004db4c0 TNPC: 00000000004db4c4 Y: 00001390 Not tainted
[ 29.860383] TPC: <console_flush_all+0x360/0x4c0>
[ 29.860397] g0: 00000000004db4c0 g1: 0000000000000000 g2: 0000000000000000 g3: 00000000017fd000
[ 29.860401] g4: fff0000000180000 g5: fff000023d194000 g6: fff0000000158000 g7: 000000000000000e
[ 29.860406] o0: 00000000017fd1e0 o1: 0000000000000000 o2: 0000000000000000 o3: 00000000017fc5d0
[ 29.860411] o4: 0000000000000000 o5: 000000000185d7e8 sp: fff000000015a901 ret_pc: 00000000004db4b0
[ 29.860415] RPC: <console_flush_all+0x350/0x4c0>
[ 29.860423] l0: 00000000017fc5d0 l1: 0000000000000000 l2: 0000000000000000 l3: 000000000143b538
[ 29.860427] l4: 0000000000000000 l5: 0000000000000001 l6: 00000000015c20b0 l7: 0000000001536308
[ 29.860432] i0: 0000000000000000 i1: fff000000015b2b8 i2: fff000000015b2b3 i3: 0000000000000000
[ 29.860436] i4: 00000000017fd1e0 i5: 0000000000000001 i6: fff000000015aa01 i7: 00000000004db6a8
[ 29.860441] I7: <console_unlock+0x88/0x120>
[ 29.860449] Call Trace:
[ 29.860451] [<00000000004db6a8>] console_unlock+0x88/0x120
[ 29.860459] [<00000000004dc1e8>] vprintk_emit+0x1e8/0x280
[ 29.860467] [<000000000042a34c>] _printk+0x20/0x30
[ 29.860477] [<00000000004dc72c>] register_console+0x34c/0x580
[ 29.860485] [<0000000000920418>] serial_core_register_port+0x898/0x8c0
[ 29.860493] [<000000000092561c>] su_probe+0x15c/0x3e0
[ 29.860502] [<0000000000936e48>] platform_probe+0x28/0x80
[ 29.860509] [<00000000009343f8>] really_probe+0xb8/0x340
[ 29.860521] [<0000000000934824>] driver_probe_device+0x24/0x120
[ 29.860529] [<0000000000934acc>] __driver_attach+0x8c/0x1a0
[ 29.860537] [<00000000009323ec>] bus_for_each_dev+0x4c/0xa0
[ 29.860544] [<0000000000933728>] bus_add_driver+0x148/0x220
[ 29.860552] [<00000000009356f4>] driver_register+0x74/0x120
[ 29.860560] [<0000000001635e3c>] sunsu_init+0x180/0x1dc
[ 29.860572] [<00000000004347b0>] do_one_initcall+0x30/0x240
[ 29.860581] [<000000000160d014>] kernel_init_freeable+0x244/0x2b
while the backtrace produced when apt hangs is:
[ 337.599490] ------------[ cut here ]------------
[ 337.660412] WARNING: CPU: 0 PID: 895 at fs/ext4/extents_status.c:298 __es_find_extent_range+0x128/0x140
[ 337.784523] Modules linked in: sg sr_mod cdrom sym53c8xx tg3 libphy mdio_bus
[ 337.877302] CPU: 0 UID: 0 PID: 895 Comm: apt Not tainted 6.16.0+ #33 VOLUNTARY
[ 337.877314] Call Trace:
[ 337.877316] [<000000000047286c>] __warn+0x10c/0x120
[ 337.877326] [<0000000000472910>] warn_slowpath_fmt+0x90/0x120
[ 337.877332] [<0000000000748988>] __es_find_extent_range+0x128/0x140
[ 337.877341] [<00000000007490f0>] ext4_es_find_extent_range+0x50/0x100
[ 337.877348] [<0000000000742a1c>] ext4_ext_map_blocks+0x7fc/0x22a0
[ 337.877355] [<00000000007578d0>] ext4_map_query_blocks+0x30/0x2a0
[ 337.877366] [<00000000007596a0>] ext4_da_get_block_prep+0x380/0x640
[ 337.877375] [<000000000075ecf4>] ext4_block_write_begin+0x294/0x480
[ 337.877382] [<00000000007625d8>] ext4_da_write_begin+0x158/0x300
[ 337.877389] [<00000000005b856c>] generic_perform_write+0x8c/0x240
[ 337.877399] [<000000000074aef0>] ext4_buffered_write_iter+0x50/0x120
[ 337.877406] [<00000000006954e0>] vfs_write+0x2a0/0x400
[ 337.877415] [<0000000000695784>] ksys_write+0x44/0xe0
[ 337.877421] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
[ 337.877433] ---[ end trace 0000000000000000 ]---
[ 339.153555] ------------[ cut here ]------------
[ 339.214459] WARNING: CPU: 0 PID: 895 at fs/ext4/extents_status.c:298 __es_find_extent_range+0x128/0x140
[ 339.338108] Modules linked in: sg sr_mod cdrom sym53c8xx tg3 libphy mdio_bus
[ 339.430869] CPU: 0 UID: 0 PID: 895 Comm: apt Tainted: G W 6.16.0+ #33 VOLUNTARY
[ 339.430880] Tainted: [W]=WARN
[ 339.430883] Call Trace:
[ 339.430886] [<000000000047286c>] __warn+0x10c/0x120
[ 339.430894] [<0000000000472910>] warn_slowpath_fmt+0x90/0x120
[ 339.430900] [<0000000000748988>] __es_find_extent_range+0x128/0x140
[ 339.430907] [<00000000007490f0>] ext4_es_find_extent_range+0x50/0x100
[ 339.430915] [<0000000000742a1c>] ext4_ext_map_blocks+0x7fc/0x22a0
[ 339.430921] [<00000000007578d0>] ext4_map_query_blocks+0x30/0x2a0
[ 339.430931] [<00000000007597d4>] ext4_da_get_block_prep+0x4b4/0x640
[ 339.430940] [<000000000075ecf4>] ext4_block_write_begin+0x294/0x480
[ 339.430948] [<00000000007625d8>] ext4_da_write_begin+0x158/0x300
[ 339.430954] [<00000000005b856c>] generic_perform_write+0x8c/0x240
[ 339.430964] [<000000000074aef0>] ext4_buffered_write_iter+0x50/0x120
[ 339.430971] [<00000000006954e0>] vfs_write+0x2a0/0x400
[ 339.430979] [<0000000000695784>] ksys_write+0x44/0xe0
[ 339.430985] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
[ 339.430996] ---[ end trace 0000000000000000 ]---
So, I guess while your patch may fix HugeTLB support, there is still a bug on sun4u with THP
which needs to be addressed.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-08 21:31 ` John Paul Adrian Glaubitz
@ 2025-08-08 22:15 ` Anthony Yznaga
2025-08-08 22:37 ` John Paul Adrian Glaubitz
0 siblings, 1 reply; 26+ messages in thread
From: Anthony Yznaga @ 2025-08-08 22:15 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Adrian,
On 8/8/25 2:31 PM, John Paul Adrian Glaubitz wrote:
> Hi Anthony,
>
> On Tue, 2025-07-15 at 18:24 -0700, Anthony Yznaga wrote:
>> An attempt to exercise sparc hugetlb code in a sun4u-based guest
>> running under qemu results in the guest hanging due to being stuck
>> in a trap loop. This is due to invalid hugetlb TTEs being installed
>> that do not have the expected _PAGE_PMD_HUGE and page size bits set.
>> Although the breakage has gone apparently unnoticed for several years,
>> fix it now so there is the option to exercise sparc hugetlb code under
>> qemu. This can be useful because sun4v support in qemu does not support
>> linux guests currently and sun4v-based hardware resources may not be
>> readily available.
>>
>> Fix tested with a 6.15.2 and 6.16-rc6 kernels by running libhugetlbfs
>> tests on a qemu guest running Debian 13.
>>
>> Fixes: c7d9f77d33a7 ("sparc64: Multi-page size support")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Anthony Yznaga <anthony.yznaga@oracle.com>
>> ---
>> arch/sparc/mm/hugetlbpage.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
>> index 80504148d8a5..2048b5c42ca8 100644
>> --- a/arch/sparc/mm/hugetlbpage.c
>> +++ b/arch/sparc/mm/hugetlbpage.c
>> @@ -22,6 +22,26 @@
>>
>> static pte_t sun4u_hugepage_shift_to_tte(pte_t entry, unsigned int shift)
>> {
>> + unsigned long hugepage_size = _PAGE_SZ4MB_4U;
>> +
>> + pte_val(entry) = pte_val(entry) & ~_PAGE_SZALL_4U;
>> +
>> + switch (shift) {
>> + case HPAGE_256MB_SHIFT:
>> + hugepage_size = _PAGE_SZ256MB_4U;
>> + pte_val(entry) |= _PAGE_PMD_HUGE;
>> + break;
>> + case HPAGE_SHIFT:
>> + pte_val(entry) |= _PAGE_PMD_HUGE;
>> + break;
>> + case HPAGE_64K_SHIFT:
>> + hugepage_size = _PAGE_SZ64K_4U;
>> + break;
>> + default:
>> + WARN_ONCE(1, "unsupported hugepage shift=%u\n", shift);
>> + }
>> +
>> + pte_val(entry) = pte_val(entry) | hugepage_size;
>> return entry;
>> }
>>
>
> So, I have to admit that I'm not an expert on Linux kernel memory management and
> don't exactly know what the difference between HugeTLB and Transparent Huge Pages
> is. Could someone enlighten me?
They both use use huge pages to reduce the number of TLB misses. HugeTLB
has to be configured and requires changes to an application to
explicitly use it. THP works in a more automated fashion where the
kernel manages when and where to use huge pages without requiring
changes to the application.
>
> The reason I am asking is because while this patch seems to fix HugeTLB support,
> we're still seeing TLB-related crashes on sun4u which are triggered when both
> CONFIG_TRANSPARENT_HUGEPAGE and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS are set.
>
> I previously thought that HugeTLB and THP are the same, but it seems like that's
> not the case.
Yes, my patch fixes HugeTLB only, and has no bearing on THP.
>
> Enabling both these options leads to the following backtrace during boot:
>
> [ 29.858572] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [ 29.858580] rcu: (detected by 0, t=2109 jiffies, g=-1155, q=3 ncpus=1)
> [ 29.858586] rcu: All QSes seen, last rcu_sched kthread activity 2109 (4294939474-4294937365), jiffies_till_next_fqs=1, root ->qsmask 0x0
> [ 29.858595] rcu: rcu_sched kthread starved for 2109 jiffies! g-1155 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
> [ 29.858603] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
> [ 29.858606] rcu: RCU grace-period kthread stack dump:
> [ 29.858609] task:rcu_sched state:R running task stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x07000000
> [ 29.858626] Call Trace:
> [ 29.858629] [<0000000000c0a234>] schedule+0x14/0x160
> [ 29.858646] [<0000000000c11194>] schedule_timeout+0x54/0xe0
> [ 29.858657] [<00000000004fbd40>] rcu_gp_fqs_loop+0x140/0x6c0
> [ 29.858669] [<000000000050003c>] rcu_gp_kthread+0x23c/0x2a0
> [ 29.858678] [<000000000049b788>] kthread+0xe8/0x120
> [ 29.858688] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
> [ 29.858700] [<0000000000000000>] 0x0
> [ 29.858705] rcu: Stack dump where RCU GP kthread last ran:
> [ 29.858710] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #32 VOLUNTARY
> [ 29.858719] TSTATE: 0000004411001603 TPC: 00000000004db400 TNPC: 00000000004db404 Y: 0000137d Not tainted
> [ 29.858725] TPC: <console_flush_all+0x360/0x4c0>
> [ 29.858738] g0: 00000000004db400 g1: 0000000000000000 g2: 0000000000000000 g3: 00000000017fd000
> [ 29.858743] g4: fff0000000180000 g5: fff000023d194000 g6: fff0000000158000 g7: 000000000000000e
> [ 29.858748] o0: 00000000017fd1e0 o1: 0000000000000000 o2: 0000000000000000 o3: 00000000017fc5d0
> [ 29.858752] o4: 0000000000000000 o5: 000000000185d7e8 sp: fff000000015a901 ret_pc: 00000000004db3f0
> [ 29.858757] RPC: <console_flush_all+0x350/0x4c0>
> [ 29.858764] l0: 00000000017fc5d0 l1: 0000000000000000 l2: 0000000000000000 l3: 000000000143b538
> [ 29.858769] l4: 0000000000000000 l5: 0000000000000001 l6: 00000000015c20b0 l7: 0000000001536308
> [ 29.858773] i0: 0000000000000000 i1: fff000000015b2b8 i2: fff000000015b2b3 i3: 0000000000000000
> [ 29.858778] i4: 00000000017fd1e0 i5: 0000000000000001 i6: fff000000015aa01 i7: 00000000004db5e8
> [ 29.858782] I7: <console_unlock+0x88/0x120>
> [ 29.858790] Call Trace:
> [ 29.858793] [<00000000004db5e8>] console_unlock+0x88/0x120
> [ 29.858801] [<00000000004dc128>] vprintk_emit+0x1e8/0x280
> [ 29.858809] [<000000000042a34c>] _printk+0x20/0x30
> [ 29.858819] [<00000000004dc66c>] register_console+0x34c/0x580
> [ 29.858828] [<0000000000920358>] serial_core_register_port+0x898/0x8c0
> [ 29.858835] [<000000000092555c>] su_probe+0x15c/0x3e0
> [ 29.858844] [<0000000000936d88>] platform_probe+0x28/0x80
> [ 29.858851] [<0000000000934338>] really_probe+0xb8/0x340
> [ 29.858863] [<0000000000934764>] driver_probe_device+0x24/0x120
> [ 29.858872] [<0000000000934a0c>] __driver_attach+0x8c/0x1a0
> [ 29.858879] [<000000000093232c>] bus_for_each_dev+0x4c/0xa0
> [ 29.858887] [<0000000000933668>] bus_add_driver+0x148/0x220
> [ 29.858894] [<0000000000935634>] driver_register+0x74/0x120
> [ 29.858903] [<0000000001635e3c>] sunsu_init+0x180/0x1dc
> [ 29.858915] [<00000000004347b0>] do_one_initcall+0x30/0x240
> [ 29.858924] [<000000000160d014>] kernel_init_freeable+0x244/0x2b8
>
> Running the apt package manager results in a minute-long hang and this backtrace:
>
> [ 112.800879] systemd-journald[154]: Time jumped backwards, rotating.
> [ 123.148552] kernel BUG at fs/ext4/inode.c:1174!
> [ 123.208162] \|/ ____ \|/
> [ 123.208162] "@'/ .. \`@"
> [ 123.208162] /_| \__/ |_\
> [ 123.208162] \__U_/
> [ 123.401513] apt(881): Kernel bad sw trap 5 [#1]
> [ 123.461051] CPU: 0 UID: 0 PID: 881 Comm: apt Not tainted 6.16.0+ #32 VOLUNTARY
> [ 123.557129] TSTATE: 0000004411001603 TPC: 000000000075eda8 TNPC: 000000000075edac Y: 00000000 Not tainted
> [ 123.686379] TPC: <ext4_block_write_begin+0x408/0x480>
> [ 123.752813] g0: 0000000000000000 g1: 0000000000000001 g2: 0000000000000000 g3: 0000000000000000
> [ 123.867186] g4: fff0000007eb8140 g5: fff000023d194000 g6: fff000000a130000 g7: 0000000000000001
> [ 123.981565] o0: 0000000000000023 o1: 0000000000d74b28 o2: 0000000000000496 o3: 0000000000101cca
> [ 124.095948] o4: 0000000001568800 o5: 0000000000000000 sp: fff000000a133161 ret_pc: 000000000075eda0
> [ 124.214890] RPC: <ext4_block_write_begin+0x400/0x480>
> [ 124.281219] l0: fff00000029ce828 l1: 0000000000113cca l2: fff00000029ce6c0 l3: 0000000000001000
> [ 124.395608] l4: 0000000000000002 l5: 0000000000080000 l6: 0000000000012000 l7: 0000000000000001
> [ 124.509978] i0: 0000000000000000 i1: 000c0000003bfa00 i2: 0000000000001fc0 i3: 0000000000680000
> [ 124.624351] i4: 0000000000000000 i5: 0000000000000000 i6: fff000000a133251 i7: 0000000000762518
> [ 124.738729] I7: <ext4_da_write_begin+0x158/0x300>
> [ 124.800487] Call Trace:
> [ 124.832506] [<0000000000762518>] ext4_da_write_begin+0x158/0x300
> [ 124.911429] [<00000000005b84ac>] generic_perform_write+0x8c/0x240
> [ 124.991491] [<000000000074ae30>] ext4_buffered_write_iter+0x50/0x120
> [ 125.074997] [<0000000000695420>] vfs_write+0x2a0/0x400
> [ 125.142468] [<00000000006956c4>] ksys_write+0x44/0xe0
> [ 125.208805] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
> [ 125.285437] Disabling lock debugging due to kernel taint
> [ 125.355205] Caller[0000000000762518]: ext4_da_write_begin+0x158/0x300
> [ 125.439843] Caller[00000000005b84ac]: generic_perform_write+0x8c/0x240
> [ 125.525624] Caller[000000000074ae30]: ext4_buffered_write_iter+0x50/0x120
> [ 125.614836] Caller[0000000000695420]: vfs_write+0x2a0/0x400
> [ 125.688035] Caller[00000000006956c4]: ksys_write+0x44/0xe0
> [ 125.760093] Caller[0000000000406274]: linux_sparc_syscall+0x34/0x44
> [ 125.842442] Caller[0000000000000000]: 0x0
> [ 125.895052] Instruction DUMP:
> [ 125.895055] 110035d2
> [ 125.933938] 7ff35910
> [ 125.964823] 90122328
> [ 125.995700] <91d02005>
> [ 126.026582] 80a06000
> [ 126.057466] 02480010
> [ 126.088347] d45fa7cf
> [ 126.119224] d85fa7cf
> [ 126.150125] 9736a000
> [ 126.181088]
>
> After applying this patch to fix HugeTLB support on sun4u, the backtrace during boot changes to:
>
> [ 29.860234] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> [ 29.860241] rcu: (detected by 0, t=2109 jiffies, g=-1151, q=3 ncpus=1)
> [ 29.860247] rcu: All QSes seen, last rcu_sched kthread activity 2109 (4294939474-4294937365), jiffies_till_next_fqs=1, root ->qsmask 0x0
> [ 29.860256] rcu: rcu_sched kthread starved for 2109 jiffies! g-1151 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
> [ 29.860263] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
> [ 29.860266] rcu: RCU grace-period kthread stack dump:
> [ 29.860269] task:rcu_sched state:R running task stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x07000000
> [ 29.860285] Call Trace:
> [ 29.860288] [<0000000000c0a2f4>] schedule+0x14/0x160
> [ 29.860305] [<0000000000c11254>] schedule_timeout+0x54/0xe0
> [ 29.860317] [<00000000004fbe00>] rcu_gp_fqs_loop+0x140/0x6c0
> [ 29.860329] [<00000000005000fc>] rcu_gp_kthread+0x23c/0x2a0
> [ 29.860338] [<000000000049b848>] kthread+0xe8/0x120
> [ 29.860347] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
> [ 29.860359] [<0000000000000000>] 0x0
> [ 29.860364] rcu: Stack dump where RCU GP kthread last ran:
> [ 29.860368] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #33 VOLUNTARY
> [ 29.860378] TSTATE: 0000004411001603 TPC: 00000000004db4c0 TNPC: 00000000004db4c4 Y: 00001390 Not tainted
> [ 29.860383] TPC: <console_flush_all+0x360/0x4c0>
> [ 29.860397] g0: 00000000004db4c0 g1: 0000000000000000 g2: 0000000000000000 g3: 00000000017fd000
> [ 29.860401] g4: fff0000000180000 g5: fff000023d194000 g6: fff0000000158000 g7: 000000000000000e
> [ 29.860406] o0: 00000000017fd1e0 o1: 0000000000000000 o2: 0000000000000000 o3: 00000000017fc5d0
> [ 29.860411] o4: 0000000000000000 o5: 000000000185d7e8 sp: fff000000015a901 ret_pc: 00000000004db4b0
> [ 29.860415] RPC: <console_flush_all+0x350/0x4c0>
> [ 29.860423] l0: 00000000017fc5d0 l1: 0000000000000000 l2: 0000000000000000 l3: 000000000143b538
> [ 29.860427] l4: 0000000000000000 l5: 0000000000000001 l6: 00000000015c20b0 l7: 0000000001536308
> [ 29.860432] i0: 0000000000000000 i1: fff000000015b2b8 i2: fff000000015b2b3 i3: 0000000000000000
> [ 29.860436] i4: 00000000017fd1e0 i5: 0000000000000001 i6: fff000000015aa01 i7: 00000000004db6a8
> [ 29.860441] I7: <console_unlock+0x88/0x120>
> [ 29.860449] Call Trace:
> [ 29.860451] [<00000000004db6a8>] console_unlock+0x88/0x120
> [ 29.860459] [<00000000004dc1e8>] vprintk_emit+0x1e8/0x280
> [ 29.860467] [<000000000042a34c>] _printk+0x20/0x30
> [ 29.860477] [<00000000004dc72c>] register_console+0x34c/0x580
> [ 29.860485] [<0000000000920418>] serial_core_register_port+0x898/0x8c0
> [ 29.860493] [<000000000092561c>] su_probe+0x15c/0x3e0
> [ 29.860502] [<0000000000936e48>] platform_probe+0x28/0x80
> [ 29.860509] [<00000000009343f8>] really_probe+0xb8/0x340
> [ 29.860521] [<0000000000934824>] driver_probe_device+0x24/0x120
> [ 29.860529] [<0000000000934acc>] __driver_attach+0x8c/0x1a0
> [ 29.860537] [<00000000009323ec>] bus_for_each_dev+0x4c/0xa0
> [ 29.860544] [<0000000000933728>] bus_add_driver+0x148/0x220
> [ 29.860552] [<00000000009356f4>] driver_register+0x74/0x120
> [ 29.860560] [<0000000001635e3c>] sunsu_init+0x180/0x1dc
> [ 29.860572] [<00000000004347b0>] do_one_initcall+0x30/0x240
> [ 29.860581] [<000000000160d014>] kernel_init_freeable+0x244/0x2b
>
> while the backtrace produced when apt hangs is:
>
> [ 337.599490] ------------[ cut here ]------------
> [ 337.660412] WARNING: CPU: 0 PID: 895 at fs/ext4/extents_status.c:298 __es_find_extent_range+0x128/0x140
> [ 337.784523] Modules linked in: sg sr_mod cdrom sym53c8xx tg3 libphy mdio_bus
> [ 337.877302] CPU: 0 UID: 0 PID: 895 Comm: apt Not tainted 6.16.0+ #33 VOLUNTARY
> [ 337.877314] Call Trace:
> [ 337.877316] [<000000000047286c>] __warn+0x10c/0x120
> [ 337.877326] [<0000000000472910>] warn_slowpath_fmt+0x90/0x120
> [ 337.877332] [<0000000000748988>] __es_find_extent_range+0x128/0x140
> [ 337.877341] [<00000000007490f0>] ext4_es_find_extent_range+0x50/0x100
> [ 337.877348] [<0000000000742a1c>] ext4_ext_map_blocks+0x7fc/0x22a0
> [ 337.877355] [<00000000007578d0>] ext4_map_query_blocks+0x30/0x2a0
> [ 337.877366] [<00000000007596a0>] ext4_da_get_block_prep+0x380/0x640
> [ 337.877375] [<000000000075ecf4>] ext4_block_write_begin+0x294/0x480
> [ 337.877382] [<00000000007625d8>] ext4_da_write_begin+0x158/0x300
> [ 337.877389] [<00000000005b856c>] generic_perform_write+0x8c/0x240
> [ 337.877399] [<000000000074aef0>] ext4_buffered_write_iter+0x50/0x120
> [ 337.877406] [<00000000006954e0>] vfs_write+0x2a0/0x400
> [ 337.877415] [<0000000000695784>] ksys_write+0x44/0xe0
> [ 337.877421] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
> [ 337.877433] ---[ end trace 0000000000000000 ]---
> [ 339.153555] ------------[ cut here ]------------
> [ 339.214459] WARNING: CPU: 0 PID: 895 at fs/ext4/extents_status.c:298 __es_find_extent_range+0x128/0x140
> [ 339.338108] Modules linked in: sg sr_mod cdrom sym53c8xx tg3 libphy mdio_bus
> [ 339.430869] CPU: 0 UID: 0 PID: 895 Comm: apt Tainted: G W 6.16.0+ #33 VOLUNTARY
> [ 339.430880] Tainted: [W]=WARN
> [ 339.430883] Call Trace:
> [ 339.430886] [<000000000047286c>] __warn+0x10c/0x120
> [ 339.430894] [<0000000000472910>] warn_slowpath_fmt+0x90/0x120
> [ 339.430900] [<0000000000748988>] __es_find_extent_range+0x128/0x140
> [ 339.430907] [<00000000007490f0>] ext4_es_find_extent_range+0x50/0x100
> [ 339.430915] [<0000000000742a1c>] ext4_ext_map_blocks+0x7fc/0x22a0
> [ 339.430921] [<00000000007578d0>] ext4_map_query_blocks+0x30/0x2a0
> [ 339.430931] [<00000000007597d4>] ext4_da_get_block_prep+0x4b4/0x640
> [ 339.430940] [<000000000075ecf4>] ext4_block_write_begin+0x294/0x480
> [ 339.430948] [<00000000007625d8>] ext4_da_write_begin+0x158/0x300
> [ 339.430954] [<00000000005b856c>] generic_perform_write+0x8c/0x240
> [ 339.430964] [<000000000074aef0>] ext4_buffered_write_iter+0x50/0x120
> [ 339.430971] [<00000000006954e0>] vfs_write+0x2a0/0x400
> [ 339.430979] [<0000000000695784>] ksys_write+0x44/0xe0
> [ 339.430985] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
> [ 339.430996] ---[ end trace 0000000000000000 ]---
>
> So, I guess while your patch may fix HugeTLB support, there is still a bug on sun4u with THP
> which needs to be addressed.
Maybe try enabling CONFIG_DEBUG_VM_IRQSOFF, CONFIG_DEBUG_VM, and perhaps
CONFIG_DEBUG_VM_PGFLAGS. That might help detect a problem closer to the
source. You can also try adding transparent_hugepage=never to the kernel
boot line to see if compiling in THP support but not using it is okay.
Anthony
>
> Adrian
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-08 22:15 ` Anthony Yznaga
@ 2025-08-08 22:37 ` John Paul Adrian Glaubitz
2025-08-09 6:23 ` John Paul Adrian Glaubitz
0 siblings, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-08 22:37 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Fri, 2025-08-08 at 15:15 -0700, Anthony Yznaga wrote:
> > So, I have to admit that I'm not an expert on Linux kernel memory management and
> > don't exactly know what the difference between HugeTLB and Transparent Huge Pages
> > is. Could someone enlighten me?
>
> They both use use huge pages to reduce the number of TLB misses. HugeTLB
> has to be configured and requires changes to an application to
> explicitly use it. THP works in a more automated fashion where the
> kernel manages when and where to use huge pages without requiring
> changes to the application.
Thanks for the explanation! I had actually researched the difference in the mean time
because I was curious about it ;-).
> >
> > The reason I am asking is because while this patch seems to fix HugeTLB support,
> > we're still seeing TLB-related crashes on sun4u which are triggered when both
> > CONFIG_TRANSPARENT_HUGEPAGE and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS are set.
> >
> > I previously thought that HugeTLB and THP are the same, but it seems like that's
> > not the case.
>
> Yes, my patch fixes HugeTLB only, and has no bearing on THP.
>
> >
> > Enabling both these options leads to the following backtrace during boot:
> >
> > [ 29.858572] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> > [ 29.858580] rcu: (detected by 0, t=2109 jiffies, g=-1155, q=3 ncpus=1)
> > [ 29.858586] rcu: All QSes seen, last rcu_sched kthread activity 2109 (4294939474-4294937365), jiffies_till_next_fqs=1, root ->qsmask 0x0
> > [ 29.858595] rcu: rcu_sched kthread starved for 2109 jiffies! g-1155 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
> > [ 29.858603] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
> > [ 29.858606] rcu: RCU grace-period kthread stack dump:
> > [ 29.858609] task:rcu_sched state:R running task stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x07000000
> > [ 29.858626] Call Trace:
> > [ 29.858629] [<0000000000c0a234>] schedule+0x14/0x160
> > [ 29.858646] [<0000000000c11194>] schedule_timeout+0x54/0xe0
> > [ 29.858657] [<00000000004fbd40>] rcu_gp_fqs_loop+0x140/0x6c0
> > [ 29.858669] [<000000000050003c>] rcu_gp_kthread+0x23c/0x2a0
> > [ 29.858678] [<000000000049b788>] kthread+0xe8/0x120
> > [ 29.858688] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
> > [ 29.858700] [<0000000000000000>] 0x0
> > [ 29.858705] rcu: Stack dump where RCU GP kthread last ran:
> > [ 29.858710] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #32 VOLUNTARY
> > [ 29.858719] TSTATE: 0000004411001603 TPC: 00000000004db400 TNPC: 00000000004db404 Y: 0000137d Not tainted
> > [ 29.858725] TPC: <console_flush_all+0x360/0x4c0>
> > [ 29.858738] g0: 00000000004db400 g1: 0000000000000000 g2: 0000000000000000 g3: 00000000017fd000
> > [ 29.858743] g4: fff0000000180000 g5: fff000023d194000 g6: fff0000000158000 g7: 000000000000000e
> > [ 29.858748] o0: 00000000017fd1e0 o1: 0000000000000000 o2: 0000000000000000 o3: 00000000017fc5d0
> > [ 29.858752] o4: 0000000000000000 o5: 000000000185d7e8 sp: fff000000015a901 ret_pc: 00000000004db3f0
> > [ 29.858757] RPC: <console_flush_all+0x350/0x4c0>
> > [ 29.858764] l0: 00000000017fc5d0 l1: 0000000000000000 l2: 0000000000000000 l3: 000000000143b538
> > [ 29.858769] l4: 0000000000000000 l5: 0000000000000001 l6: 00000000015c20b0 l7: 0000000001536308
> > [ 29.858773] i0: 0000000000000000 i1: fff000000015b2b8 i2: fff000000015b2b3 i3: 0000000000000000
> > [ 29.858778] i4: 00000000017fd1e0 i5: 0000000000000001 i6: fff000000015aa01 i7: 00000000004db5e8
> > [ 29.858782] I7: <console_unlock+0x88/0x120>
> > [ 29.858790] Call Trace:
> > [ 29.858793] [<00000000004db5e8>] console_unlock+0x88/0x120
> > [ 29.858801] [<00000000004dc128>] vprintk_emit+0x1e8/0x280
> > [ 29.858809] [<000000000042a34c>] _printk+0x20/0x30
> > [ 29.858819] [<00000000004dc66c>] register_console+0x34c/0x580
> > [ 29.858828] [<0000000000920358>] serial_core_register_port+0x898/0x8c0
> > [ 29.858835] [<000000000092555c>] su_probe+0x15c/0x3e0
> > [ 29.858844] [<0000000000936d88>] platform_probe+0x28/0x80
> > [ 29.858851] [<0000000000934338>] really_probe+0xb8/0x340
> > [ 29.858863] [<0000000000934764>] driver_probe_device+0x24/0x120
> > [ 29.858872] [<0000000000934a0c>] __driver_attach+0x8c/0x1a0
> > [ 29.858879] [<000000000093232c>] bus_for_each_dev+0x4c/0xa0
> > [ 29.858887] [<0000000000933668>] bus_add_driver+0x148/0x220
> > [ 29.858894] [<0000000000935634>] driver_register+0x74/0x120
> > [ 29.858903] [<0000000001635e3c>] sunsu_init+0x180/0x1dc
> > [ 29.858915] [<00000000004347b0>] do_one_initcall+0x30/0x240
> > [ 29.858924] [<000000000160d014>] kernel_init_freeable+0x244/0x2b8
> >
> > Running the apt package manager results in a minute-long hang and this backtrace:
> >
> > [ 112.800879] systemd-journald[154]: Time jumped backwards, rotating.
> > [ 123.148552] kernel BUG at fs/ext4/inode.c:1174!
> > [ 123.208162] \|/ ____ \|/
> > [ 123.208162] "@'/ .. \`@"
> > [ 123.208162] /_| \__/ |_\
> > [ 123.208162] \__U_/
> > [ 123.401513] apt(881): Kernel bad sw trap 5 [#1]
> > [ 123.461051] CPU: 0 UID: 0 PID: 881 Comm: apt Not tainted 6.16.0+ #32 VOLUNTARY
> > [ 123.557129] TSTATE: 0000004411001603 TPC: 000000000075eda8 TNPC: 000000000075edac Y: 00000000 Not tainted
> > [ 123.686379] TPC: <ext4_block_write_begin+0x408/0x480>
> > [ 123.752813] g0: 0000000000000000 g1: 0000000000000001 g2: 0000000000000000 g3: 0000000000000000
> > [ 123.867186] g4: fff0000007eb8140 g5: fff000023d194000 g6: fff000000a130000 g7: 0000000000000001
> > [ 123.981565] o0: 0000000000000023 o1: 0000000000d74b28 o2: 0000000000000496 o3: 0000000000101cca
> > [ 124.095948] o4: 0000000001568800 o5: 0000000000000000 sp: fff000000a133161 ret_pc: 000000000075eda0
> > [ 124.214890] RPC: <ext4_block_write_begin+0x400/0x480>
> > [ 124.281219] l0: fff00000029ce828 l1: 0000000000113cca l2: fff00000029ce6c0 l3: 0000000000001000
> > [ 124.395608] l4: 0000000000000002 l5: 0000000000080000 l6: 0000000000012000 l7: 0000000000000001
> > [ 124.509978] i0: 0000000000000000 i1: 000c0000003bfa00 i2: 0000000000001fc0 i3: 0000000000680000
> > [ 124.624351] i4: 0000000000000000 i5: 0000000000000000 i6: fff000000a133251 i7: 0000000000762518
> > [ 124.738729] I7: <ext4_da_write_begin+0x158/0x300>
> > [ 124.800487] Call Trace:
> > [ 124.832506] [<0000000000762518>] ext4_da_write_begin+0x158/0x300
> > [ 124.911429] [<00000000005b84ac>] generic_perform_write+0x8c/0x240
> > [ 124.991491] [<000000000074ae30>] ext4_buffered_write_iter+0x50/0x120
> > [ 125.074997] [<0000000000695420>] vfs_write+0x2a0/0x400
> > [ 125.142468] [<00000000006956c4>] ksys_write+0x44/0xe0
> > [ 125.208805] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
> > [ 125.285437] Disabling lock debugging due to kernel taint
> > [ 125.355205] Caller[0000000000762518]: ext4_da_write_begin+0x158/0x300
> > [ 125.439843] Caller[00000000005b84ac]: generic_perform_write+0x8c/0x240
> > [ 125.525624] Caller[000000000074ae30]: ext4_buffered_write_iter+0x50/0x120
> > [ 125.614836] Caller[0000000000695420]: vfs_write+0x2a0/0x400
> > [ 125.688035] Caller[00000000006956c4]: ksys_write+0x44/0xe0
> > [ 125.760093] Caller[0000000000406274]: linux_sparc_syscall+0x34/0x44
> > [ 125.842442] Caller[0000000000000000]: 0x0
> > [ 125.895052] Instruction DUMP:
> > [ 125.895055] 110035d2
> > [ 125.933938] 7ff35910
> > [ 125.964823] 90122328
> > [ 125.995700] <91d02005>
> > [ 126.026582] 80a06000
> > [ 126.057466] 02480010
> > [ 126.088347] d45fa7cf
> > [ 126.119224] d85fa7cf
> > [ 126.150125] 9736a000
> > [ 126.181088]
> >
> > After applying this patch to fix HugeTLB support on sun4u, the backtrace during boot changes to:
> >
> > [ 29.860234] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> > [ 29.860241] rcu: (detected by 0, t=2109 jiffies, g=-1151, q=3 ncpus=1)
> > [ 29.860247] rcu: All QSes seen, last rcu_sched kthread activity 2109 (4294939474-4294937365), jiffies_till_next_fqs=1, root ->qsmask 0x0
> > [ 29.860256] rcu: rcu_sched kthread starved for 2109 jiffies! g-1151 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
> > [ 29.860263] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
> > [ 29.860266] rcu: RCU grace-period kthread stack dump:
> > [ 29.860269] task:rcu_sched state:R running task stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x07000000
> > [ 29.860285] Call Trace:
> > [ 29.860288] [<0000000000c0a2f4>] schedule+0x14/0x160
> > [ 29.860305] [<0000000000c11254>] schedule_timeout+0x54/0xe0
> > [ 29.860317] [<00000000004fbe00>] rcu_gp_fqs_loop+0x140/0x6c0
> > [ 29.860329] [<00000000005000fc>] rcu_gp_kthread+0x23c/0x2a0
> > [ 29.860338] [<000000000049b848>] kthread+0xe8/0x120
> > [ 29.860347] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
> > [ 29.860359] [<0000000000000000>] 0x0
> > [ 29.860364] rcu: Stack dump where RCU GP kthread last ran:
> > [ 29.860368] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #33 VOLUNTARY
> > [ 29.860378] TSTATE: 0000004411001603 TPC: 00000000004db4c0 TNPC: 00000000004db4c4 Y: 00001390 Not tainted
> > [ 29.860383] TPC: <console_flush_all+0x360/0x4c0>
> > [ 29.860397] g0: 00000000004db4c0 g1: 0000000000000000 g2: 0000000000000000 g3: 00000000017fd000
> > [ 29.860401] g4: fff0000000180000 g5: fff000023d194000 g6: fff0000000158000 g7: 000000000000000e
> > [ 29.860406] o0: 00000000017fd1e0 o1: 0000000000000000 o2: 0000000000000000 o3: 00000000017fc5d0
> > [ 29.860411] o4: 0000000000000000 o5: 000000000185d7e8 sp: fff000000015a901 ret_pc: 00000000004db4b0
> > [ 29.860415] RPC: <console_flush_all+0x350/0x4c0>
> > [ 29.860423] l0: 00000000017fc5d0 l1: 0000000000000000 l2: 0000000000000000 l3: 000000000143b538
> > [ 29.860427] l4: 0000000000000000 l5: 0000000000000001 l6: 00000000015c20b0 l7: 0000000001536308
> > [ 29.860432] i0: 0000000000000000 i1: fff000000015b2b8 i2: fff000000015b2b3 i3: 0000000000000000
> > [ 29.860436] i4: 00000000017fd1e0 i5: 0000000000000001 i6: fff000000015aa01 i7: 00000000004db6a8
> > [ 29.860441] I7: <console_unlock+0x88/0x120>
> > [ 29.860449] Call Trace:
> > [ 29.860451] [<00000000004db6a8>] console_unlock+0x88/0x120
> > [ 29.860459] [<00000000004dc1e8>] vprintk_emit+0x1e8/0x280
> > [ 29.860467] [<000000000042a34c>] _printk+0x20/0x30
> > [ 29.860477] [<00000000004dc72c>] register_console+0x34c/0x580
> > [ 29.860485] [<0000000000920418>] serial_core_register_port+0x898/0x8c0
> > [ 29.860493] [<000000000092561c>] su_probe+0x15c/0x3e0
> > [ 29.860502] [<0000000000936e48>] platform_probe+0x28/0x80
> > [ 29.860509] [<00000000009343f8>] really_probe+0xb8/0x340
> > [ 29.860521] [<0000000000934824>] driver_probe_device+0x24/0x120
> > [ 29.860529] [<0000000000934acc>] __driver_attach+0x8c/0x1a0
> > [ 29.860537] [<00000000009323ec>] bus_for_each_dev+0x4c/0xa0
> > [ 29.860544] [<0000000000933728>] bus_add_driver+0x148/0x220
> > [ 29.860552] [<00000000009356f4>] driver_register+0x74/0x120
> > [ 29.860560] [<0000000001635e3c>] sunsu_init+0x180/0x1dc
> > [ 29.860572] [<00000000004347b0>] do_one_initcall+0x30/0x240
> > [ 29.860581] [<000000000160d014>] kernel_init_freeable+0x244/0x2b
> >
> > while the backtrace produced when apt hangs is:
> >
> > [ 337.599490] ------------[ cut here ]------------
> > [ 337.660412] WARNING: CPU: 0 PID: 895 at fs/ext4/extents_status.c:298 __es_find_extent_range+0x128/0x140
> > [ 337.784523] Modules linked in: sg sr_mod cdrom sym53c8xx tg3 libphy mdio_bus
> > [ 337.877302] CPU: 0 UID: 0 PID: 895 Comm: apt Not tainted 6.16.0+ #33 VOLUNTARY
> > [ 337.877314] Call Trace:
> > [ 337.877316] [<000000000047286c>] __warn+0x10c/0x120
> > [ 337.877326] [<0000000000472910>] warn_slowpath_fmt+0x90/0x120
> > [ 337.877332] [<0000000000748988>] __es_find_extent_range+0x128/0x140
> > [ 337.877341] [<00000000007490f0>] ext4_es_find_extent_range+0x50/0x100
> > [ 337.877348] [<0000000000742a1c>] ext4_ext_map_blocks+0x7fc/0x22a0
> > [ 337.877355] [<00000000007578d0>] ext4_map_query_blocks+0x30/0x2a0
> > [ 337.877366] [<00000000007596a0>] ext4_da_get_block_prep+0x380/0x640
> > [ 337.877375] [<000000000075ecf4>] ext4_block_write_begin+0x294/0x480
> > [ 337.877382] [<00000000007625d8>] ext4_da_write_begin+0x158/0x300
> > [ 337.877389] [<00000000005b856c>] generic_perform_write+0x8c/0x240
> > [ 337.877399] [<000000000074aef0>] ext4_buffered_write_iter+0x50/0x120
> > [ 337.877406] [<00000000006954e0>] vfs_write+0x2a0/0x400
> > [ 337.877415] [<0000000000695784>] ksys_write+0x44/0xe0
> > [ 337.877421] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
> > [ 337.877433] ---[ end trace 0000000000000000 ]---
> > [ 339.153555] ------------[ cut here ]------------
> > [ 339.214459] WARNING: CPU: 0 PID: 895 at fs/ext4/extents_status.c:298 __es_find_extent_range+0x128/0x140
> > [ 339.338108] Modules linked in: sg sr_mod cdrom sym53c8xx tg3 libphy mdio_bus
> > [ 339.430869] CPU: 0 UID: 0 PID: 895 Comm: apt Tainted: G W 6.16.0+ #33 VOLUNTARY
> > [ 339.430880] Tainted: [W]=WARN
> > [ 339.430883] Call Trace:
> > [ 339.430886] [<000000000047286c>] __warn+0x10c/0x120
> > [ 339.430894] [<0000000000472910>] warn_slowpath_fmt+0x90/0x120
> > [ 339.430900] [<0000000000748988>] __es_find_extent_range+0x128/0x140
> > [ 339.430907] [<00000000007490f0>] ext4_es_find_extent_range+0x50/0x100
> > [ 339.430915] [<0000000000742a1c>] ext4_ext_map_blocks+0x7fc/0x22a0
> > [ 339.430921] [<00000000007578d0>] ext4_map_query_blocks+0x30/0x2a0
> > [ 339.430931] [<00000000007597d4>] ext4_da_get_block_prep+0x4b4/0x640
> > [ 339.430940] [<000000000075ecf4>] ext4_block_write_begin+0x294/0x480
> > [ 339.430948] [<00000000007625d8>] ext4_da_write_begin+0x158/0x300
> > [ 339.430954] [<00000000005b856c>] generic_perform_write+0x8c/0x240
> > [ 339.430964] [<000000000074aef0>] ext4_buffered_write_iter+0x50/0x120
> > [ 339.430971] [<00000000006954e0>] vfs_write+0x2a0/0x400
> > [ 339.430979] [<0000000000695784>] ksys_write+0x44/0xe0
> > [ 339.430985] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
> > [ 339.430996] ---[ end trace 0000000000000000 ]---
> >
> > So, I guess while your patch may fix HugeTLB support, there is still a bug on sun4u with THP
> > which needs to be addressed.
>
> Maybe try enabling CONFIG_DEBUG_VM_IRQSOFF, CONFIG_DEBUG_VM, and perhaps
> CONFIG_DEBUG_VM_PGFLAGS. That might help detect a problem closer to the
> source. You can also try adding transparent_hugepage=never to the kernel
> boot line to see if compiling in THP support but not using it is okay.
OK, I will try that. But not today anymore. It's half past midnight now here in Germany
and I was debugging this issue almost all day long. I'm glad to have finally been able
to track this down to THP support being enabled.
Maybe you can try whether you can reproduce this in QEMU as well.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-08 22:37 ` John Paul Adrian Glaubitz
@ 2025-08-09 6:23 ` John Paul Adrian Glaubitz
2025-08-09 6:26 ` John Paul Adrian Glaubitz
2025-08-11 8:20 ` David Hildenbrand
0 siblings, 2 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-09 6:23 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Sat, 2025-08-09 at 00:37 +0200, John Paul Adrian Glaubitz wrote:
> > Maybe try enabling CONFIG_DEBUG_VM_IRQSOFF, CONFIG_DEBUG_VM, and perhaps
> > CONFIG_DEBUG_VM_PGFLAGS. That might help detect a problem closer to the
> > source. You can also try adding transparent_hugepage=never to the kernel
> > boot line to see if compiling in THP support but not using it is okay.
>
> OK, I will try that. But not today anymore. It's half past midnight now here in Germany
> and I was debugging this issue almost all day long. I'm glad to have finally been able
> to track this down to THP support being enabled.
>
> Maybe you can try whether you can reproduce this in QEMU as well.
OK, first data point: Setting CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y causes the backtrace during
boot to disappear with CONFIG_TRANSPARENT_HUGEPAGE=y. However, it still disappears later when
running "apt update && apt -y upgrade" again:
[ 170.472743] kernel BUG at fs/ext4/inode.c:1174!
[ 170.532313] \|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
[ 170.725707] apt(1085): Kernel bad sw trap 5 [#1]
[ 170.786396] CPU: 0 UID: 0 PID: 1085 Comm: apt Not tainted 6.16.0+ #35 VOLUNTARY
[ 170.883619] TSTATE: 0000004411001603 TPC: 000000000075ee68 TNPC: 000000000075ee6c Y: 00000000 Not tainted
[ 171.012868] TPC: <ext4_block_write_begin+0x408/0x480>
[ 171.079299] g0: 0000000000000000 g1: 0000000000000001 g2: 0000000000000000 g3: 0000000000000000
[ 171.193692] g4: fff0000007802340 g5: fff000023d194000 g6: fff0000004aa8000 g7: 0000000000000001
[ 171.308157] o0: 0000000000000023 o1: 0000000000d74b28 o2: 0000000000000496 o3: 0000000000101cca
[ 171.422531] o4: 0000000001568800 o5: 0000000000000000 sp: fff0000004aab161 ret_pc: 000000000075ee60
[ 171.541487] RPC: <ext4_block_write_begin+0x400/0x480>
[ 171.607814] l0: fff000000274c6a8 l1: 0000000000113cca l2: fff000000274c540 l3: 0000000000001000
[ 171.722195] l4: 0000000000000002 l5: 0000000000080000 l6: 0000000000012000 l7: 0000000000000001
[ 171.836568] i0: 0000000000000000 i1: 000c000000374400 i2: 0000000000001fc0 i3: 0000000000680000
[ 171.950944] i4: 0000000000000000 i5: 0000000000000000 i6: fff0000004aab251 i7: 00000000007625d8
[ 172.065317] I7: <ext4_da_write_begin+0x158/0x300>
[ 172.127075] Call Trace:
[ 172.159101] [<00000000007625d8>] ext4_da_write_begin+0x158/0x300
[ 172.238023] [<00000000005b856c>] generic_perform_write+0x8c/0x240
[ 172.318085] [<000000000074aef0>] ext4_buffered_write_iter+0x50/0x120
[ 172.401586] [<00000000006954e0>] vfs_write+0x2a0/0x400
[ 172.469059] [<0000000000695784>] ksys_write+0x44/0xe0
[ 172.535395] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
[ 172.612029] Disabling lock debugging due to kernel taint
[ 172.681796] Caller[00000000007625d8]: ext4_da_write_begin+0x158/0x300
[ 172.766430] Caller[00000000005b856c]: generic_perform_write+0x8c/0x240
[ 172.852213] Caller[000000000074aef0]: ext4_buffered_write_iter+0x50/0x120
[ 172.941429] Caller[00000000006954e0]: vfs_write+0x2a0/0x400
[ 173.014627] Caller[0000000000695784]: ksys_write+0x44/0xe0
[ 173.086684] Caller[0000000000406274]: linux_sparc_syscall+0x34/0x44
[ 173.169033] Caller[0000000000000000]: 0x0
[ 173.221645] Instruction DUMP:
[ 173.221648] 110035d2
[ 173.260532] 7ff358e0
[ 173.291414] 90122328
[ 173.322289] <91d02005>
[ 173.353172] 80a06000
[ 173.384051] 02480010
[ 173.414937] d45fa7cf
[ 173.445815] d85fa7cf
[ 173.476697] 9736a000
So, even just compiling in the THP support code already triggers the bug.
Will now test with the debug flags enabled.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-09 6:23 ` John Paul Adrian Glaubitz
@ 2025-08-09 6:26 ` John Paul Adrian Glaubitz
2025-08-09 6:42 ` John Paul Adrian Glaubitz
2025-08-11 8:20 ` David Hildenbrand
1 sibling, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-09 6:26 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
On Sat, 2025-08-09 at 08:23 +0200, John Paul Adrian Glaubitz wrote:
> Hi Anthony,
>
> On Sat, 2025-08-09 at 00:37 +0200, John Paul Adrian Glaubitz wrote:
> > > Maybe try enabling CONFIG_DEBUG_VM_IRQSOFF, CONFIG_DEBUG_VM, and perhaps
> > > CONFIG_DEBUG_VM_PGFLAGS. That might help detect a problem closer to the
> > > source. You can also try adding transparent_hugepage=never to the kernel
> > > boot line to see if compiling in THP support but not using it is okay.
> >
> > OK, I will try that. But not today anymore. It's half past midnight now here in Germany
> > and I was debugging this issue almost all day long. I'm glad to have finally been able
> > to track this down to THP support being enabled.
> >
> > Maybe you can try whether you can reproduce this in QEMU as well.
>
> OK, first data point: Setting CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y causes the backtrace during
> boot to disappear with CONFIG_TRANSPARENT_HUGEPAGE=y. However, it still disappears later when
> running "apt update && apt -y upgrade" again:
That was meant to say "it appears later", of course.
So, again. No backtrace during boot with CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y but later when
running apt.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-09 6:26 ` John Paul Adrian Glaubitz
@ 2025-08-09 6:42 ` John Paul Adrian Glaubitz
2025-08-10 9:52 ` John Paul Adrian Glaubitz
0 siblings, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-09 6:42 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Sat, 2025-08-09 at 08:26 +0200, John Paul Adrian Glaubitz wrote:
> > OK, first data point: Setting CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y causes the backtrace during
> > boot to disappear with CONFIG_TRANSPARENT_HUGEPAGE=y. However, it still disappears later when
> > running "apt update && apt -y upgrade" again:
>
> That was meant to say "it appears later", of course.
>
> So, again. No backtrace during boot with CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y but later when
> running apt.
Here is the full dmesg output with CONFIG_DEBUG_VM, CONFIG_DEBUG_VM_IRQSOFF and CONFIG_DEBUG_VM_PGFLAGS
enabled. Caputuring the backtrace after running up was not possible as the machine locked up completely.
[ 0.000028] PROMLIB: Sun IEEE Boot Prom 'OBP 4.22.33 2007/06/18 12:45'
[ 0.000050] PROMLIB: Root node compatible:
[ 0.000121] Linux version 6.16.0+ (glaubitz@node54) (sparc64-suse-linux-gcc (SUSE Linux) 11.3.0, GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.43.1.20241209-150100.7.52) #36 SMP Sat Aug 9
06:19:23 UTC 2025
[ 0.000201] printk: legacy bootconsole [earlyprom0] enabled
[ 0.418616] ARCH: SUN4U
[ 0.447856] Ethernet address: 00:03:ba:15:17:4e
[ 0.502076] MM: PAGE_OFFSET is 0xfff0000000000000 (max_phys_bits == 42)
[ 0.581235] MM: VMALLOC [0x0000000100000000 --> 0x000c000000000000]
[ 0.656203] MM: VMEMMAP [0x000c000000000000 --> 0x0018000000000000]
[ 0.755106] Kernel: Using 6 locked TLB entries for main kernel image.
[ 0.832144] Remapping the kernel...
[ 0.832784] done.
[ 1.069989] OF stdout device is: /pci@1e,600000/isa@7/serial@0,3f8
[ 1.143962] PROM: Built device tree with 138544 bytes of memory.
[ 1.219257] NODE_DATA(0) allocated [mem 0x23fe72340-0x23fe73dff]
[ 1.368961] Allocated 24576 bytes for kernel page tables.
[ 1.433729] Zone ranges:
[ 1.464003] Normal [mem 0x0000000000000000-0x000000023fec9fff]
[ 1.537931] Movable zone start for each node
[ 1.588983] Early memory node ranges
[ 1.631717] node 0: [mem 0x0000000000000000-0x000000003fffffff]
[ 1.706687] node 0: [mem 0x0000000200000000-0x000000023effdfff]
[ 1.781654] node 0: [mem 0x000000023f000000-0x000000023fd9ffff]
[ 1.856620] node 0: [mem 0x000000023fdb0000-0x000000023fdc5fff]
[ 1.931588] node 0: [mem 0x000000023fdca000-0x000000023fe99fff]
[ 2.006556] node 0: [mem 0x000000023fea0000-0x000000023feaffff]
[ 2.081524] node 0: [mem 0x000000023fec4000-0x000000023fec9fff]
[ 2.156494] Initmem setup node 0 [mem 0x0000000000000000-0x000000023fec9fff]
[ 2.241080] Initmem setup node 1 as memoryless
[ 2.294511] Initmem setup node 2 as memoryless
[ 2.347954] Initmem setup node 3 as memoryless
[ 2.401400] Initmem setup node 4 as memoryless
[ 2.454845] Initmem setup node 5 as memoryless
[ 2.508289] Initmem setup node 6 as memoryless
[ 2.561732] Initmem setup node 7 as memoryless
[ 2.615175] Initmem setup node 8 as memoryless
[ 2.668617] Initmem setup node 9 as memoryless
[ 2.722063] Initmem setup node 10 as memoryless
[ 2.776548] Initmem setup node 11 as memoryless
[ 2.831030] Initmem setup node 12 as memoryless
[ 2.885514] Initmem setup node 13 as memoryless
[ 2.939999] Initmem setup node 14 as memoryless
[ 2.994484] Initmem setup node 15 as memoryless
[ 3.048968] Initmem setup node 16 as memoryless
[ 3.103453] Initmem setup node 17 as memoryless
[ 3.157935] Initmem setup node 18 as memoryless
[ 3.212420] Initmem setup node 19 as memoryless
[ 3.266905] Initmem setup node 20 as memoryless
[ 3.321388] Initmem setup node 21 as memoryless
[ 3.375871] Initmem setup node 22 as memoryless
[ 3.430356] Initmem setup node 23 as memoryless
[ 3.484838] Initmem setup node 24 as memoryless
[ 3.539324] Initmem setup node 25 as memoryless
[ 3.593810] Initmem setup node 26 as memoryless
[ 3.648293] Initmem setup node 27 as memoryless
[ 3.702778] Initmem setup node 28 as memoryless
[ 3.757261] Initmem setup node 29 as memoryless
[ 3.811744] Initmem setup node 30 as memoryless
[ 3.866229] Initmem setup node 31 as memoryless
[ 3.960015] On node 0, zone Normal: 1 pages in unavailable ranges
[ 4.032976] On node 0, zone Normal: 8 pages in unavailable ranges
[ 4.105874] On node 0, zone Normal: 2 pages in unavailable ranges
[ 4.178749] On node 0, zone Normal: 3 pages in unavailable ranges
[ 4.251637] On node 0, zone Normal: 10 pages in unavailable ranges
[ 4.325587] On node 0, zone Normal: 155 pages in unavailable ranges
[ 4.400532] Booting Linux...
[ 4.434948] CPU CAPS: [flush,stbar,swap,muldiv,v9,ultra3,mul32,div32]
[ 4.511993] CPU CAPS: [v8plus,vis,vis2]
[ 4.564722] percpu: Embedded 14 pages/cpu s74968 r8192 d31528 u4194304
[ 4.643756] pcpu-alloc: s74968 r8192 d31528 u4194304 alloc=1*4194304
[ 4.643771] pcpu-alloc: [0] 0
[ 4.646285] Kernel command line: BOOT_IMAGE=/vmlinux-6.16.0+ root=UUID=a8314d10-9c39-438b-9dc4-9db2e05a6530 ro
[ 4.766302] Unknown kernel command line parameters "BOOT_IMAGE=/vmlinux-6.16.0+", will be passed to user space.
[ 4.887097] printk: log buffer data + meta data: 262144 + 917504 = 1179648 bytes
[ 4.978119] Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes, linear)
[ 5.073189] Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes, linear)
[ 5.165908] Sorting __ex_table...
[ 5.206168] Fallback order for Node 0: 0
[ 5.206180] Fallback order for Node 1: 0
[ 5.206187] Fallback order for Node 2: 0
[ 5.206192] Fallback order for Node 3: 0
[ 5.206198] Fallback order for Node 4: 0
[ 5.206203] Fallback order for Node 5: 0
[ 5.206209] Fallback order for Node 6: 0
[ 5.206214] Fallback order for Node 7: 0
[ 5.206220] Fallback order for Node 8: 0
[ 5.206225] Fallback order for Node 9: 0
[ 5.206231] Fallback order for Node 10: 0
[ 5.206237] Fallback order for Node 11: 0
[ 5.206243] Fallback order for Node 12: 0
[ 5.206248] Fallback order for Node 13: 0
[ 5.206254] Fallback order for Node 14: 0
[ 5.206259] Fallback order for Node 15: 0
[ 5.206265] Fallback order for Node 16: 0
[ 5.206271] Fallback order for Node 17: 0
[ 5.206277] Fallback order for Node 18: 0
[ 5.206282] Fallback order for Node 19: 0
[ 5.206288] Fallback order for Node 20: 0
[ 5.206293] Fallback order for Node 21: 0
[ 5.206299] Fallback order for Node 22: 0
[ 5.206304] Fallback order for Node 23: 0
[ 5.206310] Fallback order for Node 24: 0
[ 5.206315] Fallback order for Node 25: 0
[ 5.206321] Fallback order for Node 26: 0
[ 5.206326] Fallback order for Node 27: 0
[ 5.206332] Fallback order for Node 28: 0
[ 5.206338] Fallback order for Node 29: 0
[ 5.206343] Fallback order for Node 30: 0
[ 5.206348] Fallback order for Node 31: 0
[ 5.206357] Built 1 zonelists, mobility grouping on. Total pages: 261965
[ 6.844310] Policy zone: Normal
[ 6.881848] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 7.009331] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=32
[ 7.089245] rcu: Hierarchical RCU implementation.
[ 7.145533] rcu: RCU event tracing is enabled.
[ 7.199704] rcu: RCU restricting CPUs from NR_CPUS=4096 to nr_cpu_ids=1.
[ 7.280912] Tracing variant of Tasks RCU enabled.
[ 7.338203] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 7.428765] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[ 7.508955] RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=1.
[ 7.625622] NR_IRQS: 2048, nr_irqs: 2048, preallocated irqs: 1
[ 7.695587] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 7.777833] clocksource: stick: mask: 0xffffffffffffffff max_cycles: 0x2c47f4ee7, max_idle_ns: 440795202497 ns
[ 7.897497] clocksource: mult[53555555] shift[24]
[ 7.953748] clockevent: mult[3126e98] shift[32]
[ 8.008060] Console: colour dummy device 80x25
[ 8.061290] printk: legacy console [tty0] enabled
[ 8.117620] printk: legacy bootconsole [earlyprom0] disabled
[ 8.335327] Calibrating delay using timer specific routine.. 24.00 BogoMIPS (lpj=120039)
[ 8.335348] pid_max: default: 32768 minimum: 301
[ 8.335566] Mount-cache hash table entries: 4096 (order: 2, 32768 bytes, linear)
[ 8.335605] Mountpoint-cache hash table entries: 4096 (order: 2, 32768 bytes, linear)
[ 8.337722] rcu: Hierarchical SRCU implementation.
[ 8.337743] rcu: Max phase no-delay instances is 1000.
[ 8.338177] smp: Bringing up secondary CPUs ...
[ 8.338199] smp: Brought up 1 node, 1 CPU
[ 8.338434] Memory: 2022448K/2095720K available (8391K kernel code, 8021K rwdata, 2168K rodata, 472K init, 1938K bss, 68552K reserved, 0K cma-reserved)
[ 8.338861] devtmpfs: initialized
[ 8.341519] Performance events:
[ 8.341529] Testing NMI watchdog ...
[ 8.541542] OK.
[ 8.541580] Supported PMU type is 'ultra3i'
[ 8.541914] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 8.541978] posixtimers hash table entries: 512 (order: 0, 8192 bytes, linear)
[ 8.542061] futex hash table entries: 8 (512 bytes on 32 NUMA nodes, total 16 KiB, linear).
[ 8.542730] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 8.543663] IRQ pre handler NOT supported.
[ 8.543695] IRQ pre handler NOT supported.
[ 8.543713] IRQ pre handler NOT supported.
[ 8.543730] IRQ pre handler NOT supported.
[ 8.543746] IRQ pre handler NOT supported.
[ 8.543827] IRQ pre handler NOT supported.
[ 8.543906] IRQ pre handler NOT supported.
[ 8.543983] IRQ pre handler NOT supported.
[ 8.544001] IRQ pre handler NOT supported.
[ 8.544018] IRQ pre handler NOT supported.
[ 8.544034] IRQ pre handler NOT supported.
[ 8.544050] IRQ pre handler NOT supported.
[ 8.544269] IRQ pre handler NOT supported.
[ 8.545176] IRQ pre handler NOT supported.
[ 8.545289] IRQ pre handler NOT supported.
[ 8.545355] IRQ pre handler NOT supported.
[ 8.545485] IRQ pre handler NOT supported.
[ 8.545626] IRQ pre handler NOT supported.
[ 8.545741] IRQ pre handler NOT supported.
[ 8.545877] IRQ pre handler NOT supported.
[ 8.546041] IRQ pre handler NOT supported.
[ 8.546062] IRQ pre handler NOT supported.
[ 8.546080] IRQ pre handler NOT supported.
[ 8.546097] IRQ pre handler NOT supported.
[ 8.546114] IRQ pre handler NOT supported.
[ 8.546212] IRQ pre handler NOT supported.
[ 8.546378] IRQ pre handler NOT supported.
[ 8.546551] IRQ pre handler NOT supported.
[ 8.546571] IRQ pre handler NOT supported.
[ 8.546589] IRQ pre handler NOT supported.
[ 8.546613] IRQ pre handler NOT supported.
[ 8.546640] IRQ pre handler NOT supported.
[ 8.546719] IRQ pre handler NOT supported.
[ 8.546815] IRQ pre handler NOT supported.
[ 8.548337] pci@1f,700000: TOMATILLO PCI Bus Module ver[4:0]
[ 8.548363] pci@1f,700000: PCI IO [io 0x7f601000000-0x7f601ffffff] offset 7f601000000
[ 8.548384] pci@1f,700000: PCI MEM [mem 0x7f700000000-0x7f7ffffffff] offset 7f700000000
[ 8.549720] PCI: Scanning PBM /pci@1f,700000
[ 8.549964] schizo f0068950: PCI host bridge to bus 0000:00
[ 8.549986] pci_bus 0000:00: Unknown NUMA node; performance will be reduced
[ 8.550007] pci_bus 0000:00: root bus resource [io 0x7f601000000-0x7f601ffffff] (bus address [0x0000-0xffffff])
[ 8.550030] pci_bus 0000:00: root bus resource [mem 0x7f700000000-0x7f7ffffffff] (bus address [0x00000000-0xffffffff])
[ 8.550052] pci_bus 0000:00: root bus resource [bus 00]
[ 8.550105] pci 0000:00:02.0: [14e4:1648] type 00 class 0x020000
[ 8.550122] pci 0000:00:02.0: reg 0x10: [mem 0x7f700200000-0x7f7003fffff 64bit]
[ 8.550142] pci 0000:00:02.0: reg 0x18: [mem 0x7f700000000-0x7f70000ffff 64bit]
[ 8.550206] pci 0000:00:02.0: PME# supported from D3hot
[ 8.550357] pci 0000:00:02.1: [14e4:1648] type 00 class 0x020000
[ 8.550376] pci 0000:00:02.1: reg 0x10: [mem 0x7f700400000-0x7f7005fffff 64bit]
[ 8.550395] pci 0000:00:02.1: reg 0x18: [mem 0x7f700000000-0x7f70000ffff 64bit]
[ 8.550442] pci 0000:00:02.1: PME# supported from D3hot
[ 8.550570] pci 0000:00:02.1: BAR 2 [mem 0x7f700000000-0x7f70000ffff 64bit]: can't claim; address conflict with 0000:00:02.0 [mem 0x7f700000000-0x7f70000ffff 64bit]
[ 8.550774] pci@1e,600000: TOMATILLO PCI Bus Module ver[4:0]
[ 8.550793] pci@1e,600000: PCI IO [io 0x7fe01000000-0x7fe01ffffff] offset 7fe01000000
[ 8.550811] pci@1e,600000: PCI MEM [mem 0x7ff00000000-0x7ffffffffff] offset 7ff00000000
[ 8.552155] PCI: Scanning PBM /pci@1e,600000
[ 8.552712] schizo f0071294: PCI host bridge to bus 0001:00
[ 8.552731] pci_bus 0001:00: Unknown NUMA node; performance will be reduced
[ 8.552751] pci_bus 0001:00: root bus resource [io 0x7fe01000000-0x7fe01ffffff] (bus address [0x0000-0xffffff])
[ 8.552774] pci_bus 0001:00: root bus resource [mem 0x7ff00000000-0x7ffffffffff] (bus address [0x00000000-0xffffffff])
[ 8.552796] pci_bus 0001:00: root bus resource [bus 00]
[ 8.552845] pci 0001:00:07.0: [10b9:1533] type 00 class 0x060100
[ 8.552863] pci 0001:00:07.0: reg 0x10: [io 0x7fe01000000-0x7fe0100ffff]
[ 8.552879] pci 0001:00:07.0: reg 0x14: [mem 0x7ff00000000-0x7ff000fffff]
[ 8.552895] pci 0001:00:07.0: reg 0x18: [mem 0x7ff00000000-0x7ff000fffff]
[ 8.553081] pci 0001:00:06.0: [10b9:7101] type 00 class 0x000000
[ 8.553100] pci 0001:00:06.0: reg 0x10: [io 0x7fe01000000-0x7fe0100000f]
[ 8.553128] pci 0001:00:06.0: quirk: [io 0x7fe01000800-0x7fe0100083f] claimed by ali7101 ACPI
[ 8.553149] pci 0001:00:06.0: quirk: [io 0x7fe01000600-0x7fe0100061f] claimed by ali7101 SMB
[ 8.553277] pci 0001:00:0a.0: [10b9:5237] type 00 class 0x0c0310
[ 8.553295] pci 0001:00:0a.0: reg 0x10: [mem 0x7ff01000000-0x7ff01ffffff]
[ 8.553331] pci 0001:00:0a.0: PME# supported from D3cold
[ 8.553466] pci 0001:00:0d.0: [10b9:5229] type 00 class 0x0101ff
[ 8.553484] pci 0001:00:0d.0: reg 0x10: [io 0x7fe01000900-0x7fe01000907]
[ 8.553501] pci 0001:00:0d.0: reg 0x14: [io 0x7fe01000918-0x7fe0100091f]
[ 8.553517] pci 0001:00:0d.0: reg 0x18: [io 0x7fe01000910-0x7fe01000917]
[ 8.553532] pci 0001:00:0d.0: reg 0x1c: [io 0x7fe01000908-0x7fe0100090f]
[ 8.553547] pci 0001:00:0d.0: reg 0x20: [io 0x7fe01000920-0x7fe0100092f]
[ 8.553671] pci 0001:00:07.0: BAR 0 [io 0x7fe01000000-0x7fe0100ffff]: can't claim; address conflict with 0001:00:06.0 [io 0x7fe01000600-0x7fe0100061f]
[ 8.553699] pci 0001:00:07.0: BAR 2 [mem 0x7ff00000000-0x7ff000fffff]: can't claim; address conflict with 0001:00:07.0 [mem 0x7ff00000000-0x7ff000fffff]
[ 8.553939] pci@1c,600000: TOMATILLO PCI Bus Module ver[4:0]
[ 8.553959] pci@1c,600000: PCI IO [io 0x7ce01000000-0x7ce01ffffff] offset 7ce01000000
[ 8.553976] pci@1c,600000: PCI MEM [mem 0x7cf00000000-0x7cfffffffff] offset 7cf00000000
[ 8.555350] PCI: Scanning PBM /pci@1c,600000
[ 8.555726] schizo f00798e4: PCI host bridge to bus 0002:00
[ 8.555749] pci_bus 0002:00: Unknown NUMA node; performance will be reduced
[ 8.555769] pci_bus 0002:00: root bus resource [io 0x7ce01000000-0x7ce01ffffff] (bus address [0x0000-0xffffff])
[ 8.555793] pci_bus 0002:00: root bus resource [mem 0x7cf00000000-0x7cfffffffff] (bus address [0x00000000-0xffffffff])
[ 8.555814] pci_bus 0002:00: root bus resource [bus 00]
[ 8.555879] pci 0002:00:02.0: [1000:0021] type 00 class 0x010000
[ 8.555897] pci 0002:00:02.0: reg 0x10: [io 0x7ce01000900-0x7ce010009ff]
[ 8.555913] pci 0002:00:02.0: reg 0x14: [mem 0x7cf00100000-0x7cf00101fff 64bit]
[ 8.555931] pci 0002:00:02.0: reg 0x1c: [mem 0x7cf00102000-0x7cf00103fff 64bit]
[ 8.555977] pci 0002:00:02.0: supports D1 D2
[ 8.556122] pci 0002:00:02.1: [1000:0021] type 00 class 0x010000
[ 8.556141] pci 0002:00:02.1: reg 0x10: [io 0x7ce01000a00-0x7ce01000aff]
[ 8.556157] pci 0002:00:02.1: reg 0x14: [mem 0x7cf00104000-0x7cf00105fff 64bit]
[ 8.556175] pci 0002:00:02.1: reg 0x1c: [mem 0x7cf00106000-0x7cf00107fff 64bit]
[ 8.556212] pci 0002:00:02.1: supports D1 D2
[ 8.556525] pci@1d,700000: TOMATILLO PCI Bus Module ver[4:0]
[ 8.556545] pci@1d,700000: PCI IO [io 0x7c601000000-0x7c601ffffff] offset 7c601000000
[ 8.556563] pci@1d,700000: PCI MEM [mem 0x7c700000000-0x7c7ffffffff] offset 7c700000000
[ 8.557937] PCI: Scanning PBM /pci@1d,700000
[ 8.558160] schizo f0081e80: PCI host bridge to bus 0003:00
[ 8.558181] pci_bus 0003:00: Unknown NUMA node; performance will be reduced
[ 8.558201] pci_bus 0003:00: root bus resource [io 0x7c601000000-0x7c601ffffff] (bus address [0x0000-0xffffff])
[ 8.558223] pci_bus 0003:00: root bus resource [mem 0x7c700000000-0x7c7ffffffff] (bus address [0x00000000-0xffffffff])
[ 8.558245] pci_bus 0003:00: root bus resource [bus 00]
[ 8.558316] pci 0003:00:02.0: [14e4:1648] type 00 class 0x020000
[ 8.558334] pci 0003:00:02.0: reg 0x10: [mem 0x7c700200000-0x7c7003fffff 64bit]
[ 8.558353] pci 0003:00:02.0: reg 0x18: [mem 0x7c700000000-0x7c70000ffff 64bit]
[ 8.558410] pci 0003:00:02.0: PME# supported from D3hot
[ 8.558566] pci 0003:00:02.1: [14e4:1648] type 00 class 0x020000
[ 8.558585] pci 0003:00:02.1: reg 0x10: [mem 0x7c700400000-0x7c7005fffff 64bit]
[ 8.558604] pci 0003:00:02.1: reg 0x18: [mem 0x7c700000000-0x7c70000ffff 64bit]
[ 8.558651] pci 0003:00:02.1: PME# supported from D3hot
[ 8.558779] pci 0003:00:02.1: BAR 2 [mem 0x7c700000000-0x7c70000ffff 64bit]: can't claim; address conflict with 0003:00:02.0 [mem 0x7c700000000-0x7c70000ffff 64bit]
[ 8.570029] HugeTLB: allocation took 0ms with hugepage_allocation_threads=1
[ 8.570056] HugeTLB: allocation took 0ms with hugepage_allocation_threads=1
[ 8.570076] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages
[ 8.570090] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page
[ 8.570103] HugeTLB: registered 8.00 MiB page size, pre-allocated 0 pages
[ 8.570116] HugeTLB: 0 KiB vmemmap can be freed for a 8.00 MiB page
[ 8.570129] HugeTLB: registered 256 MiB page size, pre-allocated 0 pages
[ 8.570141] HugeTLB: 0 KiB vmemmap can be freed for a 256 MiB page
[ 8.570155] HugeTLB: registered 2.00 GiB page size, pre-allocated 0 pages
[ 8.570167] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 GiB page
[ 8.587788] SCSI subsystem initialized
[ 8.587928] libata version 3.00 loaded.
[ 8.588013] usbcore: registered new interface driver usbfs
[ 8.588066] usbcore: registered new interface driver hub
[ 8.588101] usbcore: registered new device driver usb
[ 8.588167] pps_core: LinuxPPS API ver. 1 registered
[ 8.588180] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 8.588205] PTP clock support registered
[ 8.588879] vgaarb: loaded
[ 8.589063] /pci@1e,600000/isa@7/rtc@0,70: RTC regs at 0x7fe01000070
[ 8.589831] clocksource: Switched to clocksource stick
[ 8.693105] NET: Registered PF_INET protocol family
[ 8.693447] IP idents hash table entries: 32768 (order: 5, 262144 bytes, linear)
[ 8.695838] tcp_listen_portaddr_hash hash table entries: 1024 (order: 1, 16384 bytes, linear)
[ 8.695906] Table-perturb hash table entries: 65536 (order: 5, 262144 bytes, linear)
[ 8.695937] TCP established hash table entries: 16384 (order: 4, 131072 bytes, linear)
[ 8.696219] TCP bind hash table entries: 16384 (order: 6, 524288 bytes, linear)
[ 8.697521] TCP: Hash tables configured (established 16384 bind 16384)
[ 8.697690] UDP hash table entries: 1024 (order: 3, 65536 bytes, linear)
[ 8.697860] UDP-Lite hash table entries: 1024 (order: 3, 65536 bytes, linear)
[ 8.698208] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 8.698334] pci 0001:00:0a.0: enabling device (0000 -> 0002)
[ 8.698403] PCI: CLS 64 bytes, default 64
[ 8.698583] Unpacking initramfs...
[ 8.700064] power: Control reg at 7fe01000800
[ 8.700466] chmc: UltraSPARC-IIIi memory controller at /memory-controller@0,0
[ 8.701174] workingset: timestamp_bits=41 max_order=18 bucket_order=0
[ 8.850311] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[ 8.850359] io scheduler mq-deadline registered
[ 8.850372] io scheduler kyber registered
[ 8.851946] f00a71fc: ttyS0 at MMIO 0x7fe010003f8 (irq = 15, base_baud = 115387) is a 16550A
[ 8.851981] Console: ttyS0 (SU)
[ 8.852015] printk: legacy console [ttyS0] enabled
[ 29.948586] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 29.948592] rcu: (detected by 0, t=2109 jiffies, g=-1151, q=3 ncpus=1)
[ 29.948598] rcu: All QSes seen, last rcu_sched kthread activity 2109 (4294939474-4294937365), jiffies_till_next_fqs=1, root ->qsmask 0x0
[ 29.948607] rcu: rcu_sched kthread starved for 2109 jiffies! g-1151 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
[ 29.948615] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
[ 29.948618] rcu: RCU grace-period kthread stack dump:
[ 29.948621] task:rcu_sched state:R running task stack:0 pid:15 tgid:15 ppid:2 task_flags:0x208040 flags:0x07000000
[ 29.948637] Call Trace:
[ 29.948640] [<0000000000c2bdf4>] schedule+0x14/0x160
[ 29.948654] [<0000000000c32d54>] schedule_timeout+0x54/0xe0
[ 29.948665] [<00000000004fe240>] rcu_gp_fqs_loop+0x140/0x6c0
[ 29.948678] [<000000000050253c>] rcu_gp_kthread+0x23c/0x2a0
[ 29.948686] [<000000000049dc88>] kthread+0xe8/0x120
[ 29.948696] [<00000000004060c8>] ret_from_fork+0x1c/0x2c
[ 29.948709] [<0000000000000000>] 0x0
[ 29.948714] rcu: Stack dump where RCU GP kthread last ran:
[ 29.948718] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0+ #36 VOLUNTARY
[ 29.948727] TSTATE: 0000004411001603 TPC: 00000000004dd900 TNPC: 00000000004dd904 Y: 00001702 Not tainted
[ 29.948733] TPC: <console_flush_all+0x360/0x4c0>
[ 29.948747] g0: 00000000004dd900 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000001821000
[ 29.948752] g4: fff0000000180000 g5: fff000023d170000 g6: fff0000000158000 g7: 000000000000000e
[ 29.948757] o0: 00000000018211e0 o1: 0000000000000000 o2: 0000000000000000 o3: 00000000018205d0
[ 29.948761] o4: 0000000000000000 o5: 00000000018817e8 sp: fff000000015a901 ret_pc: 00000000004dd8f0
[ 29.948766] RPC: <console_flush_all+0x350/0x4c0>
[ 29.948773] l0: 00000000018205d0 l1: 0000000000000000 l2: 0000000000000000 l3: 000000000145f538
[ 29.948778] l4: 0000000000000000 l5: 0000000000000001 l6: 00000000015e60b0 l7: 000000000155a308
[ 29.948783] i0: 0000000000000000 i1: fff000000015b2b8 i2: fff000000015b2b3 i3: 0000000000000000
[ 29.948787] i4: 00000000018211e0 i5: 0000000000000001 i6: fff000000015aa01 i7: 00000000004ddae8
[ 29.948792] I7: <console_unlock+0x88/0x120>
[ 29.948800] Call Trace:
[ 29.948802] [<00000000004ddae8>] console_unlock+0x88/0x120
[ 29.948810] [<00000000004de628>] vprintk_emit+0x1e8/0x280
[ 29.948818] [<000000000042a3a0>] _printk+0x20/0x30
[ 29.948828] [<00000000004deb6c>] register_console+0x34c/0x580
[ 29.948837] [<00000000009416f8>] serial_core_register_port+0x898/0x8c0
[ 29.948849] [<00000000009468fc>] su_probe+0x15c/0x3e0
[ 29.948856] [<00000000009581e8>] platform_probe+0x28/0x80
[ 29.948868] [<0000000000955798>] really_probe+0xb8/0x340
[ 29.948874] [<0000000000955bc4>] driver_probe_device+0x24/0x120
[ 29.948881] [<0000000000955e6c>] __driver_attach+0x8c/0x1a0
[ 29.948888] [<000000000095378c>] bus_for_each_dev+0x4c/0xa0
[ 29.948894] [<0000000000954ac8>] bus_add_driver+0x148/0x220
[ 29.948901] [<0000000000956a94>] driver_register+0x74/0x120
[ 29.948908] [<000000000165a150>] sunsu_init+0x180/0x1dc
[ 29.948917] [<00000000004367b0>] do_one_initcall+0x30/0x240
[ 29.948926] [<0000000001631014>] kernel_init_freeable+0x244/0x2b8
[ 36.081726] Freeing initrd memory: 10872K
[ 36.135456] f00a8d7c: ttyS1 at MMIO 0x7fe010002e8 (irq = 15, base_baud = 115387) is a 16550A
[ 36.247159] pata_ali 0001:00:0d.0: enabling device (0004 -> 0005)
[ 36.328511] scsi host0: pata_ali
[ 36.371269] scsi host1: pata_ali
[ 36.413710] ata1: PATA max UDMA/100 cmd 0x7fe01000900 ctl 0x7fe01000918 bmdma 0x7fe01000920 irq 18 lpm-pol 0
[ 36.542953] ata2: PATA max UDMA/100 cmd 0x7fe01000910 ctl 0x7fe01000908 bmdma 0x7fe01000928 irq 18 lpm-pol 0
[ 36.672814] ohci-pci 0001:00:0a.0: OHCI PCI host controller
[ 36.746038] ohci-pci 0001:00:0a.0: new USB bus registered, assigned bus number 1
[ 36.843611] ohci-pci 0001:00:0a.0: irq 17, io mem 0x7ff01000000
[ 36.921786] ata1.00: ATAPI: TSSTcorpCD/DVDW TS-L532U, SI02, max UDMA/33
[ 37.008775] ata1.00: WARNING: ATAPI DMA disabled for reliability issues. It can be enabled
[ 37.118566] ata1.00: WARNING: via pata_ali.atapi_dma modparam or corresponding sysfs node.
[ 37.231885] hub 1-0:1.0: USB hub found
[ 37.281304] hub 1-0:1.0: 2 ports detected
[ 37.335395] rtc_cmos rtc_cmos: error -ENXIO: IRQ index 0 not found
[ 37.417064] rtc_cmos rtc_cmos: registered as rtc0
[ 37.479161] rtc_cmos rtc_cmos: setting system clock to 2025-08-09T06:59:27 UTC (1754722767)
[ 37.589355] rtc_cmos rtc_cmos: no alarms, 114 bytes nvram
[ 37.660523] scsi 0:0:0:0: CD-ROM TSSTcorp CD/DVDW TS-L532U SI02 PQ: 0 ANSI: 5
[ 37.768080] usbcore: registered new interface driver usbhid
[ 37.841333] usbhid: USB HID core driver
[ 37.892166] NET: Registered PF_INET6 protocol family
[ 37.957397] usb 1-1: new low-speed USB device number 2 using ohci-pci
[ 38.043046] Segment Routing with IPv6
[ 38.091327] In-situ OAM (IOAM) with IPv6
[ 38.142939] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 38.221312] NET: Registered PF_PACKET protocol family
[ 38.299490] Demotion targets for Node 0: null
[ 38.434147] input: Dell Dell QuietKey Keyboard as /devices/root/f0071294/pci0001:00/0001:00:0a.0/usb1/1-1/1-1:1.0/0003:413C:2106.0001/input/input0
[ 38.607481] This architecture does not have kernel memory protection.
[ 38.692231] Run /init as init process
[ 38.740289] with arguments:
[ 38.740294] /init
[ 38.740298] with environment:
[ 38.740302] HOME=/
[ 38.740306] TERM=linux
[ 38.740310] BOOT_IMAGE=/vmlinux-6.16.0+
[ 38.749973] hid-generic 0003:413C:2106.0001: input: USB HID v1.10 Keyboard [Dell Dell QuietKey Keyboard] on usb-0001:00:0a.0-1/input0
[ 39.466208] tg3 0000:00:02.0: enabling device (0000 -> 0002)
[ 39.713238] sym53c8xx 0002:00:02.0: enabling device (0146 -> 0147)
[ 39.938727] sym0: <1010-66> rev 0x1 at pci 0002:00:02.0 irq 24
[ 40.025921] sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
[ 40.144456] sym0: SCSI BUS has been reset.
[ 40.198277] scsi host2: sym-2.2.3
[ 40.241845] tg3 0000:00:02.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update
[ 40.461860] sr 0:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
[ 40.566055] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 40.634772] tg3 0000:00:02.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update
[ 40.805443] tg3 0000:00:02.0 eth0: Tigon3 [partno(none) rev 2100] (PCI:66MHz:64-bit) MAC address 00:03:ba:15:17:4e
[ 40.941647] tg3 0000:00:02.0 eth0: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 41.069812] tg3 0000:00:02.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[ 41.172840] tg3 0000:00:02.0 eth0: dma_rwctrl[763f0000] dma_mask[64-bit]
[ 41.261810] tg3 0000:00:02.1: enabling device (0000 -> 0002)
[ 41.336305] tg3 0000:00:02.1: BAR 2: can't reserve [mem size 0x00010000 64bit]
[ 41.431350] tg3 0000:00:02.1: Cannot obtain PCI resources, aborting
[ 41.513806] tg3 0000:00:02.1: probe with driver tg3 failed with error -16
[ 41.603169] tg3 0003:00:02.0: enabling device (0000 -> 0002)
[ 41.709976] sr 0:0:0:0: Attached scsi CD-ROM sr0
[ 41.829722] tg3 0003:00:02.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update
[ 42.129720] tg3 0003:00:02.0: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update
[ 42.300455] tg3 0003:00:02.0 eth1: Tigon3 [partno(none) rev 2100] (PCI:66MHz:64-bit) MAC address 00:03:ba:15:17:50
[ 42.436627] tg3 0003:00:02.0 eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 42.564810] tg3 0003:00:02.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[ 42.667830] tg3 0003:00:02.0 eth1: dma_rwctrl[763f0000] dma_mask[64-bit]
[ 42.756452] tg3 0003:00:02.1: enabling device (0000 -> 0002)
[ 42.830943] tg3 0003:00:02.1: BAR 2: can't reserve [mem size 0x00010000 64bit]
[ 42.925914] tg3 0003:00:02.1: Cannot obtain PCI resources, aborting
[ 43.008384] tg3 0003:00:02.1: probe with driver tg3 failed with error -16
[ 43.107054] tg3 0003:00:02.0 enP3p0s2f0: renamed from eth1
[ 43.187131] tg3 0000:00:02.0 enp0s2f0: renamed from eth0
[ 43.731423] scsi 2:0:0:0: Direct-Access HITACHI HUS15143BSUN146G PA04 PQ: 0 ANSI: 3
[ 43.837936] scsi target2:0:0: tagged command queuing enabled, command queue depth 16.
[ 43.959710] scsi target2:0:0: Beginning Domain Validation
[ 44.038800] scsi target2:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
[ 44.143551] scsi 2:0:0:0: Power-on or device reset occurred
[ 44.225556] scsi target2:0:0: Ending Domain Validation
[ 44.297767] scsi 2:0:1:0: Direct-Access FUJITSU MAX3147NCSUN146G 1503 PQ: 0 ANSI: 4
[ 44.404246] sd 2:0:0:0: [sda] 286739329 512-byte logical blocks: (147 GB/137 GiB)
[ 44.502640] scsi target2:0:1: tagged command queuing enabled, command queue depth 16.
[ 44.607368] sd 2:0:0:0: [sda] Write Protect is off
[ 44.670341] sd 2:0:0:0: [sda] Mode Sense: e3 00 10 08
[ 44.670365] scsi target2:0:1: Beginning Domain Validation
[ 44.745399] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
[ 44.861450] scsi target2:0:1: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
[ 44.967471] scsi 2:0:1:0: Power-on or device reset occurred
[ 45.087828] sda: sda1 sda2 sda3 sda4
[ 45.141451] sd 2:0:0:0: [sda] Attached SCSI disk
[ 45.204383] scsi target2:0:1: Ending Domain Validation
[ 45.854271] sd 2:0:1:0: [sdb] 286739329 512-byte logical blocks: (147 GB/137 GiB)
[ 46.444081] sd 2:0:1:0: [sdb] Write Protect is off
[ 46.506999] sd 2:0:1:0: [sdb] Mode Sense: c7 00 00 08
[ 47.623729] sd 2:0:1:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 49.098634] sym53c8xx 0002:00:02.1: enabling device (0146 -> 0147)
[ 49.180576] sym1: <1010-66> rev 0x1 at pci 0002:00:02.1 irq 25
[ 49.260335] sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking
[ 49.378843] sym1: SCSI BUS has been reset.
[ 49.432604] scsi host3: sym-2.2.3
[ 49.494560] sdb: sdb1
[ 49.526080] sd 2:0:1:0: [sdb] Attached SCSI disk
[ 57.944587] EXT4-fs (sda2): mounted filesystem a8314d10-9c39-438b-9dc4-9db2e05a6530 ro with ordered data mode. Quota mode: disabled.
[ 59.548859] systemd[1]: Failed to find module 'autofs4'
[ 59.739711] systemd[1]: systemd 257.7-1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK -SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC
+KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE)
[ 60.181448] systemd[1]: Detected architecture sparc64.
[ 60.401210] systemd[1]: Hostname set to <raverin>.
[ 61.662210] systemd-sysv-generator[140]: SysV service '/etc/init.d/buildd' lacks a native systemd unit file, automatically generating a unit file for compatibility.
[ 61.855664] systemd-sysv-generator[140]: Please update package to include a native systemd unit file.
[ 61.977034] systemd-sysv-generator[140]: ⚠️ This compatibility logic is deprecated, expect removal soon. ⚠️
[ 63.339369] systemd[1]: Queued start job for default target graphical.target.
[ 63.500708] systemd[1]: Created slice system-getty.slice - Slice /system/getty.
[ 63.712026] systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe.
[ 63.931887] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty.
[ 64.181824] systemd[1]: Created slice system-systemd\x2dfsck.slice - Slice /system/systemd-fsck.
[ 64.431259] systemd[1]: Created slice user.slice - User and Session Slice.
[ 64.619959] systemd[1]: Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch.
[ 64.879850] systemd[1]: Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch.
[ 65.129871] systemd[1]: Starting of proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point unsupported.
[ 65.429785] systemd[1]: Expecting device dev-disk-by\x2duuid-2b14ad4b\x2d10c7\x2d4337\x2da4bd\x2d38cb86a8e79b.device - /dev/disk/by-uuid/2b14ad4b-10c7-4337-a4bd-38cb86a8e79b...
[ 65.749684] systemd[1]: Expecting device dev-disk-by\x2duuid-e4125eef\x2d3d62\x2d4226\x2d8d9a\x2d9838b6d2c426.device - /dev/disk/by-uuid/e4125eef-3d62-4226-8d9a-9838b6d2c426...
[ 66.069682] systemd[1]: Expecting device dev-ttyS0.device - /dev/ttyS0...
[ 66.239724] systemd[1]: Reached target cryptsetup.target - Local Encrypted Volumes.
[ 66.439752] systemd[1]: Reached target integritysetup.target - Local Integrity Protected Volumes.
[ 66.669765] systemd[1]: Reached target paths.target - Path Units.
[ 66.849722] systemd[1]: Reached target remote-fs.target - Remote File Systems.
[ 67.039734] systemd[1]: Reached target slices.target - Slice Units.
[ 67.219807] systemd[1]: Reached target veritysetup.target - Local Verity Protected Volumes.
[ 67.440141] systemd[1]: Listening on syslog.socket - Syslog Socket.
[ 67.630027] systemd[1]: Listening on systemd-creds.socket - Credential Encryption/Decryption.
[ 67.860026] systemd[1]: Listening on systemd-initctl.socket - initctl Compatibility Named Pipe.
[ 68.089958] systemd[1]: Listening on systemd-journald-dev-log.socket - Journal Socket (/dev/log).
[ 68.320053] systemd[1]: Listening on systemd-journald.socket - Journal Sockets.
[ 68.530037] systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket.
[ 68.749899] systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket.
[ 68.980819] systemd[1]: Mounting dev-hugepages.mount - Huge Pages File System...
[ 69.190098] systemd[1]: Mounting dev-mqueue.mount - POSIX Message Queue File System...
[ 69.450117] systemd[1]: Mounting run-lock.mount - Legacy Locks Directory /run/lock...
[ 69.710169] systemd[1]: Mounting sys-kernel-debug.mount - Kernel Debug File System...
[ 69.970187] systemd[1]: Mounting sys-kernel-tracing.mount - Kernel Trace File System...
[ 70.230328] systemd[1]: Starting kmod-static-nodes.service - Create List of Static Device Nodes...
[ 70.530332] systemd[1]: Starting modprobe@configfs.service - Load Kernel Module configfs...
[ 70.820323] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm...
[ 71.080361] systemd[1]: Starting modprobe@efi_pstore.service - Load Kernel Module efi_pstore...
[ 71.370306] systemd[1]: Starting modprobe@fuse.service - Load Kernel Module fuse...
[ 71.620104] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root).
[ 71.833050] systemd[1]: systemd-hibernate-clear.service - Clear Stale Hibernate Storage Info was skipped because of an unmet condition check
(ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67).
[ 72.118962] systemd[1]: systemd-journald.service: unit configures an IP firewall, but the local system does not support BPF/cgroup firewalling.
[ 72.288335] systemd[1]: systemd-journald.service: (This warning is only shown for the first unit using IP firewalling.)
[ 72.441273] systemd[1]: Starting systemd-journald.service - Journal Service...
[ 72.684614] systemd-journald[154]: Collecting audit messages is disabled.
[ 72.810526] systemd[1]: Starting systemd-modules-load.service - Load Kernel Modules...
[ 73.200343] systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems...
[ 73.446942] EXT4-fs (sda2): re-mounted a8314d10-9c39-438b-9dc4-9db2e05a6530 r/w.
[ 73.590318] systemd[1]: Starting systemd-udev-load-credentials.service - Load udev Rules from Credentials...
[ 73.890315] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices...
[ 74.240333] systemd[1]: Started systemd-journald.service - Journal Service.
[ 76.472443] systemd-journald[154]: Received client request to flush runtime journal.
[ 78.349606] random: crng init done
[ 79.504029] sr 0:0:0:0: Attached scsi generic sg0 type 5
[ 80.133697] sd 2:0:0:0: Attached scsi generic sg1 type 0
[ 80.275546] sd 2:0:1:0: Attached scsi generic sg2 type 0
[ 81.376870] Adding 1000096k swap on /dev/sda4. Priority:-2 extents:1 across:1000096k
[ 83.194980] tg3 0000:00:02.0: Direct firmware load for tigon/tg3_tso.bin failed with error -2
[ 83.329895] tg3 0000:00:02.0 enp0s2f0: Failed to load firmware "tigon/tg3_tso.bin"
[ 83.429513] tg3 0000:00:02.0 enp0s2f0: TSO capability disabled
[ 84.815494] tg3 0000:00:02.0 enp0s2f0: No firmware running
[ 90.434186] tg3 0000:00:02.0 enp0s2f0: Link is up at 1000 Mbps, full duplex
[ 90.525821] tg3 0000:00:02.0 enp0s2f0: Flow control is off for TX and off for RX
[ 113.710728] systemd-journald[154]: Time jumped backwards, rotating.
Let me know if you have more suggestions to test. I can also provide you with full access to this Netra 240
if you send me your public SSH key in a private mail.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-09 6:42 ` John Paul Adrian Glaubitz
@ 2025-08-10 9:52 ` John Paul Adrian Glaubitz
2025-08-10 22:20 ` John Paul Adrian Glaubitz
0 siblings, 1 reply; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-10 9:52 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi Anthony,
On Sat, 2025-08-09 at 08:42 +0200, John Paul Adrian Glaubitz wrote:
> Let me know if you have more suggestions to test. I can also provide you with full
> access to this Netra 240 if you send me your public SSH key in a private mail.
I have narrowed it down to a regression between v6.3 and v6.4 now.
The bug can be reproduced with the sparc64_defconfig on a Sun Netra 240 by setting
CONFIG_TRANSPARENT_HUGEPAGE=y and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y. When testing
on a modern systemd-based distribution, it's also necessary to enable CGroup support
as well as enable support for Sun partition tables with CONFIG_SUN_PARTITION=y.
Then it should be a matter of bisecting the commits between v6.3 and v6.4.
I will do that within the next days as I'm currently a bit busy with other stuff.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-10 9:52 ` John Paul Adrian Glaubitz
@ 2025-08-10 22:20 ` John Paul Adrian Glaubitz
2025-08-11 8:25 ` David Hildenbrand
2025-08-11 10:44 ` John Paul Adrian Glaubitz
0 siblings, 2 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-10 22:20 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador
Hi,
On Sun, 2025-08-10 at 11:52 +0200, John Paul Adrian Glaubitz wrote:
> On Sat, 2025-08-09 at 08:42 +0200, John Paul Adrian Glaubitz wrote:
> > Let me know if you have more suggestions to test. I can also provide you with full
> > access to this Netra 240 if you send me your public SSH key in a private mail.
>
> I have narrowed it down to a regression between v6.3 and v6.4 now.
>
> The bug can be reproduced with the sparc64_defconfig on a Sun Netra 240 by setting
> CONFIG_TRANSPARENT_HUGEPAGE=y and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y. When testing
> on a modern systemd-based distribution, it's also necessary to enable CGroup support
> as well as enable support for Sun partition tables with CONFIG_SUN_PARTITION=y.
>
> Then it should be a matter of bisecting the commits between v6.3 and v6.4.
>
> I will do that within the next days as I'm currently a bit busy with other stuff.
OK, it turns out it's reproducible on older kernels (but not as old as 4.19) as well.
It's just much harder to trigger. I found a reproducer though and will try to find
the problematic commit next.
[50686.808389] BUG: Bad page map in process sshd-session pte:00000002 pmd:01448000
[50686.905701] addr:00000100000a0000 vm_flags:00000075 anon_vma:0000000000000000 mapping:fff000003c8ca4f8 index:50
[50687.038425] file:sshd-session fault:filemap_fault mmap:ext4_file_mmap [ext4] read_folio:ext4_read_folio [ext4]
[50687.170246] CPU: 0 PID: 37883 Comm: sshd-session Not tainted 6.3.0-2-sparc64 #1 Debian 6.3.11-1
[50687.285751] Call Trace:
[50687.317771] [<0000000000d660b0>] dump_stack+0x8/0x18
[50687.382976] [<000000000064fd1c>] print_bad_pte+0x15c/0x200
[50687.455024] [<0000000000650f84>] unmap_page_range+0x3e4/0xbe0
[50687.530513] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
[50687.597993] [<000000000065e674>] exit_mmap+0xb4/0x360
[50687.664331] [<00000000004647dc>] __mmput+0x3c/0x120
[50687.728380] [<00000000004648f4>] mmput+0x34/0x60
[50687.788999] [<000000000046b510>] do_exit+0x250/0xa00
[50687.854194] [<000000000046bea4>] do_group_exit+0x24/0xa0
[50687.923962] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
[50687.994875] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
[50688.071518] Disabling lock debugging due to kernel taint
[50689.484196] Unable to handle kernel paging request at virtual address 000c000002400000
[50689.588368] tsk->{mm,active_mm}->context = 00000000001815a6
[50689.661677] tsk->{mm,active_mm}->pgd = fff000000ae60000
[50689.730374] \|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
[50689.923679] sshd-session(37883): Oops [#1]
[50689.977420] CPU: 0 PID: 37883 Comm: sshd-session Tainted: G B 6.3.0-2-sparc64 #1 Debian 6.3.11-1
[50690.112384] TSTATE: 0000008811001607 TPC: 00000000006510cc TNPC: 00000000006510d0 Y: 00000000 Tainted: G B
[50690.261089] TPC: <unmap_page_range+0x52c/0xbe0>
[50690.320650] g0: 00000000000004a8 g1: 000c000000000000 g2: 0000000000008800 g3: ffffffffffffffff
[50690.435029] g4: fff0000001ef1280 g5: 0000000031200000 g6: fff0000001f04000 g7: ffffffffffffffff
[50690.549403] o0: 000c000002400a20 o1: 00000100000a4000 o2: 0000000100048290 o3: 0000000000000000
[50690.663779] o4: 0000000000000001 o5: 000000000000000d sp: fff0000001f06f61 ret_pc: 0000010000000000
[50690.782728] RPC: <0x10000000000>
[50690.825039] l0: 0000000100048290 l1: 000c000002400a20 l2: 00000100000a6000 l3: fff0000000950000
[50690.939419] l4: 00000100000fc000 l5: fff000000196dc20 l6: fff0000001f07938 l7: 00000000010f6fd0
[50691.053798] i0: fff0000001f07aa8 i1: 0000000000002000 i2: 00000100000a4000 i3: fff0000008311b00
[50691.168170] i4: 0000000000100000 i5: fff0000001448290 i6: fff0000001f07081 i7: 0000000000651cd8
[50691.282546] I7: <unmap_vmas+0xf8/0x1a0>
[50691.332867] Call Trace:
[50691.364891] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
[50691.432371] [<000000000065e674>] exit_mmap+0xb4/0x360
[50691.498708] [<00000000004647dc>] __mmput+0x3c/0x120
[50691.562759] [<00000000004648f4>] mmput+0x34/0x60
[50691.623376] [<000000000046b510>] do_exit+0x250/0xa00
[50691.688573] [<000000000046bea4>] do_group_exit+0x24/0xa0
[50691.758340] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
[50691.829256] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
[50691.905886] Caller[0000000000651cd8]: unmap_vmas+0xf8/0x1a0
[50691.979085] Caller[000000000065e674]: exit_mmap+0xb4/0x360
[50692.051141] Caller[00000000004647dc]: __mmput+0x3c/0x120
[50692.120911] Caller[00000000004648f4]: mmput+0x34/0x60
[50692.187246] Caller[000000000046b510]: do_exit+0x250/0xa00
[50692.258160] Caller[000000000046bea4]: do_group_exit+0x24/0xa0
[50692.333645] Caller[000000000046bf3c]: sys_exit_group+0x1c/0x40
[50692.410280] Caller[0000000000406174]: linux_sparc_syscall+0x34/0x44
[50692.492629] Caller[fff0000102ad4a74]: 0xfff0000102ad4a74
[50692.562397] Instruction DUMP:
[50692.562399] ce762010
[50692.601281] 02f47fa8
[50692.632163] c4362018
[50692.663044] <c45c6008>
[50692.693926] 86100011
[50692.724808] 8e08a001
[50692.755689] 8400bfff
[50692.786569] 8779d402
[50692.817451] c458e018
[50692.898656] Fixing recursive fault but reboot is needed!
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-09 6:23 ` John Paul Adrian Glaubitz
2025-08-09 6:26 ` John Paul Adrian Glaubitz
@ 2025-08-11 8:20 ` David Hildenbrand
2025-08-11 8:28 ` John Paul Adrian Glaubitz
1 sibling, 1 reply; 26+ messages in thread
From: David Hildenbrand @ 2025-08-11 8:20 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, Anthony Yznaga, sparclinux, davem,
andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, osalvador
On 09.08.25 08:23, John Paul Adrian Glaubitz wrote:
> Hi Anthony,
>
> On Sat, 2025-08-09 at 00:37 +0200, John Paul Adrian Glaubitz wrote:
>>> Maybe try enabling CONFIG_DEBUG_VM_IRQSOFF, CONFIG_DEBUG_VM, and perhaps
>>> CONFIG_DEBUG_VM_PGFLAGS. That might help detect a problem closer to the
>>> source. You can also try adding transparent_hugepage=never to the kernel
>>> boot line to see if compiling in THP support but not using it is okay.
>>
>> OK, I will try that. But not today anymore. It's half past midnight now here in Germany
>> and I was debugging this issue almost all day long. I'm glad to have finally been able
>> to track this down to THP support being enabled.
>>
>> Maybe you can try whether you can reproduce this in QEMU as well.
>
> OK, first data point: Setting CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y causes the backtrace during
> boot to disappear with CONFIG_TRANSPARENT_HUGEPAGE=y. However, it still disappears later when
> running "apt update && apt -y upgrade" again:
Just to give some context: (m)THPs in file systems will get used
independently of CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y.
So CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y primarily only controls usage of
(m)THPs for anonymous memory, but not in the pagecache.
>
> [ 170.472743] kernel BUG at fs/ext4/inode.c:1174!
> [ 170.532313] \|/ ____ \|/
> "@'/ .. \`@"
> /_| \__/ |_\
> \__U_/
Is this the
BUG_ON(to > folio_size(folio));
?
--
Cheers,
David / dhildenb
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-10 22:20 ` John Paul Adrian Glaubitz
@ 2025-08-11 8:25 ` David Hildenbrand
2025-08-11 10:44 ` John Paul Adrian Glaubitz
1 sibling, 0 replies; 26+ messages in thread
From: David Hildenbrand @ 2025-08-11 8:25 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, Anthony Yznaga, sparclinux, davem,
andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, osalvador
On 11.08.25 00:20, John Paul Adrian Glaubitz wrote:
> Hi,
>
> On Sun, 2025-08-10 at 11:52 +0200, John Paul Adrian Glaubitz wrote:
>> On Sat, 2025-08-09 at 08:42 +0200, John Paul Adrian Glaubitz wrote:
>>> Let me know if you have more suggestions to test. I can also provide you with full
>>> access to this Netra 240 if you send me your public SSH key in a private mail.
>>
>> I have narrowed it down to a regression between v6.3 and v6.4 now.
>>
>> The bug can be reproduced with the sparc64_defconfig on a Sun Netra 240 by setting
>> CONFIG_TRANSPARENT_HUGEPAGE=y and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y. When testing
>> on a modern systemd-based distribution, it's also necessary to enable CGroup support
>> as well as enable support for Sun partition tables with CONFIG_SUN_PARTITION=y.
>>
>> Then it should be a matter of bisecting the commits between v6.3 and v6.4.
>>
>> I will do that within the next days as I'm currently a bit busy with other stuff.
>
> OK, it turns out it's reproducible on older kernels (but not as old as 4.19) as well.
> It's just much harder to trigger. I found a reproducer though and will try to find
> the problematic commit next.
ext4 support for large folios was added recently (6.16? not 100% sure).
But below can indicate some ext4 issue with large folios.
(fault:filemap_fault mmap:ext4_file_mmap)
--
Cheers,
David / dhildenb
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-11 8:20 ` David Hildenbrand
@ 2025-08-11 8:28 ` John Paul Adrian Glaubitz
0 siblings, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-11 8:28 UTC (permalink / raw)
To: David Hildenbrand, Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, osalvador
Hi David,
thanks a lot for your input!
On Mon, 2025-08-11 at 10:20 +0200, David Hildenbrand wrote:
> On 09.08.25 08:23, John Paul Adrian Glaubitz wrote:
> > Hi Anthony,
> >
> > On Sat, 2025-08-09 at 00:37 +0200, John Paul Adrian Glaubitz wrote:
> > > > Maybe try enabling CONFIG_DEBUG_VM_IRQSOFF, CONFIG_DEBUG_VM, and perhaps
> > > > CONFIG_DEBUG_VM_PGFLAGS. That might help detect a problem closer to the
> > > > source. You can also try adding transparent_hugepage=never to the kernel
> > > > boot line to see if compiling in THP support but not using it is okay.
> > >
> > > OK, I will try that. But not today anymore. It's half past midnight now here in Germany
> > > and I was debugging this issue almost all day long. I'm glad to have finally been able
> > > to track this down to THP support being enabled.
> > >
> > > Maybe you can try whether you can reproduce this in QEMU as well.
> >
> > OK, first data point: Setting CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y causes the backtrace during
> > boot to disappear with CONFIG_TRANSPARENT_HUGEPAGE=y. However, it still disappears later when
> > running "apt update && apt -y upgrade" again:
>
> Just to give some context: (m)THPs in file systems will get used
> independently of CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y.
>
> So CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y primarily only controls usage of
> (m)THPs for anonymous memory, but not in the pagecache.
Thanks, this actually explains why CONFIG_TRANSPARENT_HUGEPAGE_NEVER=y doesn't fully mitigate
the problem.
> > [ 170.472743] kernel BUG at fs/ext4/inode.c:1174!
> > [ 170.532313] \|/ ____ \|/
> > "@'/ .. \`@"
> > /_| \__/ |_\
> > \__U_/
>
> Is this the
>
> BUG_ON(to > folio_size(folio));
Yes, I just looked it up in my current local kernel tree and that's indeed the line.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-10 22:20 ` John Paul Adrian Glaubitz
2025-08-11 8:25 ` David Hildenbrand
@ 2025-08-11 10:44 ` John Paul Adrian Glaubitz
2025-08-11 11:06 ` John Paul Adrian Glaubitz
2025-08-12 12:32 ` Found it - was: " John Paul Adrian Glaubitz
1 sibling, 2 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-11 10:44 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador,
Meelis Roos
Hi,
On Mon, 2025-08-11 at 00:20 +0200, John Paul Adrian Glaubitz wrote:
> Hi,
>
> On Sun, 2025-08-10 at 11:52 +0200, John Paul Adrian Glaubitz wrote:
> > On Sat, 2025-08-09 at 08:42 +0200, John Paul Adrian Glaubitz wrote:
> > > Let me know if you have more suggestions to test. I can also provide you with full
> > > access to this Netra 240 if you send me your public SSH key in a private mail.
> >
> > I have narrowed it down to a regression between v6.3 and v6.4 now.
> >
> > The bug can be reproduced with the sparc64_defconfig on a Sun Netra 240 by setting
> > CONFIG_TRANSPARENT_HUGEPAGE=y and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y. When testing
> > on a modern systemd-based distribution, it's also necessary to enable CGroup support
> > as well as enable support for Sun partition tables with CONFIG_SUN_PARTITION=y.
> >
> > Then it should be a matter of bisecting the commits between v6.3 and v6.4.
> >
> > I will do that within the next days as I'm currently a bit busy with other stuff.
>
> OK, it turns out it's reproducible on older kernels (but not as old as 4.19) as well.
> It's just much harder to trigger. I found a reproducer though and will try to find
> the problematic commit next.
>
> [50686.808389] BUG: Bad page map in process sshd-session pte:00000002 pmd:01448000
> [50686.905701] addr:00000100000a0000 vm_flags:00000075 anon_vma:0000000000000000 mapping:fff000003c8ca4f8 index:50
> [50687.038425] file:sshd-session fault:filemap_fault mmap:ext4_file_mmap [ext4] read_folio:ext4_read_folio [ext4]
> [50687.170246] CPU: 0 PID: 37883 Comm: sshd-session Not tainted 6.3.0-2-sparc64 #1 Debian 6.3.11-1
> [50687.285751] Call Trace:
> [50687.317771] [<0000000000d660b0>] dump_stack+0x8/0x18
> [50687.382976] [<000000000064fd1c>] print_bad_pte+0x15c/0x200
> [50687.455024] [<0000000000650f84>] unmap_page_range+0x3e4/0xbe0
> [50687.530513] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
> [50687.597993] [<000000000065e674>] exit_mmap+0xb4/0x360
> [50687.664331] [<00000000004647dc>] __mmput+0x3c/0x120
> [50687.728380] [<00000000004648f4>] mmput+0x34/0x60
> [50687.788999] [<000000000046b510>] do_exit+0x250/0xa00
> [50687.854194] [<000000000046bea4>] do_group_exit+0x24/0xa0
> [50687.923962] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
> [50687.994875] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> [50688.071518] Disabling lock debugging due to kernel taint
> [50689.484196] Unable to handle kernel paging request at virtual address 000c000002400000
> [50689.588368] tsk->{mm,active_mm}->context = 00000000001815a6
> [50689.661677] tsk->{mm,active_mm}->pgd = fff000000ae60000
> [50689.730374] \|/ ____ \|/
> "@'/ .. \`@"
> /_| \__/ |_\
> \__U_/
> [50689.923679] sshd-session(37883): Oops [#1]
> [50689.977420] CPU: 0 PID: 37883 Comm: sshd-session Tainted: G B 6.3.0-2-sparc64 #1 Debian 6.3.11-1
> [50690.112384] TSTATE: 0000008811001607 TPC: 00000000006510cc TNPC: 00000000006510d0 Y: 00000000 Tainted: G B
> [50690.261089] TPC: <unmap_page_range+0x52c/0xbe0>
> [50690.320650] g0: 00000000000004a8 g1: 000c000000000000 g2: 0000000000008800 g3: ffffffffffffffff
> [50690.435029] g4: fff0000001ef1280 g5: 0000000031200000 g6: fff0000001f04000 g7: ffffffffffffffff
> [50690.549403] o0: 000c000002400a20 o1: 00000100000a4000 o2: 0000000100048290 o3: 0000000000000000
> [50690.663779] o4: 0000000000000001 o5: 000000000000000d sp: fff0000001f06f61 ret_pc: 0000010000000000
> [50690.782728] RPC: <0x10000000000>
> [50690.825039] l0: 0000000100048290 l1: 000c000002400a20 l2: 00000100000a6000 l3: fff0000000950000
> [50690.939419] l4: 00000100000fc000 l5: fff000000196dc20 l6: fff0000001f07938 l7: 00000000010f6fd0
> [50691.053798] i0: fff0000001f07aa8 i1: 0000000000002000 i2: 00000100000a4000 i3: fff0000008311b00
> [50691.168170] i4: 0000000000100000 i5: fff0000001448290 i6: fff0000001f07081 i7: 0000000000651cd8
> [50691.282546] I7: <unmap_vmas+0xf8/0x1a0>
> [50691.332867] Call Trace:
> [50691.364891] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
> [50691.432371] [<000000000065e674>] exit_mmap+0xb4/0x360
> [50691.498708] [<00000000004647dc>] __mmput+0x3c/0x120
> [50691.562759] [<00000000004648f4>] mmput+0x34/0x60
> [50691.623376] [<000000000046b510>] do_exit+0x250/0xa00
> [50691.688573] [<000000000046bea4>] do_group_exit+0x24/0xa0
> [50691.758340] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
> [50691.829256] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> [50691.905886] Caller[0000000000651cd8]: unmap_vmas+0xf8/0x1a0
> [50691.979085] Caller[000000000065e674]: exit_mmap+0xb4/0x360
> [50692.051141] Caller[00000000004647dc]: __mmput+0x3c/0x120
> [50692.120911] Caller[00000000004648f4]: mmput+0x34/0x60
> [50692.187246] Caller[000000000046b510]: do_exit+0x250/0xa00
> [50692.258160] Caller[000000000046bea4]: do_group_exit+0x24/0xa0
> [50692.333645] Caller[000000000046bf3c]: sys_exit_group+0x1c/0x40
> [50692.410280] Caller[0000000000406174]: linux_sparc_syscall+0x34/0x44
> [50692.492629] Caller[fff0000102ad4a74]: 0xfff0000102ad4a74
> [50692.562397] Instruction DUMP:
> [50692.562399] ce762010
> [50692.601281] 02f47fa8
> [50692.632163] c4362018
> [50692.663044] <c45c6008>
> [50692.693926] 86100011
> [50692.724808] 8e08a001
> [50692.755689] 8400bfff
> [50692.786569] 8779d402
> [50692.817451] c458e018
>
> [50692.898656] Fixing recursive fault but reboot is needed!
So, I was able now to even reproduce it in kernel versions as early as 5.2:
[ 122.085803] Unable to handle kernel NULL pointer dereference
[ 122.160227] tsk->{mm,active_mm}->context = 000000000000009d
[ 122.233502] tsk->{mm,active_mm}->pgd = fff0000231d14000
[ 122.302118] \|/ ____ \|/
[ 122.302118] "@'/ .. \`@"
[ 122.302118] /_| \__/ |_\
[ 122.302118] \__U_/
[ 122.495420] systemd(1): Oops [#1]
[ 122.538874] CPU: 0 PID: 1 Comm: systemd Not tainted 5.2.0-3-sparc64 #1 Debian 5.2.17-1
[ 122.642957] TSTATE: 0000004411001601 TPC: 000000000061cd94 TNPC: 000000000061cd98 Y: 00000000 Not tainted
[ 122.772207] TPC: <vfs_getattr_nosec+0x34/0xc0>
[ 122.830529] g0: 0000000000000000 g1: 00000000000007ff g2: 0000000000000000 g3: 00000000000007df
[ 122.944902] g4: fff00002381771c0 g5: 0000000000000003 g6: fff0000238178000 g7: 0000000000000000
[ 123.059275] o0: fff000023817be18 o1: 0000000000000000 o2: 0000000000000000 o3: fff000023817be18
[ 123.173658] o4: 0000000000000000 o5: 0000000000000000 sp: fff000023817b341 ret_pc: 000000000061cd7c
[ 123.292611] RPC: <vfs_getattr_nosec+0x1c/0xc0>
[ 123.350933] l0: 0000010000204010 l1: fff0000101600e28 l2: e4e45b5b8ae44628 l3: 0000000000000000
[ 123.465311] l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000000000 l7: fff0000100bff140
[ 123.579692] i0: fff000023817bd50 i1: fff000023817be18 i2: 0000000000000001 i3: 0000000000000900
[ 123.694060] i4: 0000000000000000 i5: fff00002320c1210 i6: fff000023817b3f1 i7: 000000000061ce48
[ 123.808439] I7: <vfs_getattr+0x28/0x40>
[ 123.858759] Call Trace:
[ 123.890785] [000000000061ce48] vfs_getattr+0x28/0x40
[ 123.957123] [000000000061cf64] vfs_statx+0x84/0xc0
[ 124.021173] [000000000061d918] sys_statx+0x38/0x60
[ 124.085226] [0000000000406154] linux_sparc_syscall+0x34/0x44
[ 124.160708] Disabling lock debugging due to kernel taint
[ 124.230481] Caller[000000000061ce48]: vfs_getattr+0x28/0x40
[ 124.303680] Caller[000000000061cf64]: vfs_statx+0x84/0xc0
[ 124.374593] Caller[000000000061d918]: sys_statx+0x38/0x60
[ 124.445503] Caller[0000000000406154]: linux_sparc_syscall+0x34/0x44
[ 124.527857] Caller[fff00001013fde40]: 0xfff00001013fde40
[ 124.597621] Instruction DUMP:
[ 124.597623] c2264000
[ 124.636505] 861027df
[ 124.667386] c45f6028
[ 124.698267] <c458a050>
[ 124.729148] 8408a401
[ 124.760031] 83789403
[ 124.790910] c2264000
[ 124.821801] c207600c
[ 124.852675] 80886800
[ 124.883556]
[ 124.954015] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[ 125.054721] Press Stop-A (L1-A) from sun keyboard or send break
[ 125.054721] twice on console to return to the boot prom
[ 125.201103] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---
On v5.6, I'm getting an interesting error mentioning D-cache parity errors:
[ 125.743109] CPU[0]: Cheetah+ D-cache parity error at TPC[000000000056bacc]
[ 125.833511] TPC<bpf_check+0x18ec/0x3060>
[ 127.909612] systemd-sysv-generator[1677]: SysV service '/etc/init.d/buildd' lacks a native systemd unit file, automatically generating a unit file for compatibility.
[ 128.104239] systemd-sysv-generator[1677]: Please update package to include a native systemd unit file.
[ 128.227312] systemd-sysv-generator[1677]: ⚠ This compatibility logic is deprecated, expect removal soon. ⚠
[ 129.638144] Unable to handle kernel NULL pointer dereference
[ 129.712528] tsk->{mm,active_mm}->context = 000000000000009e
[ 129.785808] tsk->{mm,active_mm}->pgd = fff0000233d38000
[ 129.854522] \|/ ____ \|/
[ 129.854522] "@'/ .. \`@"
[ 129.854522] /_| \__/ |_\
[ 129.854522] \__U_/
[ 130.047827] systemd(1): Oops [#1]
[ 130.091278] CPU: 0 PID: 1 Comm: systemd Tainted: G E 5.6.0-2-sparc64 #1 Debian 5.6.14-2
[ 130.213664] TSTATE: 0000009911001604 TPC: 00000000005506d8 TNPC: 00000000005506dc Y: 00000000 Tainted: G E
[ 130.361222] TPC: <bpf_prog_realloc+0x38/0xe0>
[ 130.418486] g0: 0000000002000000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000002
[ 130.532867] g4: fff000023c178000 g5: 0000000000657300 g6: fff000023c180000 g7: fff000023423e684
[ 130.647245] o0: ffffffff00002000 o1: 0000000000000001 o2: fff0000234168fa0 o3: 0000000000000000
[ 130.761617] o4: fff0000237761f80 o5: 0000000000000001 sp: fff000023c182fd1 ret_pc: 00000000005f2c84
[ 130.880576] RPC: <__vfree+0x24/0x80>
[ 130.927456] l0: ffffffffffffffff l1: 0000000000000001 l2: 0000000000000400 l3: 0000000002000000
[ 131.041836] l4: 0000000000debc00 l5: 0000000000000100 l6: 0000000000000001 l7: fff000023c005e40
[ 131.156213] i0: 000000010004e000 i1: 0000000000002000 i2: 0000000000100cc0 i3: fff0000237761300
[ 131.270589] i4: 0000000000000001 i5: 0000000000000001 i6: fff000023c183081 i7: 0000000000550a70
[ 131.384963] I7: <bpf_patch_insn_single+0x70/0x1e0>
[ 131.447862] Call Trace:
[ 131.479889] [0000000000550a70] bpf_patch_insn_single+0x70/0x1e0
[ 131.558814] [000000000055fe58] bpf_patch_insn_data+0x18/0x1c0
[ 131.635442] [000000000056bed8] bpf_check+0x1cf8/0x3060
[ 131.704064] [0000000000559778] bpf_prog_load+0x498/0x8e0
[ 131.774975] [0000000000559d10] __do_sys_bpf+0x150/0x1880
[ 131.845890] [000000000055b534] sys_bpf+0x14/0x560
[ 131.908807] [0000000000406154] linux_sparc_syscall+0x34/0x44
[ 131.984281] Disabling lock debugging due to kernel taint
[ 132.054051] Caller[0000000000550a70]: bpf_patch_insn_single+0x70/0x1e0
[ 132.139832] Caller[000000000055fe58]: bpf_patch_insn_data+0x18/0x1c0
[ 132.223325] Caller[000000000056bed8]: bpf_check+0x1cf8/0x3060
[ 132.298811] Caller[0000000000559778]: bpf_prog_load+0x498/0x8e0
[ 132.376588] Caller[0000000000559d10]: __do_sys_bpf+0x150/0x1880
[ 132.454361] Caller[000000000055b534]: sys_bpf+0x14/0x560
[ 132.524132] Caller[0000000000406154]: linux_sparc_syscall+0x34/0x44
[ 132.606483] Caller[fff0000100995b38]: 0xfff0000100995b38
[ 132.676247] Instruction DUMP:
[ 132.676249] c25e2020
[ 132.715134] 92270009
[ 132.746014] bb326000
[ 132.776895] <d05860e0>
[ 132.807776] 400021a1
[ 132.838657] 9210001d
[ 132.869540] 80a22000
[ 132.900422] 12400016
[ 132.931303] 03003480
[ 132.962184]
[ 133.020246] systemd-journald[205]: Time jumped backwards, rotating. (Dropped 1 similar message(s))
[ 133.138938] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[ 133.239608] Press Stop-A (L1-A) from sun keyboard or send break
[ 133.239608] twice on console to return to the boot prom
[ 133.385997] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---
Searching for that error in the archives, yielded this report from 2018 [1] which seems to have never
been addressed by David Miller.
@Anthony: Can you see any suspicious in the disassembled code that Meelis (CC'ed) posted?
Adrian
> [1] https://lore.kernel.org/all/a4391645-0c4f-bd99-7371-b0e2cb505542@linux.ee/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-11 10:44 ` John Paul Adrian Glaubitz
@ 2025-08-11 11:06 ` John Paul Adrian Glaubitz
2025-08-12 12:32 ` Found it - was: " John Paul Adrian Glaubitz
1 sibling, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-11 11:06 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, Oscar Salvador
Hi,
dropping Meelis Roos from the discussion again as his mail address bounces.
Adrian
On Mon, 2025-08-11 at 12:44 +0200, John Paul Adrian Glaubitz wrote:
> Hi,
>
> On Mon, 2025-08-11 at 00:20 +0200, John Paul Adrian Glaubitz wrote:
> > Hi,
> >
> > On Sun, 2025-08-10 at 11:52 +0200, John Paul Adrian Glaubitz wrote:
> > > On Sat, 2025-08-09 at 08:42 +0200, John Paul Adrian Glaubitz wrote:
> > > > Let me know if you have more suggestions to test. I can also provide you with full
> > > > access to this Netra 240 if you send me your public SSH key in a private mail.
> > >
> > > I have narrowed it down to a regression between v6.3 and v6.4 now.
> > >
> > > The bug can be reproduced with the sparc64_defconfig on a Sun Netra 240 by setting
> > > CONFIG_TRANSPARENT_HUGEPAGE=y and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y. When testing
> > > on a modern systemd-based distribution, it's also necessary to enable CGroup support
> > > as well as enable support for Sun partition tables with CONFIG_SUN_PARTITION=y.
> > >
> > > Then it should be a matter of bisecting the commits between v6.3 and v6.4.
> > >
> > > I will do that within the next days as I'm currently a bit busy with other stuff.
> >
> > OK, it turns out it's reproducible on older kernels (but not as old as 4.19) as well.
> > It's just much harder to trigger. I found a reproducer though and will try to find
> > the problematic commit next.
> >
> > [50686.808389] BUG: Bad page map in process sshd-session pte:00000002 pmd:01448000
> > [50686.905701] addr:00000100000a0000 vm_flags:00000075 anon_vma:0000000000000000 mapping:fff000003c8ca4f8 index:50
> > [50687.038425] file:sshd-session fault:filemap_fault mmap:ext4_file_mmap [ext4] read_folio:ext4_read_folio [ext4]
> > [50687.170246] CPU: 0 PID: 37883 Comm: sshd-session Not tainted 6.3.0-2-sparc64 #1 Debian 6.3.11-1
> > [50687.285751] Call Trace:
> > [50687.317771] [<0000000000d660b0>] dump_stack+0x8/0x18
> > [50687.382976] [<000000000064fd1c>] print_bad_pte+0x15c/0x200
> > [50687.455024] [<0000000000650f84>] unmap_page_range+0x3e4/0xbe0
> > [50687.530513] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
> > [50687.597993] [<000000000065e674>] exit_mmap+0xb4/0x360
> > [50687.664331] [<00000000004647dc>] __mmput+0x3c/0x120
> > [50687.728380] [<00000000004648f4>] mmput+0x34/0x60
> > [50687.788999] [<000000000046b510>] do_exit+0x250/0xa00
> > [50687.854194] [<000000000046bea4>] do_group_exit+0x24/0xa0
> > [50687.923962] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
> > [50687.994875] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> > [50688.071518] Disabling lock debugging due to kernel taint
> > [50689.484196] Unable to handle kernel paging request at virtual address 000c000002400000
> > [50689.588368] tsk->{mm,active_mm}->context = 00000000001815a6
> > [50689.661677] tsk->{mm,active_mm}->pgd = fff000000ae60000
> > [50689.730374] \|/ ____ \|/
> > "@'/ .. \`@"
> > /_| \__/ |_\
> > \__U_/
> > [50689.923679] sshd-session(37883): Oops [#1]
> > [50689.977420] CPU: 0 PID: 37883 Comm: sshd-session Tainted: G B 6.3.0-2-sparc64 #1 Debian 6.3.11-1
> > [50690.112384] TSTATE: 0000008811001607 TPC: 00000000006510cc TNPC: 00000000006510d0 Y: 00000000 Tainted: G B
> > [50690.261089] TPC: <unmap_page_range+0x52c/0xbe0>
> > [50690.320650] g0: 00000000000004a8 g1: 000c000000000000 g2: 0000000000008800 g3: ffffffffffffffff
> > [50690.435029] g4: fff0000001ef1280 g5: 0000000031200000 g6: fff0000001f04000 g7: ffffffffffffffff
> > [50690.549403] o0: 000c000002400a20 o1: 00000100000a4000 o2: 0000000100048290 o3: 0000000000000000
> > [50690.663779] o4: 0000000000000001 o5: 000000000000000d sp: fff0000001f06f61 ret_pc: 0000010000000000
> > [50690.782728] RPC: <0x10000000000>
> > [50690.825039] l0: 0000000100048290 l1: 000c000002400a20 l2: 00000100000a6000 l3: fff0000000950000
> > [50690.939419] l4: 00000100000fc000 l5: fff000000196dc20 l6: fff0000001f07938 l7: 00000000010f6fd0
> > [50691.053798] i0: fff0000001f07aa8 i1: 0000000000002000 i2: 00000100000a4000 i3: fff0000008311b00
> > [50691.168170] i4: 0000000000100000 i5: fff0000001448290 i6: fff0000001f07081 i7: 0000000000651cd8
> > [50691.282546] I7: <unmap_vmas+0xf8/0x1a0>
> > [50691.332867] Call Trace:
> > [50691.364891] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
> > [50691.432371] [<000000000065e674>] exit_mmap+0xb4/0x360
> > [50691.498708] [<00000000004647dc>] __mmput+0x3c/0x120
> > [50691.562759] [<00000000004648f4>] mmput+0x34/0x60
> > [50691.623376] [<000000000046b510>] do_exit+0x250/0xa00
> > [50691.688573] [<000000000046bea4>] do_group_exit+0x24/0xa0
> > [50691.758340] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
> > [50691.829256] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> > [50691.905886] Caller[0000000000651cd8]: unmap_vmas+0xf8/0x1a0
> > [50691.979085] Caller[000000000065e674]: exit_mmap+0xb4/0x360
> > [50692.051141] Caller[00000000004647dc]: __mmput+0x3c/0x120
> > [50692.120911] Caller[00000000004648f4]: mmput+0x34/0x60
> > [50692.187246] Caller[000000000046b510]: do_exit+0x250/0xa00
> > [50692.258160] Caller[000000000046bea4]: do_group_exit+0x24/0xa0
> > [50692.333645] Caller[000000000046bf3c]: sys_exit_group+0x1c/0x40
> > [50692.410280] Caller[0000000000406174]: linux_sparc_syscall+0x34/0x44
> > [50692.492629] Caller[fff0000102ad4a74]: 0xfff0000102ad4a74
> > [50692.562397] Instruction DUMP:
> > [50692.562399] ce762010
> > [50692.601281] 02f47fa8
> > [50692.632163] c4362018
> > [50692.663044] <c45c6008>
> > [50692.693926] 86100011
> > [50692.724808] 8e08a001
> > [50692.755689] 8400bfff
> > [50692.786569] 8779d402
> > [50692.817451] c458e018
> >
> > [50692.898656] Fixing recursive fault but reboot is needed!
>
> So, I was able now to even reproduce it in kernel versions as early as 5.2:
>
> [ 122.085803] Unable to handle kernel NULL pointer dereference
> [ 122.160227] tsk->{mm,active_mm}->context = 000000000000009d
> [ 122.233502] tsk->{mm,active_mm}->pgd = fff0000231d14000
> [ 122.302118] \|/ ____ \|/
> [ 122.302118] "@'/ .. \`@"
> [ 122.302118] /_| \__/ |_\
> [ 122.302118] \__U_/
> [ 122.495420] systemd(1): Oops [#1]
> [ 122.538874] CPU: 0 PID: 1 Comm: systemd Not tainted 5.2.0-3-sparc64 #1 Debian 5.2.17-1
> [ 122.642957] TSTATE: 0000004411001601 TPC: 000000000061cd94 TNPC: 000000000061cd98 Y: 00000000 Not tainted
> [ 122.772207] TPC: <vfs_getattr_nosec+0x34/0xc0>
> [ 122.830529] g0: 0000000000000000 g1: 00000000000007ff g2: 0000000000000000 g3: 00000000000007df
> [ 122.944902] g4: fff00002381771c0 g5: 0000000000000003 g6: fff0000238178000 g7: 0000000000000000
> [ 123.059275] o0: fff000023817be18 o1: 0000000000000000 o2: 0000000000000000 o3: fff000023817be18
> [ 123.173658] o4: 0000000000000000 o5: 0000000000000000 sp: fff000023817b341 ret_pc: 000000000061cd7c
> [ 123.292611] RPC: <vfs_getattr_nosec+0x1c/0xc0>
> [ 123.350933] l0: 0000010000204010 l1: fff0000101600e28 l2: e4e45b5b8ae44628 l3: 0000000000000000
> [ 123.465311] l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000000000 l7: fff0000100bff140
> [ 123.579692] i0: fff000023817bd50 i1: fff000023817be18 i2: 0000000000000001 i3: 0000000000000900
> [ 123.694060] i4: 0000000000000000 i5: fff00002320c1210 i6: fff000023817b3f1 i7: 000000000061ce48
> [ 123.808439] I7: <vfs_getattr+0x28/0x40>
> [ 123.858759] Call Trace:
> [ 123.890785] [000000000061ce48] vfs_getattr+0x28/0x40
> [ 123.957123] [000000000061cf64] vfs_statx+0x84/0xc0
> [ 124.021173] [000000000061d918] sys_statx+0x38/0x60
> [ 124.085226] [0000000000406154] linux_sparc_syscall+0x34/0x44
> [ 124.160708] Disabling lock debugging due to kernel taint
> [ 124.230481] Caller[000000000061ce48]: vfs_getattr+0x28/0x40
> [ 124.303680] Caller[000000000061cf64]: vfs_statx+0x84/0xc0
> [ 124.374593] Caller[000000000061d918]: sys_statx+0x38/0x60
> [ 124.445503] Caller[0000000000406154]: linux_sparc_syscall+0x34/0x44
> [ 124.527857] Caller[fff00001013fde40]: 0xfff00001013fde40
> [ 124.597621] Instruction DUMP:
> [ 124.597623] c2264000
> [ 124.636505] 861027df
> [ 124.667386] c45f6028
> [ 124.698267] <c458a050>
> [ 124.729148] 8408a401
> [ 124.760031] 83789403
> [ 124.790910] c2264000
> [ 124.821801] c207600c
> [ 124.852675] 80886800
> [ 124.883556]
> [ 124.954015] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [ 125.054721] Press Stop-A (L1-A) from sun keyboard or send break
> [ 125.054721] twice on console to return to the boot prom
> [ 125.201103] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---
>
> On v5.6, I'm getting an interesting error mentioning D-cache parity errors:
>
> [ 125.743109] CPU[0]: Cheetah+ D-cache parity error at TPC[000000000056bacc]
> [ 125.833511] TPC<bpf_check+0x18ec/0x3060>
> [ 127.909612] systemd-sysv-generator[1677]: SysV service '/etc/init.d/buildd' lacks a native systemd unit file, automatically generating a unit file for compatibility.
> [ 128.104239] systemd-sysv-generator[1677]: Please update package to include a native systemd unit file.
> [ 128.227312] systemd-sysv-generator[1677]: ⚠ This compatibility logic is deprecated, expect removal soon. ⚠
> [ 129.638144] Unable to handle kernel NULL pointer dereference
> [ 129.712528] tsk->{mm,active_mm}->context = 000000000000009e
> [ 129.785808] tsk->{mm,active_mm}->pgd = fff0000233d38000
> [ 129.854522] \|/ ____ \|/
> [ 129.854522] "@'/ .. \`@"
> [ 129.854522] /_| \__/ |_\
> [ 129.854522] \__U_/
> [ 130.047827] systemd(1): Oops [#1]
> [ 130.091278] CPU: 0 PID: 1 Comm: systemd Tainted: G E 5.6.0-2-sparc64 #1 Debian 5.6.14-2
> [ 130.213664] TSTATE: 0000009911001604 TPC: 00000000005506d8 TNPC: 00000000005506dc Y: 00000000 Tainted: G E
> [ 130.361222] TPC: <bpf_prog_realloc+0x38/0xe0>
> [ 130.418486] g0: 0000000002000000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000002
> [ 130.532867] g4: fff000023c178000 g5: 0000000000657300 g6: fff000023c180000 g7: fff000023423e684
> [ 130.647245] o0: ffffffff00002000 o1: 0000000000000001 o2: fff0000234168fa0 o3: 0000000000000000
> [ 130.761617] o4: fff0000237761f80 o5: 0000000000000001 sp: fff000023c182fd1 ret_pc: 00000000005f2c84
> [ 130.880576] RPC: <__vfree+0x24/0x80>
> [ 130.927456] l0: ffffffffffffffff l1: 0000000000000001 l2: 0000000000000400 l3: 0000000002000000
> [ 131.041836] l4: 0000000000debc00 l5: 0000000000000100 l6: 0000000000000001 l7: fff000023c005e40
> [ 131.156213] i0: 000000010004e000 i1: 0000000000002000 i2: 0000000000100cc0 i3: fff0000237761300
> [ 131.270589] i4: 0000000000000001 i5: 0000000000000001 i6: fff000023c183081 i7: 0000000000550a70
> [ 131.384963] I7: <bpf_patch_insn_single+0x70/0x1e0>
> [ 131.447862] Call Trace:
> [ 131.479889] [0000000000550a70] bpf_patch_insn_single+0x70/0x1e0
> [ 131.558814] [000000000055fe58] bpf_patch_insn_data+0x18/0x1c0
> [ 131.635442] [000000000056bed8] bpf_check+0x1cf8/0x3060
> [ 131.704064] [0000000000559778] bpf_prog_load+0x498/0x8e0
> [ 131.774975] [0000000000559d10] __do_sys_bpf+0x150/0x1880
> [ 131.845890] [000000000055b534] sys_bpf+0x14/0x560
> [ 131.908807] [0000000000406154] linux_sparc_syscall+0x34/0x44
> [ 131.984281] Disabling lock debugging due to kernel taint
> [ 132.054051] Caller[0000000000550a70]: bpf_patch_insn_single+0x70/0x1e0
> [ 132.139832] Caller[000000000055fe58]: bpf_patch_insn_data+0x18/0x1c0
> [ 132.223325] Caller[000000000056bed8]: bpf_check+0x1cf8/0x3060
> [ 132.298811] Caller[0000000000559778]: bpf_prog_load+0x498/0x8e0
> [ 132.376588] Caller[0000000000559d10]: __do_sys_bpf+0x150/0x1880
> [ 132.454361] Caller[000000000055b534]: sys_bpf+0x14/0x560
> [ 132.524132] Caller[0000000000406154]: linux_sparc_syscall+0x34/0x44
> [ 132.606483] Caller[fff0000100995b38]: 0xfff0000100995b38
> [ 132.676247] Instruction DUMP:
> [ 132.676249] c25e2020
> [ 132.715134] 92270009
> [ 132.746014] bb326000
> [ 132.776895] <d05860e0>
> [ 132.807776] 400021a1
> [ 132.838657] 9210001d
> [ 132.869540] 80a22000
> [ 132.900422] 12400016
> [ 132.931303] 03003480
> [ 132.962184]
> [ 133.020246] systemd-journald[205]: Time jumped backwards, rotating. (Dropped 1 similar message(s))
> [ 133.138938] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [ 133.239608] Press Stop-A (L1-A) from sun keyboard or send break
> [ 133.239608] twice on console to return to the boot prom
> [ 133.385997] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---
>
> Searching for that error in the archives, yielded this report from 2018 [1] which seems to have never
> been addressed by David Miller.
>
> @Anthony: Can you see any suspicious in the disassembled code that Meelis (CC'ed) posted?
>
> Adrian
>
> > [1] https://lore.kernel.org/all/a4391645-0c4f-bd99-7371-b0e2cb505542@linux.ee/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Found it - was: Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-11 10:44 ` John Paul Adrian Glaubitz
2025-08-11 11:06 ` John Paul Adrian Glaubitz
@ 2025-08-12 12:32 ` John Paul Adrian Glaubitz
2025-08-12 12:34 ` John Paul Adrian Glaubitz
2025-08-21 12:52 ` David Hildenbrand
1 sibling, 2 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-12 12:32 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, osalvador,
Meelis Roos
Hi Anthony,
On Mon, 2025-08-11 at 12:44 +0200, John Paul Adrian Glaubitz wrote:
> Hi,
>
> On Mon, 2025-08-11 at 00:20 +0200, John Paul Adrian Glaubitz wrote:
> > Hi,
> >
> > On Sun, 2025-08-10 at 11:52 +0200, John Paul Adrian Glaubitz wrote:
> > > On Sat, 2025-08-09 at 08:42 +0200, John Paul Adrian Glaubitz wrote:
> > > > Let me know if you have more suggestions to test. I can also provide you with full
> > > > access to this Netra 240 if you send me your public SSH key in a private mail.
> > >
> > > I have narrowed it down to a regression between v6.3 and v6.4 now.
> > >
> > > The bug can be reproduced with the sparc64_defconfig on a Sun Netra 240 by setting
> > > CONFIG_TRANSPARENT_HUGEPAGE=y and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y. When testing
> > > on a modern systemd-based distribution, it's also necessary to enable CGroup support
> > > as well as enable support for Sun partition tables with CONFIG_SUN_PARTITION=y.
> > >
> > > Then it should be a matter of bisecting the commits between v6.3 and v6.4.
> > >
> > > I will do that within the next days as I'm currently a bit busy with other stuff.
> >
> > OK, it turns out it's reproducible on older kernels (but not as old as 4.19) as well.
> > It's just much harder to trigger. I found a reproducer though and will try to find
> > the problematic commit next.
> >
> > [50686.808389] BUG: Bad page map in process sshd-session pte:00000002 pmd:01448000
> > [50686.905701] addr:00000100000a0000 vm_flags:00000075 anon_vma:0000000000000000 mapping:fff000003c8ca4f8 index:50
> > [50687.038425] file:sshd-session fault:filemap_fault mmap:ext4_file_mmap [ext4] read_folio:ext4_read_folio [ext4]
> > [50687.170246] CPU: 0 PID: 37883 Comm: sshd-session Not tainted 6.3.0-2-sparc64 #1 Debian 6.3.11-1
> > [50687.285751] Call Trace:
> > [50687.317771] [<0000000000d660b0>] dump_stack+0x8/0x18
> > [50687.382976] [<000000000064fd1c>] print_bad_pte+0x15c/0x200
> > [50687.455024] [<0000000000650f84>] unmap_page_range+0x3e4/0xbe0
> > [50687.530513] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
> > [50687.597993] [<000000000065e674>] exit_mmap+0xb4/0x360
> > [50687.664331] [<00000000004647dc>] __mmput+0x3c/0x120
> > [50687.728380] [<00000000004648f4>] mmput+0x34/0x60
> > [50687.788999] [<000000000046b510>] do_exit+0x250/0xa00
> > [50687.854194] [<000000000046bea4>] do_group_exit+0x24/0xa0
> > [50687.923962] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
> > [50687.994875] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> > [50688.071518] Disabling lock debugging due to kernel taint
> > [50689.484196] Unable to handle kernel paging request at virtual address 000c000002400000
> > [50689.588368] tsk->{mm,active_mm}->context = 00000000001815a6
> > [50689.661677] tsk->{mm,active_mm}->pgd = fff000000ae60000
> > [50689.730374] \|/ ____ \|/
> > "@'/ .. \`@"
> > /_| \__/ |_\
> > \__U_/
> > [50689.923679] sshd-session(37883): Oops [#1]
> > [50689.977420] CPU: 0 PID: 37883 Comm: sshd-session Tainted: G B 6.3.0-2-sparc64 #1 Debian 6.3.11-1
> > [50690.112384] TSTATE: 0000008811001607 TPC: 00000000006510cc TNPC: 00000000006510d0 Y: 00000000 Tainted: G B
> > [50690.261089] TPC: <unmap_page_range+0x52c/0xbe0>
> > [50690.320650] g0: 00000000000004a8 g1: 000c000000000000 g2: 0000000000008800 g3: ffffffffffffffff
> > [50690.435029] g4: fff0000001ef1280 g5: 0000000031200000 g6: fff0000001f04000 g7: ffffffffffffffff
> > [50690.549403] o0: 000c000002400a20 o1: 00000100000a4000 o2: 0000000100048290 o3: 0000000000000000
> > [50690.663779] o4: 0000000000000001 o5: 000000000000000d sp: fff0000001f06f61 ret_pc: 0000010000000000
> > [50690.782728] RPC: <0x10000000000>
> > [50690.825039] l0: 0000000100048290 l1: 000c000002400a20 l2: 00000100000a6000 l3: fff0000000950000
> > [50690.939419] l4: 00000100000fc000 l5: fff000000196dc20 l6: fff0000001f07938 l7: 00000000010f6fd0
> > [50691.053798] i0: fff0000001f07aa8 i1: 0000000000002000 i2: 00000100000a4000 i3: fff0000008311b00
> > [50691.168170] i4: 0000000000100000 i5: fff0000001448290 i6: fff0000001f07081 i7: 0000000000651cd8
> > [50691.282546] I7: <unmap_vmas+0xf8/0x1a0>
> > [50691.332867] Call Trace:
> > [50691.364891] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
> > [50691.432371] [<000000000065e674>] exit_mmap+0xb4/0x360
> > [50691.498708] [<00000000004647dc>] __mmput+0x3c/0x120
> > [50691.562759] [<00000000004648f4>] mmput+0x34/0x60
> > [50691.623376] [<000000000046b510>] do_exit+0x250/0xa00
> > [50691.688573] [<000000000046bea4>] do_group_exit+0x24/0xa0
> > [50691.758340] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
> > [50691.829256] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> > [50691.905886] Caller[0000000000651cd8]: unmap_vmas+0xf8/0x1a0
> > [50691.979085] Caller[000000000065e674]: exit_mmap+0xb4/0x360
> > [50692.051141] Caller[00000000004647dc]: __mmput+0x3c/0x120
> > [50692.120911] Caller[00000000004648f4]: mmput+0x34/0x60
> > [50692.187246] Caller[000000000046b510]: do_exit+0x250/0xa00
> > [50692.258160] Caller[000000000046bea4]: do_group_exit+0x24/0xa0
> > [50692.333645] Caller[000000000046bf3c]: sys_exit_group+0x1c/0x40
> > [50692.410280] Caller[0000000000406174]: linux_sparc_syscall+0x34/0x44
> > [50692.492629] Caller[fff0000102ad4a74]: 0xfff0000102ad4a74
> > [50692.562397] Instruction DUMP:
> > [50692.562399] ce762010
> > [50692.601281] 02f47fa8
> > [50692.632163] c4362018
> > [50692.663044] <c45c6008>
> > [50692.693926] 86100011
> > [50692.724808] 8e08a001
> > [50692.755689] 8400bfff
> > [50692.786569] 8779d402
> > [50692.817451] c458e018
> >
> > [50692.898656] Fixing recursive fault but reboot is needed!
>
> So, I was able now to even reproduce it in kernel versions as early as 5.2:
>
> [ 122.085803] Unable to handle kernel NULL pointer dereference
> [ 122.160227] tsk->{mm,active_mm}->context = 000000000000009d
> [ 122.233502] tsk->{mm,active_mm}->pgd = fff0000231d14000
> [ 122.302118] \|/ ____ \|/
> [ 122.302118] "@'/ .. \`@"
> [ 122.302118] /_| \__/ |_\
> [ 122.302118] \__U_/
> [ 122.495420] systemd(1): Oops [#1]
> [ 122.538874] CPU: 0 PID: 1 Comm: systemd Not tainted 5.2.0-3-sparc64 #1 Debian 5.2.17-1
> [ 122.642957] TSTATE: 0000004411001601 TPC: 000000000061cd94 TNPC: 000000000061cd98 Y: 00000000 Not tainted
> [ 122.772207] TPC: <vfs_getattr_nosec+0x34/0xc0>
> [ 122.830529] g0: 0000000000000000 g1: 00000000000007ff g2: 0000000000000000 g3: 00000000000007df
> [ 122.944902] g4: fff00002381771c0 g5: 0000000000000003 g6: fff0000238178000 g7: 0000000000000000
> [ 123.059275] o0: fff000023817be18 o1: 0000000000000000 o2: 0000000000000000 o3: fff000023817be18
> [ 123.173658] o4: 0000000000000000 o5: 0000000000000000 sp: fff000023817b341 ret_pc: 000000000061cd7c
> [ 123.292611] RPC: <vfs_getattr_nosec+0x1c/0xc0>
> [ 123.350933] l0: 0000010000204010 l1: fff0000101600e28 l2: e4e45b5b8ae44628 l3: 0000000000000000
> [ 123.465311] l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000000000 l7: fff0000100bff140
> [ 123.579692] i0: fff000023817bd50 i1: fff000023817be18 i2: 0000000000000001 i3: 0000000000000900
> [ 123.694060] i4: 0000000000000000 i5: fff00002320c1210 i6: fff000023817b3f1 i7: 000000000061ce48
> [ 123.808439] I7: <vfs_getattr+0x28/0x40>
> [ 123.858759] Call Trace:
> [ 123.890785] [000000000061ce48] vfs_getattr+0x28/0x40
> [ 123.957123] [000000000061cf64] vfs_statx+0x84/0xc0
> [ 124.021173] [000000000061d918] sys_statx+0x38/0x60
> [ 124.085226] [0000000000406154] linux_sparc_syscall+0x34/0x44
> [ 124.160708] Disabling lock debugging due to kernel taint
> [ 124.230481] Caller[000000000061ce48]: vfs_getattr+0x28/0x40
> [ 124.303680] Caller[000000000061cf64]: vfs_statx+0x84/0xc0
> [ 124.374593] Caller[000000000061d918]: sys_statx+0x38/0x60
> [ 124.445503] Caller[0000000000406154]: linux_sparc_syscall+0x34/0x44
> [ 124.527857] Caller[fff00001013fde40]: 0xfff00001013fde40
> [ 124.597621] Instruction DUMP:
> [ 124.597623] c2264000
> [ 124.636505] 861027df
> [ 124.667386] c45f6028
> [ 124.698267] <c458a050>
> [ 124.729148] 8408a401
> [ 124.760031] 83789403
> [ 124.790910] c2264000
> [ 124.821801] c207600c
> [ 124.852675] 80886800
> [ 124.883556]
> [ 124.954015] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [ 125.054721] Press Stop-A (L1-A) from sun keyboard or send break
> [ 125.054721] twice on console to return to the boot prom
> [ 125.201103] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---
>
> On v5.6, I'm getting an interesting error mentioning D-cache parity errors:
>
> [ 125.743109] CPU[0]: Cheetah+ D-cache parity error at TPC[000000000056bacc]
> [ 125.833511] TPC<bpf_check+0x18ec/0x3060>
> [ 127.909612] systemd-sysv-generator[1677]: SysV service '/etc/init.d/buildd' lacks a native systemd unit file, automatically generating a unit file for compatibility.
> [ 128.104239] systemd-sysv-generator[1677]: Please update package to include a native systemd unit file.
> [ 128.227312] systemd-sysv-generator[1677]: ⚠ This compatibility logic is deprecated, expect removal soon. ⚠
> [ 129.638144] Unable to handle kernel NULL pointer dereference
> [ 129.712528] tsk->{mm,active_mm}->context = 000000000000009e
> [ 129.785808] tsk->{mm,active_mm}->pgd = fff0000233d38000
> [ 129.854522] \|/ ____ \|/
> [ 129.854522] "@'/ .. \`@"
> [ 129.854522] /_| \__/ |_\
> [ 129.854522] \__U_/
> [ 130.047827] systemd(1): Oops [#1]
> [ 130.091278] CPU: 0 PID: 1 Comm: systemd Tainted: G E 5.6.0-2-sparc64 #1 Debian 5.6.14-2
> [ 130.213664] TSTATE: 0000009911001604 TPC: 00000000005506d8 TNPC: 00000000005506dc Y: 00000000 Tainted: G E
> [ 130.361222] TPC: <bpf_prog_realloc+0x38/0xe0>
> [ 130.418486] g0: 0000000002000000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000002
> [ 130.532867] g4: fff000023c178000 g5: 0000000000657300 g6: fff000023c180000 g7: fff000023423e684
> [ 130.647245] o0: ffffffff00002000 o1: 0000000000000001 o2: fff0000234168fa0 o3: 0000000000000000
> [ 130.761617] o4: fff0000237761f80 o5: 0000000000000001 sp: fff000023c182fd1 ret_pc: 00000000005f2c84
> [ 130.880576] RPC: <__vfree+0x24/0x80>
> [ 130.927456] l0: ffffffffffffffff l1: 0000000000000001 l2: 0000000000000400 l3: 0000000002000000
> [ 131.041836] l4: 0000000000debc00 l5: 0000000000000100 l6: 0000000000000001 l7: fff000023c005e40
> [ 131.156213] i0: 000000010004e000 i1: 0000000000002000 i2: 0000000000100cc0 i3: fff0000237761300
> [ 131.270589] i4: 0000000000000001 i5: 0000000000000001 i6: fff000023c183081 i7: 0000000000550a70
> [ 131.384963] I7: <bpf_patch_insn_single+0x70/0x1e0>
> [ 131.447862] Call Trace:
> [ 131.479889] [0000000000550a70] bpf_patch_insn_single+0x70/0x1e0
> [ 131.558814] [000000000055fe58] bpf_patch_insn_data+0x18/0x1c0
> [ 131.635442] [000000000056bed8] bpf_check+0x1cf8/0x3060
> [ 131.704064] [0000000000559778] bpf_prog_load+0x498/0x8e0
> [ 131.774975] [0000000000559d10] __do_sys_bpf+0x150/0x1880
> [ 131.845890] [000000000055b534] sys_bpf+0x14/0x560
> [ 131.908807] [0000000000406154] linux_sparc_syscall+0x34/0x44
> [ 131.984281] Disabling lock debugging due to kernel taint
> [ 132.054051] Caller[0000000000550a70]: bpf_patch_insn_single+0x70/0x1e0
> [ 132.139832] Caller[000000000055fe58]: bpf_patch_insn_data+0x18/0x1c0
> [ 132.223325] Caller[000000000056bed8]: bpf_check+0x1cf8/0x3060
> [ 132.298811] Caller[0000000000559778]: bpf_prog_load+0x498/0x8e0
> [ 132.376588] Caller[0000000000559d10]: __do_sys_bpf+0x150/0x1880
> [ 132.454361] Caller[000000000055b534]: sys_bpf+0x14/0x560
> [ 132.524132] Caller[0000000000406154]: linux_sparc_syscall+0x34/0x44
> [ 132.606483] Caller[fff0000100995b38]: 0xfff0000100995b38
> [ 132.676247] Instruction DUMP:
> [ 132.676249] c25e2020
> [ 132.715134] 92270009
> [ 132.746014] bb326000
> [ 132.776895] <d05860e0>
> [ 132.807776] 400021a1
> [ 132.838657] 9210001d
> [ 132.869540] 80a22000
> [ 132.900422] 12400016
> [ 132.931303] 03003480
> [ 132.962184]
> [ 133.020246] systemd-journald[205]: Time jumped backwards, rotating. (Dropped 1 similar message(s))
> [ 133.138938] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [ 133.239608] Press Stop-A (L1-A) from sun keyboard or send break
> [ 133.239608] twice on console to return to the boot prom
> [ 133.385997] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---
>
> Searching for that error in the archives, yielded this report from 2018 [1] which seems to have never
> been addressed by David Miller.
>
> @Anthony: Can you see any suspicious in the disassembled code that Meelis (CC'ed) posted?
OK, bisecting has lead me to the following commit:
d53d2f78ceadba081fc7785570798c3c8d50a718 is the first bad commit
commit d53d2f78ceadba081fc7785570798c3c8d50a718 (HEAD)
Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
Date: Thu Apr 25 17:11:38 2019 -0700
bpf: Use vmalloc special flag
Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special
permissioned memory in vmalloc and remove places where memory was set RW
before freeing which is no longer needed. Don't track if the memory is RO
anymore because it is now tracked in vmalloc.
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <akpm@linux-foundation.org>
Cc: <ard.biesheuvel@linaro.org>
Cc: <deneen.t.dock@intel.com>
Cc: <kernel-hardening@lists.openwall.com>
Cc: <kristen@linux.intel.com>
Cc: <linux_dti@icloud.com>
Cc: <will.deacon@arm.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190426001143.4983-19-namit@vmware.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
include/linux/filter.h | 17 +++--------------
kernel/bpf/core.c | 1 -
2 files changed, 3 insertions(+), 15 deletions(-)
I assume it's also related to this change:
commit 868b104d7379e28013e9d48bdd2db25e0bdcf751
Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
Date: Thu Apr 25 17:11:36 2019 -0700
mm/vmalloc: Add flag for freeing of special permsissions
Add a new flag VM_FLUSH_RESET_PERMS, for enabling vfree operations to
immediately clear executable TLB entries before freeing pages, and handle
resetting permissions on the directmap. This flag is useful for any kind
of memory with elevated permissions, or where there can be related
permissions changes on the directmap. Today this is RO+X and RO memory.
Although this enables directly vfreeing non-writeable memory now,
non-writable memory cannot be freed in an interrupt because the allocation
itself is used as a node on deferred free list. So when RO memory needs to
be freed in an interrupt the code doing the vfree needs to have its own
work queue, as was the case before the deferred vfree list was added to
vmalloc.
For architectures with set_direct_map_ implementations this whole operation
can be done with one TLB flush when centralized like this. For others with
directmap permissions, currently only arm64, a backup method using
set_memory functions is used to reset the directmap. When arm64 adds
set_direct_map_ functions, this backup can be removed.
When the TLB is flushed to both remove TLB entries for the vmalloc range
mapping and the direct map permissions, the lazy purge operation could be
done to try to save a TLB flush later. However today vm_unmap_aliases
could flush a TLB range that does not include the directmap. So a helper
is added with extra parameters that can allow both the vmalloc address and
the direct mapping to be flushed during this operation. The behavior of the
normal vm_unmap_aliases function is unchanged.
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Suggested-by: Andy Lutomirski <luto@kernel.org>
Suggested-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <akpm@linux-foundation.org>
Cc: <ard.biesheuvel@linaro.org>
Cc: <deneen.t.dock@intel.com>
Cc: <kernel-hardening@lists.openwall.com>
Cc: <kristen@linux.intel.com>
Cc: <linux_dti@icloud.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190426001143.4983-17-namit@vmware.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Found it - was: Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-12 12:32 ` Found it - was: " John Paul Adrian Glaubitz
@ 2025-08-12 12:34 ` John Paul Adrian Glaubitz
2025-08-21 12:52 ` David Hildenbrand
1 sibling, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-12 12:34 UTC (permalink / raw)
To: Anthony Yznaga, sparclinux, davem, andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, david, Oscar Salvador
I accidentally re-added Meelis. Dropping again.
Adrian
On Tue, 2025-08-12 at 14:32 +0200, John Paul Adrian Glaubitz wrote:
> Hi Anthony,
>
> On Mon, 2025-08-11 at 12:44 +0200, John Paul Adrian Glaubitz wrote:
> > Hi,
> >
> > On Mon, 2025-08-11 at 00:20 +0200, John Paul Adrian Glaubitz wrote:
> > > Hi,
> > >
> > > On Sun, 2025-08-10 at 11:52 +0200, John Paul Adrian Glaubitz wrote:
> > > > On Sat, 2025-08-09 at 08:42 +0200, John Paul Adrian Glaubitz wrote:
> > > > > Let me know if you have more suggestions to test. I can also provide you with full
> > > > > access to this Netra 240 if you send me your public SSH key in a private mail.
> > > >
> > > > I have narrowed it down to a regression between v6.3 and v6.4 now.
> > > >
> > > > The bug can be reproduced with the sparc64_defconfig on a Sun Netra 240 by setting
> > > > CONFIG_TRANSPARENT_HUGEPAGE=y and CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y. When testing
> > > > on a modern systemd-based distribution, it's also necessary to enable CGroup support
> > > > as well as enable support for Sun partition tables with CONFIG_SUN_PARTITION=y.
> > > >
> > > > Then it should be a matter of bisecting the commits between v6.3 and v6.4.
> > > >
> > > > I will do that within the next days as I'm currently a bit busy with other stuff.
> > >
> > > OK, it turns out it's reproducible on older kernels (but not as old as 4.19) as well.
> > > It's just much harder to trigger. I found a reproducer though and will try to find
> > > the problematic commit next.
> > >
> > > [50686.808389] BUG: Bad page map in process sshd-session pte:00000002 pmd:01448000
> > > [50686.905701] addr:00000100000a0000 vm_flags:00000075 anon_vma:0000000000000000 mapping:fff000003c8ca4f8 index:50
> > > [50687.038425] file:sshd-session fault:filemap_fault mmap:ext4_file_mmap [ext4] read_folio:ext4_read_folio [ext4]
> > > [50687.170246] CPU: 0 PID: 37883 Comm: sshd-session Not tainted 6.3.0-2-sparc64 #1 Debian 6.3.11-1
> > > [50687.285751] Call Trace:
> > > [50687.317771] [<0000000000d660b0>] dump_stack+0x8/0x18
> > > [50687.382976] [<000000000064fd1c>] print_bad_pte+0x15c/0x200
> > > [50687.455024] [<0000000000650f84>] unmap_page_range+0x3e4/0xbe0
> > > [50687.530513] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
> > > [50687.597993] [<000000000065e674>] exit_mmap+0xb4/0x360
> > > [50687.664331] [<00000000004647dc>] __mmput+0x3c/0x120
> > > [50687.728380] [<00000000004648f4>] mmput+0x34/0x60
> > > [50687.788999] [<000000000046b510>] do_exit+0x250/0xa00
> > > [50687.854194] [<000000000046bea4>] do_group_exit+0x24/0xa0
> > > [50687.923962] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
> > > [50687.994875] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> > > [50688.071518] Disabling lock debugging due to kernel taint
> > > [50689.484196] Unable to handle kernel paging request at virtual address 000c000002400000
> > > [50689.588368] tsk->{mm,active_mm}->context = 00000000001815a6
> > > [50689.661677] tsk->{mm,active_mm}->pgd = fff000000ae60000
> > > [50689.730374] \|/ ____ \|/
> > > "@'/ .. \`@"
> > > /_| \__/ |_\
> > > \__U_/
> > > [50689.923679] sshd-session(37883): Oops [#1]
> > > [50689.977420] CPU: 0 PID: 37883 Comm: sshd-session Tainted: G B 6.3.0-2-sparc64 #1 Debian 6.3.11-1
> > > [50690.112384] TSTATE: 0000008811001607 TPC: 00000000006510cc TNPC: 00000000006510d0 Y: 00000000 Tainted: G B
> > > [50690.261089] TPC: <unmap_page_range+0x52c/0xbe0>
> > > [50690.320650] g0: 00000000000004a8 g1: 000c000000000000 g2: 0000000000008800 g3: ffffffffffffffff
> > > [50690.435029] g4: fff0000001ef1280 g5: 0000000031200000 g6: fff0000001f04000 g7: ffffffffffffffff
> > > [50690.549403] o0: 000c000002400a20 o1: 00000100000a4000 o2: 0000000100048290 o3: 0000000000000000
> > > [50690.663779] o4: 0000000000000001 o5: 000000000000000d sp: fff0000001f06f61 ret_pc: 0000010000000000
> > > [50690.782728] RPC: <0x10000000000>
> > > [50690.825039] l0: 0000000100048290 l1: 000c000002400a20 l2: 00000100000a6000 l3: fff0000000950000
> > > [50690.939419] l4: 00000100000fc000 l5: fff000000196dc20 l6: fff0000001f07938 l7: 00000000010f6fd0
> > > [50691.053798] i0: fff0000001f07aa8 i1: 0000000000002000 i2: 00000100000a4000 i3: fff0000008311b00
> > > [50691.168170] i4: 0000000000100000 i5: fff0000001448290 i6: fff0000001f07081 i7: 0000000000651cd8
> > > [50691.282546] I7: <unmap_vmas+0xf8/0x1a0>
> > > [50691.332867] Call Trace:
> > > [50691.364891] [<0000000000651cd8>] unmap_vmas+0xf8/0x1a0
> > > [50691.432371] [<000000000065e674>] exit_mmap+0xb4/0x360
> > > [50691.498708] [<00000000004647dc>] __mmput+0x3c/0x120
> > > [50691.562759] [<00000000004648f4>] mmput+0x34/0x60
> > > [50691.623376] [<000000000046b510>] do_exit+0x250/0xa00
> > > [50691.688573] [<000000000046bea4>] do_group_exit+0x24/0xa0
> > > [50691.758340] [<000000000046bf3c>] sys_exit_group+0x1c/0x40
> > > [50691.829256] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> > > [50691.905886] Caller[0000000000651cd8]: unmap_vmas+0xf8/0x1a0
> > > [50691.979085] Caller[000000000065e674]: exit_mmap+0xb4/0x360
> > > [50692.051141] Caller[00000000004647dc]: __mmput+0x3c/0x120
> > > [50692.120911] Caller[00000000004648f4]: mmput+0x34/0x60
> > > [50692.187246] Caller[000000000046b510]: do_exit+0x250/0xa00
> > > [50692.258160] Caller[000000000046bea4]: do_group_exit+0x24/0xa0
> > > [50692.333645] Caller[000000000046bf3c]: sys_exit_group+0x1c/0x40
> > > [50692.410280] Caller[0000000000406174]: linux_sparc_syscall+0x34/0x44
> > > [50692.492629] Caller[fff0000102ad4a74]: 0xfff0000102ad4a74
> > > [50692.562397] Instruction DUMP:
> > > [50692.562399] ce762010
> > > [50692.601281] 02f47fa8
> > > [50692.632163] c4362018
> > > [50692.663044] <c45c6008>
> > > [50692.693926] 86100011
> > > [50692.724808] 8e08a001
> > > [50692.755689] 8400bfff
> > > [50692.786569] 8779d402
> > > [50692.817451] c458e018
> > >
> > > [50692.898656] Fixing recursive fault but reboot is needed!
> >
> > So, I was able now to even reproduce it in kernel versions as early as 5.2:
> >
> > [ 122.085803] Unable to handle kernel NULL pointer dereference
> > [ 122.160227] tsk->{mm,active_mm}->context = 000000000000009d
> > [ 122.233502] tsk->{mm,active_mm}->pgd = fff0000231d14000
> > [ 122.302118] \|/ ____ \|/
> > [ 122.302118] "@'/ .. \`@"
> > [ 122.302118] /_| \__/ |_\
> > [ 122.302118] \__U_/
> > [ 122.495420] systemd(1): Oops [#1]
> > [ 122.538874] CPU: 0 PID: 1 Comm: systemd Not tainted 5.2.0-3-sparc64 #1 Debian 5.2.17-1
> > [ 122.642957] TSTATE: 0000004411001601 TPC: 000000000061cd94 TNPC: 000000000061cd98 Y: 00000000 Not tainted
> > [ 122.772207] TPC: <vfs_getattr_nosec+0x34/0xc0>
> > [ 122.830529] g0: 0000000000000000 g1: 00000000000007ff g2: 0000000000000000 g3: 00000000000007df
> > [ 122.944902] g4: fff00002381771c0 g5: 0000000000000003 g6: fff0000238178000 g7: 0000000000000000
> > [ 123.059275] o0: fff000023817be18 o1: 0000000000000000 o2: 0000000000000000 o3: fff000023817be18
> > [ 123.173658] o4: 0000000000000000 o5: 0000000000000000 sp: fff000023817b341 ret_pc: 000000000061cd7c
> > [ 123.292611] RPC: <vfs_getattr_nosec+0x1c/0xc0>
> > [ 123.350933] l0: 0000010000204010 l1: fff0000101600e28 l2: e4e45b5b8ae44628 l3: 0000000000000000
> > [ 123.465311] l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000000000 l7: fff0000100bff140
> > [ 123.579692] i0: fff000023817bd50 i1: fff000023817be18 i2: 0000000000000001 i3: 0000000000000900
> > [ 123.694060] i4: 0000000000000000 i5: fff00002320c1210 i6: fff000023817b3f1 i7: 000000000061ce48
> > [ 123.808439] I7: <vfs_getattr+0x28/0x40>
> > [ 123.858759] Call Trace:
> > [ 123.890785] [000000000061ce48] vfs_getattr+0x28/0x40
> > [ 123.957123] [000000000061cf64] vfs_statx+0x84/0xc0
> > [ 124.021173] [000000000061d918] sys_statx+0x38/0x60
> > [ 124.085226] [0000000000406154] linux_sparc_syscall+0x34/0x44
> > [ 124.160708] Disabling lock debugging due to kernel taint
> > [ 124.230481] Caller[000000000061ce48]: vfs_getattr+0x28/0x40
> > [ 124.303680] Caller[000000000061cf64]: vfs_statx+0x84/0xc0
> > [ 124.374593] Caller[000000000061d918]: sys_statx+0x38/0x60
> > [ 124.445503] Caller[0000000000406154]: linux_sparc_syscall+0x34/0x44
> > [ 124.527857] Caller[fff00001013fde40]: 0xfff00001013fde40
> > [ 124.597621] Instruction DUMP:
> > [ 124.597623] c2264000
> > [ 124.636505] 861027df
> > [ 124.667386] c45f6028
> > [ 124.698267] <c458a050>
> > [ 124.729148] 8408a401
> > [ 124.760031] 83789403
> > [ 124.790910] c2264000
> > [ 124.821801] c207600c
> > [ 124.852675] 80886800
> > [ 124.883556]
> > [ 124.954015] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> > [ 125.054721] Press Stop-A (L1-A) from sun keyboard or send break
> > [ 125.054721] twice on console to return to the boot prom
> > [ 125.201103] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---
> >
> > On v5.6, I'm getting an interesting error mentioning D-cache parity errors:
> >
> > [ 125.743109] CPU[0]: Cheetah+ D-cache parity error at TPC[000000000056bacc]
> > [ 125.833511] TPC<bpf_check+0x18ec/0x3060>
> > [ 127.909612] systemd-sysv-generator[1677]: SysV service '/etc/init.d/buildd' lacks a native systemd unit file, automatically generating a unit file for compatibility.
> > [ 128.104239] systemd-sysv-generator[1677]: Please update package to include a native systemd unit file.
> > [ 128.227312] systemd-sysv-generator[1677]: ⚠ This compatibility logic is deprecated, expect removal soon. ⚠
> > [ 129.638144] Unable to handle kernel NULL pointer dereference
> > [ 129.712528] tsk->{mm,active_mm}->context = 000000000000009e
> > [ 129.785808] tsk->{mm,active_mm}->pgd = fff0000233d38000
> > [ 129.854522] \|/ ____ \|/
> > [ 129.854522] "@'/ .. \`@"
> > [ 129.854522] /_| \__/ |_\
> > [ 129.854522] \__U_/
> > [ 130.047827] systemd(1): Oops [#1]
> > [ 130.091278] CPU: 0 PID: 1 Comm: systemd Tainted: G E 5.6.0-2-sparc64 #1 Debian 5.6.14-2
> > [ 130.213664] TSTATE: 0000009911001604 TPC: 00000000005506d8 TNPC: 00000000005506dc Y: 00000000 Tainted: G E
> > [ 130.361222] TPC: <bpf_prog_realloc+0x38/0xe0>
> > [ 130.418486] g0: 0000000002000000 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000002
> > [ 130.532867] g4: fff000023c178000 g5: 0000000000657300 g6: fff000023c180000 g7: fff000023423e684
> > [ 130.647245] o0: ffffffff00002000 o1: 0000000000000001 o2: fff0000234168fa0 o3: 0000000000000000
> > [ 130.761617] o4: fff0000237761f80 o5: 0000000000000001 sp: fff000023c182fd1 ret_pc: 00000000005f2c84
> > [ 130.880576] RPC: <__vfree+0x24/0x80>
> > [ 130.927456] l0: ffffffffffffffff l1: 0000000000000001 l2: 0000000000000400 l3: 0000000002000000
> > [ 131.041836] l4: 0000000000debc00 l5: 0000000000000100 l6: 0000000000000001 l7: fff000023c005e40
> > [ 131.156213] i0: 000000010004e000 i1: 0000000000002000 i2: 0000000000100cc0 i3: fff0000237761300
> > [ 131.270589] i4: 0000000000000001 i5: 0000000000000001 i6: fff000023c183081 i7: 0000000000550a70
> > [ 131.384963] I7: <bpf_patch_insn_single+0x70/0x1e0>
> > [ 131.447862] Call Trace:
> > [ 131.479889] [0000000000550a70] bpf_patch_insn_single+0x70/0x1e0
> > [ 131.558814] [000000000055fe58] bpf_patch_insn_data+0x18/0x1c0
> > [ 131.635442] [000000000056bed8] bpf_check+0x1cf8/0x3060
> > [ 131.704064] [0000000000559778] bpf_prog_load+0x498/0x8e0
> > [ 131.774975] [0000000000559d10] __do_sys_bpf+0x150/0x1880
> > [ 131.845890] [000000000055b534] sys_bpf+0x14/0x560
> > [ 131.908807] [0000000000406154] linux_sparc_syscall+0x34/0x44
> > [ 131.984281] Disabling lock debugging due to kernel taint
> > [ 132.054051] Caller[0000000000550a70]: bpf_patch_insn_single+0x70/0x1e0
> > [ 132.139832] Caller[000000000055fe58]: bpf_patch_insn_data+0x18/0x1c0
> > [ 132.223325] Caller[000000000056bed8]: bpf_check+0x1cf8/0x3060
> > [ 132.298811] Caller[0000000000559778]: bpf_prog_load+0x498/0x8e0
> > [ 132.376588] Caller[0000000000559d10]: __do_sys_bpf+0x150/0x1880
> > [ 132.454361] Caller[000000000055b534]: sys_bpf+0x14/0x560
> > [ 132.524132] Caller[0000000000406154]: linux_sparc_syscall+0x34/0x44
> > [ 132.606483] Caller[fff0000100995b38]: 0xfff0000100995b38
> > [ 132.676247] Instruction DUMP:
> > [ 132.676249] c25e2020
> > [ 132.715134] 92270009
> > [ 132.746014] bb326000
> > [ 132.776895] <d05860e0>
> > [ 132.807776] 400021a1
> > [ 132.838657] 9210001d
> > [ 132.869540] 80a22000
> > [ 132.900422] 12400016
> > [ 132.931303] 03003480
> > [ 132.962184]
> > [ 133.020246] systemd-journald[205]: Time jumped backwards, rotating. (Dropped 1 similar message(s))
> > [ 133.138938] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> > [ 133.239608] Press Stop-A (L1-A) from sun keyboard or send break
> > [ 133.239608] twice on console to return to the boot prom
> > [ 133.385997] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]---
> >
> > Searching for that error in the archives, yielded this report from 2018 [1] which seems to have never
> > been addressed by David Miller.
> >
> > @Anthony: Can you see any suspicious in the disassembled code that Meelis (CC'ed) posted?
>
> OK, bisecting has lead me to the following commit:
>
> d53d2f78ceadba081fc7785570798c3c8d50a718 is the first bad commit
> commit d53d2f78ceadba081fc7785570798c3c8d50a718 (HEAD)
> Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Date: Thu Apr 25 17:11:38 2019 -0700
>
> bpf: Use vmalloc special flag
>
> Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special
> permissioned memory in vmalloc and remove places where memory was set RW
> before freeing which is no longer needed. Don't track if the memory is RO
> anymore because it is now tracked in vmalloc.
>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: <akpm@linux-foundation.org>
> Cc: <ard.biesheuvel@linaro.org>
> Cc: <deneen.t.dock@intel.com>
> Cc: <kernel-hardening@lists.openwall.com>
> Cc: <kristen@linux.intel.com>
> Cc: <linux_dti@icloud.com>
> Cc: <will.deacon@arm.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Nadav Amit <nadav.amit@gmail.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Link: https://lkml.kernel.org/r/20190426001143.4983-19-namit@vmware.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
>
> include/linux/filter.h | 17 +++--------------
> kernel/bpf/core.c | 1 -
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> I assume it's also related to this change:
>
> commit 868b104d7379e28013e9d48bdd2db25e0bdcf751
> Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Date: Thu Apr 25 17:11:36 2019 -0700
>
> mm/vmalloc: Add flag for freeing of special permsissions
>
> Add a new flag VM_FLUSH_RESET_PERMS, for enabling vfree operations to
> immediately clear executable TLB entries before freeing pages, and handle
> resetting permissions on the directmap. This flag is useful for any kind
> of memory with elevated permissions, or where there can be related
> permissions changes on the directmap. Today this is RO+X and RO memory.
>
> Although this enables directly vfreeing non-writeable memory now,
> non-writable memory cannot be freed in an interrupt because the allocation
> itself is used as a node on deferred free list. So when RO memory needs to
> be freed in an interrupt the code doing the vfree needs to have its own
> work queue, as was the case before the deferred vfree list was added to
> vmalloc.
>
> For architectures with set_direct_map_ implementations this whole operation
> can be done with one TLB flush when centralized like this. For others with
> directmap permissions, currently only arm64, a backup method using
> set_memory functions is used to reset the directmap. When arm64 adds
> set_direct_map_ functions, this backup can be removed.
>
> When the TLB is flushed to both remove TLB entries for the vmalloc range
> mapping and the direct map permissions, the lazy purge operation could be
> done to try to save a TLB flush later. However today vm_unmap_aliases
> could flush a TLB range that does not include the directmap. So a helper
> is added with extra parameters that can allow both the vmalloc address and
> the direct mapping to be flushed during this operation. The behavior of the
> normal vm_unmap_aliases function is unchanged.
>
> Suggested-by: Dave Hansen <dave.hansen@intel.com>
> Suggested-by: Andy Lutomirski <luto@kernel.org>
> Suggested-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: <akpm@linux-foundation.org>
> Cc: <ard.biesheuvel@linaro.org>
> Cc: <deneen.t.dock@intel.com>
> Cc: <kernel-hardening@lists.openwall.com>
> Cc: <kristen@linux.intel.com>
> Cc: <linux_dti@icloud.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Nadav Amit <nadav.amit@gmail.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Link: https://lkml.kernel.org/r/20190426001143.4983-17-namit@vmware.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
>
> Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Found it - was: Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-12 12:32 ` Found it - was: " John Paul Adrian Glaubitz
2025-08-12 12:34 ` John Paul Adrian Glaubitz
@ 2025-08-21 12:52 ` David Hildenbrand
2025-08-21 15:03 ` Edgecombe, Rick P
1 sibling, 1 reply; 26+ messages in thread
From: David Hildenbrand @ 2025-08-21 12:52 UTC (permalink / raw)
To: John Paul Adrian Glaubitz, Anthony Yznaga, sparclinux, davem,
andreas
Cc: linux-kernel, agordeev, will, ryan.roberts, osalvador,
Meelis Roos, Rick Edgecombe
>>
>> @Anthony: Can you see any suspicious in the disassembled code that Meelis (CC'ed) posted?
>
> OK, bisecting has lead me to the following commit:
CCing Rick.
Hm, but that's bpf-only code. Are you sure that it's this exact commit
or rather ....
>
> d53d2f78ceadba081fc7785570798c3c8d50a718 is the first bad commit
> commit d53d2f78ceadba081fc7785570798c3c8d50a718 (HEAD)
> Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Date: Thu Apr 25 17:11:38 2019 -0700
>
> bpf: Use vmalloc special flag
>
> Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special
> permissioned memory in vmalloc and remove places where memory was set RW
> before freeing which is no longer needed. Don't track if the memory is RO
> anymore because it is now tracked in vmalloc.
>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: <akpm@linux-foundation.org>
> Cc: <ard.biesheuvel@linaro.org>
> Cc: <deneen.t.dock@intel.com>
> Cc: <kernel-hardening@lists.openwall.com>
> Cc: <kristen@linux.intel.com>
> Cc: <linux_dti@icloud.com>
> Cc: <will.deacon@arm.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Nadav Amit <nadav.amit@gmail.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Link: https://lkml.kernel.org/r/20190426001143.4983-19-namit@vmware.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
>
> include/linux/filter.h | 17 +++--------------
> kernel/bpf/core.c | 1 -
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> I assume it's also related to this change:
... this one?
>
> commit 868b104d7379e28013e9d48bdd2db25e0bdcf751
> Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Date: Thu Apr 25 17:11:36 2019 -0700
>
> mm/vmalloc: Add flag for freeing of special permsissions
>
> Add a new flag VM_FLUSH_RESET_PERMS, for enabling vfree operations to
> immediately clear executable TLB entries before freeing pages, and handle
> resetting permissions on the directmap. This flag is useful for any kind
> of memory with elevated permissions, or where there can be related
> permissions changes on the directmap. Today this is RO+X and RO memory.
>
> Although this enables directly vfreeing non-writeable memory now,
> non-writable memory cannot be freed in an interrupt because the allocation
> itself is used as a node on deferred free list. So when RO memory needs to
> be freed in an interrupt the code doing the vfree needs to have its own
> work queue, as was the case before the deferred vfree list was added to
> vmalloc.
>
> For architectures with set_direct_map_ implementations this whole operation
> can be done with one TLB flush when centralized like this. For others with
> directmap permissions, currently only arm64, a backup method using
> set_memory functions is used to reset the directmap. When arm64 adds
> set_direct_map_ functions, this backup can be removed.
>
> When the TLB is flushed to both remove TLB entries for the vmalloc range
> mapping and the direct map permissions, the lazy purge operation could be
> done to try to save a TLB flush later. However today vm_unmap_aliases
> could flush a TLB range that does not include the directmap. So a helper
> is added with extra parameters that can allow both the vmalloc address and
> the direct mapping to be flushed during this operation. The behavior of the
> normal vm_unmap_aliases function is unchanged.
>
> Suggested-by: Dave Hansen <dave.hansen@intel.com>
> Suggested-by: Andy Lutomirski <luto@kernel.org>
> Suggested-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: <akpm@linux-foundation.org>
> Cc: <ard.biesheuvel@linaro.org>
> Cc: <deneen.t.dock@intel.com>
> Cc: <kernel-hardening@lists.openwall.com>
> Cc: <kristen@linux.intel.com>
> Cc: <linux_dti@icloud.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Nadav Amit <nadav.amit@gmail.com>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Link: https://lkml.kernel.org/r/20190426001143.4983-17-namit@vmware.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
>
> Adrian
>
--
Cheers
David / dhildenb
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Found it - was: Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-21 12:52 ` David Hildenbrand
@ 2025-08-21 15:03 ` Edgecombe, Rick P
2025-08-21 16:42 ` John Paul Adrian Glaubitz
0 siblings, 1 reply; 26+ messages in thread
From: Edgecombe, Rick P @ 2025-08-21 15:03 UTC (permalink / raw)
To: andreas@gaisler.com, glaubitz@physik.fu-berlin.de,
anthony.yznaga@oracle.com, davem@davemloft.net, david@redhat.com,
sparclinux@vger.kernel.org
Cc: agordeev@linux.ibm.com, osalvador@suse.de,
linux-kernel@vger.kernel.org, will@kernel.org, mroos@linux.ee,
ryan.roberts@arm.com
On Thu, 2025-08-21 at 14:52 +0200, David Hildenbrand wrote:
> > >
> > > @Anthony: Can you see any suspicious in the disassembled code that Meelis
> > > (CC'ed) posted?
> >
> > OK, bisecting has lead me to the following commit:
>
> CCing Rick.
>
> Hm, but that's bpf-only code. Are you sure that it's this exact commit
> or rather ....
>
> >
> > d53d2f78ceadba081fc7785570798c3c8d50a718 is the first bad commit
> > commit d53d2f78ceadba081fc7785570798c3c8d50a718 (HEAD)
> > Author: Rick Edgecombe <rick.p.edgecombe@intel.com>
> > Date: Thu Apr 25 17:11:38 2019 -0700
> >
> > bpf: Use vmalloc special flag
John pinged me on this on another thread:
https://lore.kernel.org/lkml/7e4dfc01e132196d3ff10df18622252a8455d1b8.camel@intel.com/
Quoted:
So far two issues were found with that patch and they were both rare
architectures with broken kernel TLB flushes. Kernel TLB flushes can actually
not be required for a long time, so probably the bug normally looked like
unexplained crashes after days. The VM_FLUSH_RESET_PERMS just made them show
up earlier in a bisectable way.
And actually one of the architectures that was broken was sparc, which got fixed in
d3c976c14ad8 ("sparc64: Fix regression in non-hypervisor TLB flush xcall"). John
was going to explore whether the fix might have been incomplete.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Found it - was: Re: [PATCH] sparc64: fix hugetlb for sun4u
2025-08-21 15:03 ` Edgecombe, Rick P
@ 2025-08-21 16:42 ` John Paul Adrian Glaubitz
0 siblings, 0 replies; 26+ messages in thread
From: John Paul Adrian Glaubitz @ 2025-08-21 16:42 UTC (permalink / raw)
To: Edgecombe, Rick P, andreas@gaisler.com, anthony.yznaga@oracle.com,
davem@davemloft.net, david@redhat.com, sparclinux@vger.kernel.org
Cc: agordeev@linux.ibm.com, osalvador@suse.de,
linux-kernel@vger.kernel.org, will@kernel.org, mroos@linux.ee,
ryan.roberts@arm.com
Hi,
On Thu, 2025-08-21 at 15:03 +0000, Edgecombe, Rick P wrote:
> And actually one of the architectures that was broken was sparc, which got fixed in
> d3c976c14ad8 ("sparc64: Fix regression in non-hypervisor TLB flush xcall"). John
> was going to explore whether the fix might have been incomplete.
Investigations regarding the origin of the problem are still ongoing. The issue is
definitely related to SPARC-specific mm code, more specifically the TLB management
code on Cheetah-based UltraSPARC systems.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2025-08-21 16:46 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-07-16 1:24 [PATCH] sparc64: fix hugetlb for sun4u Anthony Yznaga
2025-07-16 6:18 ` John Paul Adrian Glaubitz
2025-07-16 8:41 ` John Paul Adrian Glaubitz
2025-07-16 16:47 ` Anthony Yznaga
2025-07-24 10:52 ` John Paul Adrian Glaubitz
2025-07-25 5:59 ` John Paul Adrian Glaubitz
2025-07-25 20:46 ` John Paul Adrian Glaubitz
2025-07-25 21:09 ` John Paul Adrian Glaubitz
2025-08-08 21:31 ` John Paul Adrian Glaubitz
2025-08-08 22:15 ` Anthony Yznaga
2025-08-08 22:37 ` John Paul Adrian Glaubitz
2025-08-09 6:23 ` John Paul Adrian Glaubitz
2025-08-09 6:26 ` John Paul Adrian Glaubitz
2025-08-09 6:42 ` John Paul Adrian Glaubitz
2025-08-10 9:52 ` John Paul Adrian Glaubitz
2025-08-10 22:20 ` John Paul Adrian Glaubitz
2025-08-11 8:25 ` David Hildenbrand
2025-08-11 10:44 ` John Paul Adrian Glaubitz
2025-08-11 11:06 ` John Paul Adrian Glaubitz
2025-08-12 12:32 ` Found it - was: " John Paul Adrian Glaubitz
2025-08-12 12:34 ` John Paul Adrian Glaubitz
2025-08-21 12:52 ` David Hildenbrand
2025-08-21 15:03 ` Edgecombe, Rick P
2025-08-21 16:42 ` John Paul Adrian Glaubitz
2025-08-11 8:20 ` David Hildenbrand
2025-08-11 8:28 ` John Paul Adrian Glaubitz
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).