[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250211145249.StI6tEZv@linutronix.de>
Date: Tue, 11 Feb 2025 15:52:49 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
Ben Segall <bsegall@...gle.com>,
Catalin Marinas <catalin.marinas@....com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
Mel Gorman <mgorman@...e.de>, Peter Zijlstra <peterz@...radead.org>,
Shrikanth Hegde <sshegde@...ux.ibm.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Valentin Schneider <vschneid@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Will Deacon <will@...nel.org>, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 3/9] arm: Rely on generic printing of preemption model.
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
Powered by blists - more mailing lists