[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ab2138b468994050a817426f8ce4fd784108c210.camel@physik.fu-berlin.de>
Date: Mon, 04 Aug 2025 11:38:34 +0200
From: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
To: Anthony Yznaga <anthony.yznaga@...cle.com>, "Matthew Wilcox (Oracle)"
<willy@...radead.org>, linux-arch@...r.kernel.org
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, "David S. Miller"
<davem@...emloft.net>, sparclinux@...r.kernel.org, Andreas Larsson
<andreas@...sler.com>, Rod Schnell <rods@...radio.com>, Sam James
<sam@...too.org>
Subject: Re: [PATCH v4 25/36] sparc64: Implement the new page table range API
Hi,
On Mon, 2025-08-04 at 08:58 +0200, John Paul Adrian Glaubitz wrote:
> OK, so v6.8 is fine while v6.9 crashes:
>
> [ 39.788224] Unable to handle kernel NULL pointer dereference
> [ 39.862657] tsk->{mm,active_mm}->context = 000000000000004b
> [ 39.935941] tsk->{mm,active_mm}->pgd = fff000000aa98000
> [ 40.004566] \|/ ____ \|/
> [ 40.004566] "@'/ .. \`@"
> [ 40.004566] /_| \__/ |_\
> [ 40.004566] \__U_/
> [ 40.197871] (udev-worker)(88): Oops [#1]
> [ 40.249329] CPU: 0 PID: 88 Comm: (udev-worker) Tainted: P O 6.9.0+ #28
> [ 40.353415] TSTATE: 0000004411001605 TPC: 0000000000df092c TNPC: 0000000000df0930 Y: 00000000 Tainted: P O
> [ 40.502105] TPC: <strlen+0x60/0xd4>
> [ 40.547844] g0: fff000000a3171a1 g1: 0000000000000000 g2: 0000000000000000 g3: 0000000000000001
> [ 40.662224] g4: fff000000aa4dac0 g5: 0000000010000233 g6: fff000000a314000 g7: 0000000000000000
> [ 40.776599] o0: 0000000000000010 o1: 0000000000000010 o2: 0000000001010101 o3: 0000000080808080
> [ 40.890974] o4: 0000000001010000 o5: 0000000000000000 sp: fff000000a317201 ret_pc: 00000000004d4b08
> [ 41.009924] RPC: <module_patient_check_exists.constprop.0+0x48/0x1e0>
> [ 41.094557] l0: fff0000100032f40 l1: 0000000000000000 l2: 0000000000000000 l3: 0000000000000000
> [ 41.208936] l4: 0000000000000000 l5: 0000000000000000 l6: 0000000000000000 l7: 0000000000000000
> [ 41.323311] i0: 00000001000256d8 i1: 0000000001143000 i2: 0000000001143300 i3: 000000000000000b
> [ 41.437686] i4: 0000000000000010 i5: fffffffffffffff8 i6: fff000000a3172e1 i7: 00000000004d63f0
> [ 41.552062] I7: <load_module+0x550/0x1f00>
> [ 41.605811] Call Trace:
> [ 41.637838] [<00000000004d63f0>] load_module+0x550/0x1f00
> [ 41.708752] [<00000000004d7fac>] init_module_from_file+0x6c/0xa0
> [ 41.787670] [<00000000004d81c8>] sys_finit_module+0x188/0x280
> [ 41.863158] [<0000000000406174>] linux_sparc_syscall+0x34/0x44
> [ 41.939790] Caller[00000000004d63f0]: load_module+0x550/0x1f00
> [ 42.016423] Caller[00000000004d7fac]: init_module_from_file+0x6c/0xa0
> [ 42.101059] Caller[00000000004d81c8]: sys_finit_module+0x188/0x280
> [ 42.182266] Caller[0000000000406174]: linux_sparc_syscall+0x34/0x44
> [ 42.264614] Caller[fff000010480e2fc]: 0xfff000010480e2fc
> [ 42.334384] Instruction DUMP:
> [ 42.334387] 96132080
> [ 42.373269] 19004040
> [ 42.404151] 94132101
> [ 42.435030] <da020000>
> [ 42.465914] 9823400a
> [ 42.496793] 808b000b
> [ 42.527674] 024ffffd
> [ 42.558556] 90022004
> [ 42.589437] 8f336018
> [ 42.620318]
>
> So, the regression was introduced with v6.9. Will bisect this later this week.
Looking closer it seems that the original issue seems to be filesystem corruption and the
consecutive crashes with older kernels might be a result of some corrupted binaries.
Will first try to figure out what commit exactly introduced the ext4 issues on sun4u.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Powered by blists - more mailing lists