Re: [PATCH v2 3/9] arm: Rely on generic printing of preemption model.

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2025-02-10 16:26:56 [+0000], Russell King (Oracle) wrote:
> > Patch 2/9 adds this. [ https://lore.kernel.org/all/20250203141632.440554-3-bigeasy@linutronix.de/ ]
> 
> 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.

> > 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