2018-01-27 04:13:36

by Dave Young

[permalink] [raw]
Subject: [PATCH V2] print kdump kernel loaded status in stack dump

It is useful to print kdump kernel loaded status in dump_stack()
especially when panic happens so that we can differenciate
kdump kernel early hang and a normal panic in a bug report.

Signed-off-by: Dave Young <[email protected]>
---
[v1 -> v2] merge the status in other line as Andi Kleen suggested
kernel/printk/printk.c | 3 +++
---
kernel/printk/printk.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- linux-x86.orig/kernel/printk/printk.c
+++ linux-x86/kernel/printk/printk.c
@@ -48,6 +48,7 @@
#include <linux/sched/clock.h>
#include <linux/sched/debug.h>
#include <linux/sched/task_stack.h>
+#include <linux/kexec.h>

#include <linux/uaccess.h>
#include <asm/sections.h>
@@ -3118,9 +3119,11 @@ void __init dump_stack_set_arch_desc(con
*/
void dump_stack_print_info(const char *log_lvl)
{
- printk("%sCPU: %d PID: %d Comm: %.20s %s %s %.*s\n",
+ printk("%sCPU: %d PID: %d Comm: %.20s %s%s %s %.*s\n",
log_lvl, raw_smp_processor_id(), current->pid, current->comm,
- print_tainted(), init_utsname()->release,
+ kexec_crash_loaded() ? "Kdump: loaded " : "",
+ print_tainted(),
+ init_utsname()->release,
(int)strcspn(init_utsname()->version, " "),
init_utsname()->version);



2018-01-30 08:51:48

by Sergey Senozhatsky

[permalink] [raw]
Subject: Re: [PATCH V2] print kdump kernel loaded status in stack dump

On (01/27/18 12:11), Dave Young wrote:
> It is useful to print kdump kernel loaded status in dump_stack()
> especially when panic happens so that we can differenciate
> kdump kernel early hang and a normal panic in a bug report.
>
> Signed-off-by: Dave Young <[email protected]>

Looks OK to me.

Reviewed-by: Sergey Senozhatsky <[email protected]>


I agree with Steven, would be better to move the whole thing
to lib/dump_stack.c

-ss

2018-01-30 09:08:23

by Dave Young

[permalink] [raw]
Subject: Re: [PATCH V2] print kdump kernel loaded status in stack dump

On 01/30/18 at 05:50pm, Sergey Senozhatsky wrote:
> On (01/27/18 12:11), Dave Young wrote:
> > It is useful to print kdump kernel loaded status in dump_stack()
> > especially when panic happens so that we can differenciate
> > kdump kernel early hang and a normal panic in a bug report.
> >
> > Signed-off-by: Dave Young <[email protected]>
>
> Looks OK to me.
>
> Reviewed-by: Sergey Senozhatsky <[email protected]>
>

Thank you Sergey

>
> I agree with Steven, would be better to move the whole thing
> to lib/dump_stack.c

If nobody has plan I can put it in my todo list, probably do it next
week.

>
> -ss

Thanks
Dave

2018-01-30 09:37:29

by Petr Mladek

[permalink] [raw]
Subject: Re: [PATCH V2] print kdump kernel loaded status in stack dump

On Tue 2018-01-30 17:07:29, Dave Young wrote:
> On 01/30/18 at 05:50pm, Sergey Senozhatsky wrote:
> > On (01/27/18 12:11), Dave Young wrote:
> > > It is useful to print kdump kernel loaded status in dump_stack()
> > > especially when panic happens so that we can differenciate
> > > kdump kernel early hang and a normal panic in a bug report.
> > >
> > > Signed-off-by: Dave Young <[email protected]>
> >
> > Looks OK to me.
> >
> > Reviewed-by: Sergey Senozhatsky <[email protected]>

Same here:

Reviewed-by: Petr Mladek <[email protected]>

> > I agree with Steven, would be better to move the whole thing
> > to lib/dump_stack.c
>
> If nobody has plan I can put it in my todo list, probably do it next
> week.

Sounds good.

JFYI, I would target these changes for 4.17. There was some discussion
about where and how to show the new information. IMHO, it would deserve
some gurgling in linux-next.

Best Regards,
Petr

2018-01-31 12:42:02

by Simon Horman

[permalink] [raw]
Subject: Re: [PATCH V2] print kdump kernel loaded status in stack dump

On Sat, Jan 27, 2018 at 12:11:29PM +0800, Dave Young wrote:
> It is useful to print kdump kernel loaded status in dump_stack()
> especially when panic happens so that we can differenciate
> kdump kernel early hang and a normal panic in a bug report.
>
> Signed-off-by: Dave Young <[email protected]>

Reviewed-by: Simon Horman <[email protected]>