From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2025-02-03 14:16:47
__die() invokes later __show_regs() -> show_regs_print_info() which
prints the current preemption model.
Remove it from the initial line.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
arch/arm/kernel/traps.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2025-02-10 12:04:32
On 2025-02-03 15:16:26 [+0100], To linux-kernel@vger.kernel.org wrote:
__die() invokes later __show_regs() -> show_regs_print_info() which
prints the current preemption model.
Remove it from the initial line.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Is it okay, to route this via the sched tree?
Sebastian
From: "Russell King (Oracle)" <linux@armlinux.org.uk> Date: 2025-02-10 15:16:20
On Mon, Feb 10, 2025 at 01:04:29PM +0100, Sebastian Andrzej Siewior wrote:
On 2025-02-03 15:16:26 [+0100], To linux-kernel@vger.kernel.org wrote:
quoted
__die() invokes later __show_regs() -> show_regs_print_info() which
prints the current preemption model.
Remove it from the initial line.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Is it okay, to route this via the sched tree?
Sorry, its not obvious where show_regs_print_info() prints this.
dump_stack_print_info() itself doesn't directly. print_worker_info()
doesn't. print_stop_info() doesn't. Not sure whether print_scx_info()
does.
Maybe showing example output would help?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Date: 2025-02-10 15:39:07
On 2025-02-10 15:16:11 [+0000], Russell King (Oracle) wrote:
On Mon, Feb 10, 2025 at 01:04:29PM +0100, Sebastian Andrzej Siewior wrote:
quoted
On 2025-02-03 15:16:26 [+0100], To linux-kernel@vger.kernel.org wrote:
quoted
__die() invokes later __show_regs() -> show_regs_print_info() which
prints the current preemption model.
Remove it from the initial line.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Is it okay, to route this via the sched tree?
Sorry, its not obvious where show_regs_print_info() prints this.
dump_stack_print_info() itself doesn't directly. print_worker_info()
doesn't. print_stop_info() doesn't. Not sure whether print_scx_info()
does.
Maybe showing example output would help?
Patch 2/9 adds this. [ https://lore.kernel.org/all/20250203141632.440554-3-bigeasy@linutronix.de/ ]
This this applied, die("test") on ARM ends as:
[ 1.595106] Kernel panic - not syncing: test
[ 1.596044] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.14.0-rc2-00009-gb80a798df08c-dirty #13 PREEMPT
[ 1.596768] Tainted: [W]=WARN
[ 1.596946] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022
[ 1.597407] Call trace:
[ 1.598183] unwind_backtrace from show_stack+0x10/0x14
[ 1.599231] show_stack from dump_stack_lvl+0x50/0x64
[ 1.599492] dump_stack_lvl from panic+0x114/0x358
[ 1.599824] panic from kernel_init+0x64/0x74
[ 1.600048] kernel_init from ret_from_fork+0x14/0x38
[ 1.600349] Exception stack(0xdf829fb0 to 0xdf829ff8)
[ 1.600730] 9fa0: 00000000 00000000 00000000 00000000
[ 1.601102] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.601447] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1.603163] ---[ end Kernel panic - not syncing: test ]---
Sebastian
From: "Russell King (Oracle)" <linux@armlinux.org.uk> Date: 2025-02-10 16:27:04
On Mon, Feb 10, 2025 at 04:39:02PM +0100, Sebastian Andrzej Siewior wrote:
On 2025-02-10 15:16:11 [+0000], Russell King (Oracle) wrote:
quoted
On Mon, Feb 10, 2025 at 01:04:29PM +0100, Sebastian Andrzej Siewior wrote:
quoted
On 2025-02-03 15:16:26 [+0100], To linux-kernel@vger.kernel.org wrote:
quoted
__die() invokes later __show_regs() -> show_regs_print_info() which
prints the current preemption model.
Remove it from the initial line.
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Is it okay, to route this via the sched tree?
Sorry, its not obvious where show_regs_print_info() prints this.
dump_stack_print_info() itself doesn't directly. print_worker_info()
doesn't. print_stop_info() doesn't. Not sure whether print_scx_info()
does.
Maybe showing example output would help?
That explains it - patch 2 is only sent to a very restricted subset
and not even to mailing lists that would be relevant in the absence
of a direct Cc. Ditto patch 1. All I received were patches 3 and 4.
In patch 1:
+ static char buf[128];
...
+ seq_buf_init(&s, buf, 128);
Why not sizeof(buf) ?
For patch 2:
"Use
pr_warn() instead of printk() to pass a loglevel. This makes it part of
generic WARN/ BUG traces.
"
How about cases which use dump_stack_lvl() to dump the output at a more
severe level than warning? Should the message be printed at a less
severe level than the other messages?
This this applied, die("test") on ARM ends as:
[ 1.595106] Kernel panic - not syncing: test
[ 1.596044] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.14.0-rc2-00009-gb80a798df08c-dirty #13 PREEMPT
[ 1.596768] Tainted: [W]=WARN
[ 1.596946] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022
Hmm. I've no idea what you're testing, what you've quoted makes zero
sense to me.
First...
void die(const char *str, struct pt_regs *regs, int err)
is the die function prototype, so it takes a bit more than what you've
indicated.
Second, "Kernel panic" suggests that panic() has been called. However,
this only happens when die() is called (or more specifically
oops_end()) from either interrupt context (in which case we get
"Kernel panic - Fatal exception in interrupt") or if panic_on_oops
is set ("Kernel panic - Fatal exception").
I don't see a path which would result in
"Kernel panic - not syncing: test" to be printed from this path.
Since __die() does not call dump_stack(), we're not going to call
dump_stack_print_info() from __die(), so I don't think it's appropriate
to remove this information.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
That explains it - patch 2 is only sent to a very restricted subset
and not even to mailing lists that would be relevant in the absence
of a direct Cc. Ditto patch 1. All I received were patches 3 and 4.
In patch 1:
+ static char buf[128];
...
+ seq_buf_init(&s, buf, 128);
Why not sizeof(buf) ?
Indeed, why not. Updated.
For patch 2:
"Use
pr_warn() instead of printk() to pass a loglevel. This makes it part of
generic WARN/ BUG traces.
"
How about cases which use dump_stack_lvl() to dump the output at a more
severe level than warning? Should the message be printed at a less
severe level than the other messages?
This is bad indeed. I reverted that piece.
quoted
This this applied, die("test") on ARM ends as:
[ 1.595106] Kernel panic - not syncing: test
[ 1.596044] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.14.0-rc2-00009-gb80a798df08c-dirty #13 PREEMPT
[ 1.596768] Tainted: [W]=WARN
[ 1.596946] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022
Hmm. I've no idea what you're testing, what you've quoted makes zero
sense to me.
First...
void die(const char *str, struct pt_regs *regs, int err)
is the die function prototype, so it takes a bit more than what you've
indicated.
Second, "Kernel panic" suggests that panic() has been called. However,
this only happens when die() is called (or more specifically
oops_end()) from either interrupt context (in which case we get
"Kernel panic - Fatal exception in interrupt") or if panic_on_oops
is set ("Kernel panic - Fatal exception").
I don't see a path which would result in
"Kernel panic - not syncing: test" to be printed from this path.
Since __die() does not call dump_stack(), we're not going to call
dump_stack_print_info() from __die(), so I don't think it's appropriate
to remove this information.
Okay. Let me try again with a stack overflow during boot. With the
series:
| Freeing unused kernel image (initmem) memory: 2048K
| 8<--- cut here ---
| Unable to handle kernel paging request at virtual address df82a000 when write
| [df82a000] *pgd=80000040007003, *pmd=41487003, *pte=00000000
| Internal error: Oops: a07 [#1] SMP ARM
| Modules linked in:
| CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.14.0-rc2-00009-gdca8d546a8a3-dirty #16 PREEMPT
| Tainted: [W]=WARN
| Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022
| PC is at mmioset+0x38/0xac
| LR is at 0x34343434
| pc : [<c0a07a58>] lr : [<34343434>] psr: 20000013
| sp : df829c88 ip : df829ff4 fp : 00000000
| r10: 00000000 r9 : 00000000 r8 : 34343434
| r7 : 00000000 r6 : 00000000 r5 : c0a33278 r4 : c1207bd4
| r3 : 34343434 r2 : 00000080 r1 : 34343434 r0 : df829ea4
| Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
| Control: 30c5387d Table: 40003000 DAC: 00000001
| Register r0 information: 2-page vmalloc region starting at 0xdf828000 allocated at kernel_clone+0x58/0x3b8
…
| Process swapper/0 (pid: 1, stack limit = 0x4c737b1e)
| Stack: (0xdf829c88 to 0xdf82a000)
…
| Call trace:
| mmioset from func+0x24/0x50
| func from kernel_init+0x7c/0x168
| kernel_init from 0x34343434
| Code: e1a08001 e1a0e003 e2522040 a8ac410a (a8ac410a)
| ---[ end trace 0000000000000000 ]---
| Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
| ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
Without:
| Freeing unused kernel image (initmem) memory: 2048K
| 8<--- cut here ---
| Unable to handle kernel paging request at virtual address df82a000 when write
| [df82a000] *pgd=80000040007003, *pmd=41487003, *pte=00000000
| Internal error: Oops: a07 [#1] PREEMPT SMP ARM
| Modules linked in:
| CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.14.0-rc2-00010-ged8f7288c355-dirty #17
| Tainted: [W]=WARN
| Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022
| PC is at mmioset+0x38/0xac
| LR is at 0x34343434
| pc : [<c0a079d8>] lr : [<34343434>] psr: 20000113
| sp : df829c88 ip : df829ff4 fp : 00000000
| r10: 00000000 r9 : 00000000 r8 : 34343434
| r7 : 00000000 r6 : 00000000 r5 : c0a331ec r4 : c1207bd4
| r3 : 34343434 r2 : 00000080 r1 : 34343434 r0 : df829ea4
| Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
| Control: 30c5387d Table: 40003000 DAC: 00000001
| Register r0 information: 2-page vmalloc region starting at 0xdf828000 allocated at kernel_clone+0x58/0x3b8
…
| Process swapper/0 (pid: 1, stack limit = 0x7d941701)
| Stack: (0xdf829c88 to 0xdf82a000)
…
| Call trace:
| mmioset from func+0x24/0x50
| func from kernel_init+0x7c/0x168
| kernel_init from 0x34343434
| Code: e1a08001 e1a0e003 e2522040 a8ac410a (a8ac410a)
| ---[ end trace 0000000000000000 ]---
| Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
| ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
As you see, the PREEMPT string moved and is still existing.
Sebastian
From: "Russell King (Oracle)" <linux@armlinux.org.uk> Date: 2025-02-11 15:05:46
On Tue, Feb 11, 2025 at 03:52:49PM +0100, Sebastian Andrzej Siewior wrote:
On 2025-02-10 16:26:56 [+0000], Russell King (Oracle) wrote:
quoted
quoted
This this applied, die("test") on ARM ends as:
[ 1.595106] Kernel panic - not syncing: test
[ 1.596044] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.14.0-rc2-00009-gb80a798df08c-dirty #13 PREEMPT
[ 1.596768] Tainted: [W]=WARN
[ 1.596946] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022
Hmm. I've no idea what you're testing, what you've quoted makes zero
sense to me.
First...
void die(const char *str, struct pt_regs *regs, int err)
is the die function prototype, so it takes a bit more than what you've
indicated.
Second, "Kernel panic" suggests that panic() has been called. However,
this only happens when die() is called (or more specifically
oops_end()) from either interrupt context (in which case we get
"Kernel panic - Fatal exception in interrupt") or if panic_on_oops
is set ("Kernel panic - Fatal exception").
I don't see a path which would result in
"Kernel panic - not syncing: test" to be printed from this path.
Since __die() does not call dump_stack(), we're not going to call
dump_stack_print_info() from __die(), so I don't think it's appropriate
to remove this information.
Okay. Let me try again with a stack overflow during boot. With the
series:
| Freeing unused kernel image (initmem) memory: 2048K
| 8<--- cut here ---
| Unable to handle kernel paging request at virtual address df82a000 when write
| [df82a000] *pgd=80000040007003, *pmd=41487003, *pte=00000000
| Internal error: Oops: a07 [#1] SMP ARM
| Modules linked in:
| CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.14.0-rc2-00009-gdca8d546a8a3-dirty #16 PREEMPT
Got it. Printed from __die() -> __show_regs() -> show_regs_print_info()
-> dump_stack_print_info().
Reviewed-by: Russell King (Oracle) <redacted>
Thanks!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!