Instruction dump:
80010024 8361000c 83c10018 83810010 7c0803a6 83a10014 83e1001c 38210020
4e800020 2c040000 41820260 7d032214 <9421fff0> 7c034040 41810154 3d40b000
---[ end trace 0000000000000000 ]---
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #1 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 301066
--> https://bugzilla.kernel.org/attachment.cgi?id=301066&action=edit
dmesg (5.18.0, PowerMac G4 DP), case 2
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #2 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 301067
--> https://bugzilla.kernel.org/attachment.cgi?id=301067&action=edit
kernel .config (5.18.0, PowerMac G4 DP)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #3 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
I can't see any issue, other than your CONFIG_THREAD_SHIFT is set to 13.
It should be 14 by default, see
https://elixir.bootlin.com/linux/v5.18/source/arch/powerpc/Kconfig#L769
Is there any reason why you set it to 13 ?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #4 from Arnd Bergmann (arnd@arndb.de) ---
Setting it higher is probably a good idea, but there really isn't a safe limit
with KASAN, at least if KASAN_STACK is active, running with KASAN always has a
risk of running into stack overflow issues.
One thing that sticks out is that there is an interrupt on the same stack as
the task, in
[eaa1c800] [c0009258] do_IRQ+0x20/0x34
[eaa1c820] [c00045b4] HardwareInterrupt_virt+0x108/0x10c
[eaa1c920] [c0c59b2c] __schedule+0x3f0/0x9dc
[eaa1c9b0] [c0c5a18c] schedule+0x74/0x13c
It looks like on ppc32, as of 547db12fd8a0 ("powerpc/32: Use vmapped stacks for
interrupts"), you have either VMAP_STACK (to detect stack overflows) or IRQ
stacks (to make them less likely). I think you really want both instead, and
allocate the IRQ stacks from vmalloc space as well.
The ext4 read path is a bit wasteful with KASAN enabled, using 1776 bytes from
ext4_lookup to ext4_read_bh, but not excessively so.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #5 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
There is an interrupt, that needs too looked at a bit deeper:
[eaa1c7a0] [c07d0bd4] dump_stack_lvl+0x60/0x90
[eaa1c7c0] [c0009234] __do_IRQ+0x170/0x174
[eaa1c800] [c0009258] do_IRQ+0x20/0x34
[eaa1c820] [c00045b4] HardwareInterrupt_virt+0x108/0x10c
The interesting part is __do_IRQ() :
void __do_IRQ(struct pt_regs *regs)
{
struct pt_regs *old_regs = set_irq_regs(regs);
void *cursp, *irqsp, *sirqsp;
/* Switch to the irq stack to handle this */
cursp = (void *)(current_stack_pointer & ~(THREAD_SIZE - 1));
irqsp = hardirq_ctx[raw_smp_processor_id()];
sirqsp = softirq_ctx[raw_smp_processor_id()];
check_stack_overflow();
/* Already there ? */
if (unlikely(cursp == irqsp || cursp == sirqsp)) {
__do_irq(regs);
set_irq_regs(old_regs);
return;
}
/* Switch stack and call */
call_do_irq(regs, irqsp);
set_irq_regs(old_regs);
}
The dump_stack() we see in the call trace is from check_stack_overflow(),
following the message "do_IRQ: stack overflow: 1984", because the stack dropped
below 0xeaa1c800
check_stack_overflow() function emits a warning and a stack dump when
CONFIG_DEBUG_STACKOVERFLOW is selected and only 2kbytes remain available on the
stack.
But here we get an Oops when the stack reaches 0xeaa1c000. Seems like the
2kbytes limit it not enough to properly perform the stack dump.
Commit 547db12fd8a0 ("powerpc/32: Use vmapped stacks for interrupts") doesn't
remove IRQ stacks. It change the IRQ stacks allocation from kmalloc to vmalloc.
Here we are stillon the original stack. The switch to the IRQ stack is
performed by call_do_irq().
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
I was not aware setting it to a custom value. I thought 13 is the default on
ppc32 which gets overriden to 14 if I select KASAN?
But I'll make sure I'll double check this on future builds. Only advanced
option I did set is CONFIG_LOWMEM_SIZE=0x28000000 (see bug #215389).
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #7 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 301129
--> https://bugzilla.kernel.org/attachment.cgi?id=301129&action=edit
kernel .config (5.19-rc1, Outline KASAN + patches, PowerMac G4 DP)
Tried to reinvestigate this issue with a KASAN build of v5.19-rc1 but it seems
it's not quite there.
I applied the 2 patches "powerpc-kasan-Force-thread-size-increase-with-KASAN"
and
"v2-powerpc-irq-Increase-stack_overflow-detection-limit-when-KASAN-is-enabled"
on top of v5.19-rc1 but I get a non-booting kernel. The kernel boots first but
gets stuck on a white screen reading
"done
found display: /pci@f0000000/ATY,AlteracParent@10/ATY,Alterac_B@1, opening..."
Kernel with same config but with KFENCE instead of KASAN boots fine (see bug
#216095).
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #8 from Erhard F. (erhard_f@mailbox.org) ---
Reinvestigate this issue with a KASAN build of v6.0.0-rc2 and it's looking good
so far! No stack overflow at boot, did about 10 reboots. Outline KASAN also
seems to work fine.
I'll keep an eye on this and close here if I don't see it the next few kernel
releases.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=216041
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |michael@ellerman.id.au
Resolution|--- |CODE_FIX
--- Comment #9 from Michael Ellerman (michael@ellerman.id.au) ---
The two patches mentioned in comment #7 were merged as:
3e8635fb2e07 ("powerpc/kasan: Force thread size increase with KASAN")
https://git.kernel.org/torvalds/c/3e8635fb2e072672cbc650989ffedf8300ad67fb
41f20d6db2b6 ("powerpc/irq: Increase stack_overflow detection limit when KASAN
is enabled")
https://git.kernel.org/torvalds/c/41f20d6db2b64677225bb0b97df956241c353ef8
The boot failure with v5.19-rc1 might have been some other issue?
I'll close this for now, please reopen if you see this again.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=216041
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
--- Comment #10 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
I'm away from the office until April 24th
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.