Re: Linux kernel stability fixes for older SPARCs
- To: Gregor Riepl <onitake@gmail.com>
- Cc: debian-sparc@lists.debian.org
- Subject: Re: Linux kernel stability fixes for older SPARCs
- From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
- Date: Fri, 01 Nov 2024 13:46:19 +0100
- Message-id: <[🔎] 5902265b378d549c91e959a7116f13a015c53c51.camel@physik.fu-berlin.de>
- In-reply-to: <b69ad231-b1dc-4b2b-a398-b7c9468638c5@gmail.com>
- References: <caf9102c649a8c76e7eb444ab8c702e3a8da8a52.camel@physik.fu-berlin.de> <E03776ED-377E-4FE5-86B9-A07306E4B4D4@exactcode.com> <cdcc68cc5967f13b4755b9e18ef54ab4b8a560cd.camel@physik.fu-berlin.de> <933ab1b8-fd6a-4328-80f7-91039fb57ec5@gmail.com> <4e1fc649e1d3c291c8bdb843cdc78d9fcf375b10.camel@physik.fu-berlin.de> <4dccfd31-87dd-44a9-aecd-ec19c2703162@gmail.com> <375e67a56b22fa4a08509463fd02ddbf96d385f5.camel@physik.fu-berlin.de> <b69ad231-b1dc-4b2b-a398-b7c9468638c5@gmail.com>
Hi Gregor,
On Mon, 2024-09-23 at 00:20 +0200, Gregor Riepl wrote:
> >
> > It's probably due to CONFIG_DEBUG_INFO. Try turning that off. Debian builds the kernel with debug
> > symbols enabled and then runs the strip command afterwards. This way both a debug and a standard
> > kernel package can be provided from the same build.
>
> Ah thanks, that did the trick.
>
> I built a 6.10.0 kernel using the Debian 6.10.7-sparc64-smp config, with module signing turned off.
> This kernel crashed instantly at boot, just after checking the rootfs. The fsck output was intermingled with the kernel log, but it did complete with a "done."
>
> Begin: Will now check root file system ... fsck from util-linux 2.38.1
> [ 68.420534] \|/ ____ \|/
> [ 68.420534] "@'/ .. \`@"
> [ 68.420534] /_| \__/ |_\
> [ 68.420534] \__U_/
> [ 68.630552] mount(192): Kernel illegal instruction [#1]
> [ 68.715911] CPU: 0 PID: 192 Comm: mount Tainted: G E 6.10.0 #28
> [ 68.828841] TSTATE: 0000000011001605 TPC: 0000000010320158 TNPC: 000000001032015c Y: 00000000 Tainted: G E
> [ 68.994452] TPC: <ext4_find_extent+0x3f8/0x580 [ext4]>
> [ 69.078729] g0: 0000000000000001 g1: 0000000000010000 g2: 0000000000000000 g3: 0000000000000000
> [ 69.209968] g4: fff000100210ac00 g5: fff000103e442000 g6: fff0000000598000 g7: 0000000000000000
> [ 69.341210] o0: 0000000000000200 o1: fff00000029cc3e8 o2: 0000000000000001 o3: 00000000103cc1b0
> [ 69.472457] o4: 0000000000001678 o5: 000000000000b000 sp: fff000000059a8d1 ret_pc: 0000000000ea309c
> [ 69.608287] RPC: <__cond_resched+0x1c/0x60>
> [ 69.679947] l0: fff0000000d06416 l1: fff00000029cc128 l2: 0000000100010000 l3: 0000000000ffffff
> [ 69.811203] l4: 0000000000000000 l5: 0000000000000005 l6: 0000000000010001 l7: 0000000000000002
> [ 69.942448] i0: 0000000000010001 i1: 0000000000000000 i2: 0000000000000000 i3: 0000000000000000
> [ 70.070570] i4: 0000000000000000 i5: 0000000000000001 i6: fff000000059a9a1 i7: 0000000010325748
> [ 70.185151] I7: <ext4_ext_map_blocks+0x68/0x2060 [ext4]>
> [ 70.255147] Call Trace:
> [ 70.287221] [<0000000010325748>] ext4_ext_map_blocks+0x68/0x2060 [ext4]
> [ 70.374417] [<000000001033ee38>] ext4_map_blocks+0x98/0x6c0 [ext4]
> [ 70.455872] [<000000001033fd34>] ext4_iomap_begin+0x254/0x2e0 [ext4]
> [ 70.539621] [<00000000007f494c>] iomap_iter+0x14c/0x420
> [ 70.608470] [<00000000007fa5f0>] iomap_bmap+0x70/0xe0
> [ 70.674929] [<000000001033bd3c>] ext4_bmap+0x9c/0xe0 [ext4]
> [ 70.748366] [<0000000000789404>] bmap+0x24/0x40
> [ 70.808051] [<00000000102d7e54>] jbd2_journal_init_inode+0x14/0x120 [jbd2]
> [ 70.898675] [<0000000010385c2c>] ext4_load_and_init_journal+0xec/0xd20 [ext4]
> [ 70.992740] [<000000001038bd78>] ext4_fill_super+0x2638/0x2aa0 [ext4]
> [ 71.077631] [<000000000076ae5c>] get_tree_bdev+0xfc/0x1c0
> [ 71.148774] [<0000000010377c34>] ext4_get_tree+0x14/0x40 [ext4]
> [ 71.226799] [<000000000076b4c0>] vfs_get_tree+0x20/0x120
> [ 71.296792] [<0000000000796f0c>] path_mount+0x40c/0xa60
> [ 71.365539] [<0000000000797a94>] sys_mount+0xf4/0x1c0
> [ 71.431997] [<0000000000406274>] linux_sparc_syscall+0x34/0x44
>
> I'll try a bisect with that config now, perhaps I can find something.
Could you try whether reverting the following commit fixes it?
commit 223b5e57d0d50b0c07b933350dbcde92018d3080
Author: Mike Rapoport (IBM) <rppt@kernel.org>
Date: Sun May 5 19:06:20 2024 +0300
mm/execmem, arch: convert remaining overrides of module_alloc to execmem
Alternatively, please try the following change:
diff --git a/mm/execmem.c b/mm/execmem.c
index 0c4b36bc6d10..8232f9767c8c 100644
--- a/mm/execmem.c
+++ b/mm/execmem.c
@@ -17,7 +17,11 @@ static struct execmem_info default_execmem_info __ro_after_init;
static void *__execmem_alloc(struct execmem_range *range, size_t size)
{
bool kasan = range->flags & EXECMEM_KASAN_SHADOW;
+#ifndef __sparc__
unsigned long vm_flags = VM_FLUSH_RESET_PERMS;
+#else
+ unsigned long vm_flags = 0;
+#endif
gfp_t gfp_flags = GFP_KERNEL | __GFP_NOWARN;
unsigned long start = range->start;
unsigned long end = range->end;
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: