All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  3:04 ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

Add log level argument to show_stack().
Done in three stages:
1. Introducing show_stack_loglvl() for every architecture
2. Migrating old users with an explicit log level
3. Renaming show_stack_loglvl() into show_stack()

Justification:
o It's a design mistake to move a business-logic decision
  into platform realization detail.
o I have currently two patches sets that would benefit from this work:
  Removing console_loglevel jumps in sysrq driver [1]
  Hung task warning before panic [2] - suggested by Tetsuo (but he
  probably didn't realise what it would involve).
o While doing (1), (2) the backtraces were adjusted to headers
  and other messages for each situation - so there won't be a situation
  when the backtrace is printed, but the headers are missing because
  they have lesser log level (or the reverse).
o As the result in (2) plays with console_loglevel for kdb are removed.

The least important for upstream, but maybe still worth to note that
every company I've worked in so far had an off-list patch to print
backtrace with the needed log level (but only for the architecture they
cared about).
If you have other ideas how you will benefit from show_stack() with
a log level - please, reply to this cover letter.

Ok, to the scary part: I've tested it on x86_64 and build tested on a
couple of architectures. Though, I can't cover all platforms so
I hope I'll have a couple of reports and than it'll soak in linux-next
for some time. In my opinion the variety of architectures shouldn't
stop general improvements.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

Thanks,
Dmitry

[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
[2]: https://lkml.kernel.org/r/41fd7652-df1f-26f6-aba0-b87ebae07db6@i-love.sakura.ne.jp

Dmitry Safonov (50):
  kallsyms/printk: Add loglvl to print_ip_sym()
  alpha: Add show_stack_loglvl()
  arc: Add show_stack_loglvl()
  arm/asm: Add loglvl to c_backtrace()
  arm: Add loglvl to unwind_backtrace()
  arm: Add loglvl to dump_backtrace()
  arm: Wire up dump_backtrace_{entry,stm}
  arm: Add show_stack_loglvl()
  arm64: Add loglvl to dump_backtrace()
  arm64: Add show_stack_loglvl()
  c6x: Add show_stack_loglvl()
  csky: Add show_stack_loglvl()
  h8300: Add show_stack_loglvl()
  hexagon: Add show_stack_loglvl()
  ia64: Pass log level as arg into ia64_do_show_stack()
  ia64: Add show_stack_loglvl()
  m68k: Add show_stack_loglvl()
  microblaze: Add loglvl to microblaze_unwind_inner()
  microblaze: Add loglvl to microblaze_unwind()
  microblaze: Add show_stack_loglvl()
  mips: Add show_stack_loglvl()
  nds32: Add show_stack_loglvl()
  nios2: Add show_stack_loglvl()
  openrisc: Add show_stack_loglvl()
  parisc: Add show_stack_loglvl()
  powerpc: Add show_stack_loglvl()
  riscv: Add show_stack_loglvl()
  s390: Add show_stack_loglvl()
  sh: Add loglvl to dump_mem()
  sh: Remove needless printk()
  sh: Add loglvl to printk_address()
  sh: Add loglvl to show_trace()
  sh: Add show_stack_loglvl()
  sparc: Add show_stack_loglvl()
  um/sysrq: Remove needless variable sp
  um: Add show_stack_loglvl()
  unicore32: Remove unused pmode argument in c_backtrace()
  unicore32: Add loglvl to c_backtrace()
  unicore32: Add show_stack_loglvl()
  x86: Add missing const qualifiers for log_lvl
  x86: Add show_stack_loglvl()
  xtensa: Add loglvl to show_trace()
  xtensa: Add show_stack_loglvl()
  sysrq: Use show_stack_loglvl()
  x86/amd_gart: Print stacktrace for a leak with KERN_ERR
  power: Use show_stack_loglvl()
  kdb: Don't play with console_loglevel
  sched: Print stack trace with KERN_INFO
  kernel: Use show_stack_loglvl()
  kernel: Rename show_stack_loglvl() => show_stack()

 arch/alpha/kernel/traps.c            | 22 +++++++--------
 arch/arc/include/asm/bug.h           |  3 ++-
 arch/arc/kernel/stacktrace.c         | 17 +++++++-----
 arch/arc/kernel/troubleshoot.c       |  2 +-
 arch/arm/include/asm/bug.h           |  3 ++-
 arch/arm/include/asm/traps.h         |  3 ++-
 arch/arm/include/asm/unwind.h        |  3 ++-
 arch/arm/kernel/traps.c              | 40 ++++++++++++++++------------
 arch/arm/kernel/unwind.c             |  7 ++---
 arch/arm/lib/backtrace-clang.S       |  9 +++++--
 arch/arm/lib/backtrace.S             | 14 +++++++---
 arch/arm64/include/asm/stacktrace.h  |  3 ++-
 arch/arm64/kernel/process.c          |  2 +-
 arch/arm64/kernel/traps.c            | 19 ++++++-------
 arch/c6x/kernel/traps.c              | 18 +++++++------
 arch/csky/kernel/dumpstack.c         |  9 ++++---
 arch/csky/kernel/ptrace.c            |  4 +--
 arch/h8300/kernel/traps.c            | 12 ++++-----
 arch/hexagon/kernel/traps.c          | 25 ++++++++---------
 arch/ia64/include/asm/ptrace.h       |  1 -
 arch/ia64/kernel/mca.c               |  2 +-
 arch/ia64/kernel/process.c           | 17 ++++++------
 arch/m68k/kernel/traps.c             | 13 ++++-----
 arch/microblaze/include/asm/unwind.h |  3 ++-
 arch/microblaze/kernel/stacktrace.c  |  4 +--
 arch/microblaze/kernel/traps.c       | 12 ++++-----
 arch/microblaze/kernel/unwind.c      | 37 ++++++++++++++-----------
 arch/mips/kernel/traps.c             | 35 ++++++++++++------------
 arch/nds32/kernel/traps.c            | 15 ++++++-----
 arch/nios2/kernel/traps.c            | 17 ++++++------
 arch/openrisc/kernel/traps.c         | 12 +++++----
 arch/parisc/kernel/traps.c           | 24 ++++++++---------
 arch/powerpc/kernel/process.c        | 15 ++++++-----
 arch/powerpc/kernel/stacktrace.c     |  2 +-
 arch/riscv/kernel/stacktrace.c       |  9 ++++---
 arch/s390/kernel/dumpstack.c         | 11 ++++----
 arch/sh/include/asm/kdebug.h         |  6 +++--
 arch/sh/include/asm/processor_32.h   |  2 +-
 arch/sh/kernel/dumpstack.c           | 36 ++++++++++++-------------
 arch/sh/kernel/process_32.c          |  2 +-
 arch/sh/kernel/process_64.c          |  3 +--
 arch/sh/kernel/traps.c               |  4 +--
 arch/sh/mm/fault.c                   |  2 +-
 arch/sparc/kernel/process_32.c       | 10 +++----
 arch/sparc/kernel/process_64.c       |  2 +-
 arch/um/drivers/mconsole_kern.c      |  2 +-
 arch/um/kernel/sysrq.c               | 23 ++++++++--------
 arch/unicore32/kernel/setup.h        |  2 +-
 arch/unicore32/kernel/traps.c        | 34 +++++++++++------------
 arch/unicore32/lib/backtrace.S       | 24 +++++++++++------
 arch/x86/include/asm/stacktrace.h    |  2 +-
 arch/x86/kernel/amd_gart_64.c        |  2 +-
 arch/x86/kernel/dumpstack.c          |  9 ++++---
 arch/xtensa/kernel/traps.c           | 26 ++++++++++--------
 drivers/base/power/main.c            |  2 +-
 drivers/tty/sysrq.c                  |  2 +-
 include/linux/kallsyms.h             |  4 +--
 include/linux/sched/debug.h          |  3 ++-
 kernel/debug/kdb/kdb_bt.c            | 11 +++-----
 kernel/locking/lockdep.c             |  4 +--
 kernel/locking/rtmutex-debug.c       |  2 +-
 kernel/sched/core.c                  |  6 ++---
 kernel/trace/ftrace.c                |  8 +++---
 lib/dump_stack.c                     |  2 +-
 64 files changed, 368 insertions(+), 311 deletions(-)

-- 
2.23.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  3:04 ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, Ralf Baechle,
	Paul Mackerras, Andrew Morton, linux-ia64, Tetsuo Handa,
	James Hogan, James E.J. Bottomley, Max Filippov, Vincent Chen,
	Ingo Molnar, linux-s390, linux-c6x-dev, Yoshinori Sato,
	linux-hexagon, Helge Deller, linux-xtensa, Vasily Gorbik,
	Aurelien Jacquiot, linux-m68k, Stafford Horne, linux-arm-kernel,
	Chris Zankel, Tony Luck, Douglas Anderson, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

Add log level argument to show_stack().
Done in three stages:
1. Introducing show_stack_loglvl() for every architecture
2. Migrating old users with an explicit log level
3. Renaming show_stack_loglvl() into show_stack()

Justification:
o It's a design mistake to move a business-logic decision
  into platform realization detail.
o I have currently two patches sets that would benefit from this work:
  Removing console_loglevel jumps in sysrq driver [1]
  Hung task warning before panic [2] - suggested by Tetsuo (but he
  probably didn't realise what it would involve).
o While doing (1), (2) the backtraces were adjusted to headers
  and other messages for each situation - so there won't be a situation
  when the backtrace is printed, but the headers are missing because
  they have lesser log level (or the reverse).
o As the result in (2) plays with console_loglevel for kdb are removed.

The least important for upstream, but maybe still worth to note that
every company I've worked in so far had an off-list patch to print
backtrace with the needed log level (but only for the architecture they
cared about).
If you have other ideas how you will benefit from show_stack() with
a log level - please, reply to this cover letter.

Ok, to the scary part: I've tested it on x86_64 and build tested on a
couple of architectures. Though, I can't cover all platforms so
I hope I'll have a couple of reports and than it'll soak in linux-next
for some time. In my opinion the variety of architectures shouldn't
stop general improvements.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

Thanks,
Dmitry

[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
[2]: https://lkml.kernel.org/r/41fd7652-df1f-26f6-aba0-b87ebae07db6@i-love.sakura.ne.jp

Dmitry Safonov (50):
  kallsyms/printk: Add loglvl to print_ip_sym()
  alpha: Add show_stack_loglvl()
  arc: Add show_stack_loglvl()
  arm/asm: Add loglvl to c_backtrace()
  arm: Add loglvl to unwind_backtrace()
  arm: Add loglvl to dump_backtrace()
  arm: Wire up dump_backtrace_{entry,stm}
  arm: Add show_stack_loglvl()
  arm64: Add loglvl to dump_backtrace()
  arm64: Add show_stack_loglvl()
  c6x: Add show_stack_loglvl()
  csky: Add show_stack_loglvl()
  h8300: Add show_stack_loglvl()
  hexagon: Add show_stack_loglvl()
  ia64: Pass log level as arg into ia64_do_show_stack()
  ia64: Add show_stack_loglvl()
  m68k: Add show_stack_loglvl()
  microblaze: Add loglvl to microblaze_unwind_inner()
  microblaze: Add loglvl to microblaze_unwind()
  microblaze: Add show_stack_loglvl()
  mips: Add show_stack_loglvl()
  nds32: Add show_stack_loglvl()
  nios2: Add show_stack_loglvl()
  openrisc: Add show_stack_loglvl()
  parisc: Add show_stack_loglvl()
  powerpc: Add show_stack_loglvl()
  riscv: Add show_stack_loglvl()
  s390: Add show_stack_loglvl()
  sh: Add loglvl to dump_mem()
  sh: Remove needless printk()
  sh: Add loglvl to printk_address()
  sh: Add loglvl to show_trace()
  sh: Add show_stack_loglvl()
  sparc: Add show_stack_loglvl()
  um/sysrq: Remove needless variable sp
  um: Add show_stack_loglvl()
  unicore32: Remove unused pmode argument in c_backtrace()
  unicore32: Add loglvl to c_backtrace()
  unicore32: Add show_stack_loglvl()
  x86: Add missing const qualifiers for log_lvl
  x86: Add show_stack_loglvl()
  xtensa: Add loglvl to show_trace()
  xtensa: Add show_stack_loglvl()
  sysrq: Use show_stack_loglvl()
  x86/amd_gart: Print stacktrace for a leak with KERN_ERR
  power: Use show_stack_loglvl()
  kdb: Don't play with console_loglevel
  sched: Print stack trace with KERN_INFO
  kernel: Use show_stack_loglvl()
  kernel: Rename show_stack_loglvl() => show_stack()

 arch/alpha/kernel/traps.c            | 22 +++++++--------
 arch/arc/include/asm/bug.h           |  3 ++-
 arch/arc/kernel/stacktrace.c         | 17 +++++++-----
 arch/arc/kernel/troubleshoot.c       |  2 +-
 arch/arm/include/asm/bug.h           |  3 ++-
 arch/arm/include/asm/traps.h         |  3 ++-
 arch/arm/include/asm/unwind.h        |  3 ++-
 arch/arm/kernel/traps.c              | 40 ++++++++++++++++------------
 arch/arm/kernel/unwind.c             |  7 ++---
 arch/arm/lib/backtrace-clang.S       |  9 +++++--
 arch/arm/lib/backtrace.S             | 14 +++++++---
 arch/arm64/include/asm/stacktrace.h  |  3 ++-
 arch/arm64/kernel/process.c          |  2 +-
 arch/arm64/kernel/traps.c            | 19 ++++++-------
 arch/c6x/kernel/traps.c              | 18 +++++++------
 arch/csky/kernel/dumpstack.c         |  9 ++++---
 arch/csky/kernel/ptrace.c            |  4 +--
 arch/h8300/kernel/traps.c            | 12 ++++-----
 arch/hexagon/kernel/traps.c          | 25 ++++++++---------
 arch/ia64/include/asm/ptrace.h       |  1 -
 arch/ia64/kernel/mca.c               |  2 +-
 arch/ia64/kernel/process.c           | 17 ++++++------
 arch/m68k/kernel/traps.c             | 13 ++++-----
 arch/microblaze/include/asm/unwind.h |  3 ++-
 arch/microblaze/kernel/stacktrace.c  |  4 +--
 arch/microblaze/kernel/traps.c       | 12 ++++-----
 arch/microblaze/kernel/unwind.c      | 37 ++++++++++++++-----------
 arch/mips/kernel/traps.c             | 35 ++++++++++++------------
 arch/nds32/kernel/traps.c            | 15 ++++++-----
 arch/nios2/kernel/traps.c            | 17 ++++++------
 arch/openrisc/kernel/traps.c         | 12 +++++----
 arch/parisc/kernel/traps.c           | 24 ++++++++---------
 arch/powerpc/kernel/process.c        | 15 ++++++-----
 arch/powerpc/kernel/stacktrace.c     |  2 +-
 arch/riscv/kernel/stacktrace.c       |  9 ++++---
 arch/s390/kernel/dumpstack.c         | 11 ++++----
 arch/sh/include/asm/kdebug.h         |  6 +++--
 arch/sh/include/asm/processor_32.h   |  2 +-
 arch/sh/kernel/dumpstack.c           | 36 ++++++++++++-------------
 arch/sh/kernel/process_32.c          |  2 +-
 arch/sh/kernel/process_64.c          |  3 +--
 arch/sh/kernel/traps.c               |  4 +--
 arch/sh/mm/fault.c                   |  2 +-
 arch/sparc/kernel/process_32.c       | 10 +++----
 arch/sparc/kernel/process_64.c       |  2 +-
 arch/um/drivers/mconsole_kern.c      |  2 +-
 arch/um/kernel/sysrq.c               | 23 ++++++++--------
 arch/unicore32/kernel/setup.h        |  2 +-
 arch/unicore32/kernel/traps.c        | 34 +++++++++++------------
 arch/unicore32/lib/backtrace.S       | 24 +++++++++++------
 arch/x86/include/asm/stacktrace.h    |  2 +-
 arch/x86/kernel/amd_gart_64.c        |  2 +-
 arch/x86/kernel/dumpstack.c          |  9 ++++---
 arch/xtensa/kernel/traps.c           | 26 ++++++++++--------
 drivers/base/power/main.c            |  2 +-
 drivers/tty/sysrq.c                  |  2 +-
 include/linux/kallsyms.h             |  4 +--
 include/linux/sched/debug.h          |  3 ++-
 kernel/debug/kdb/kdb_bt.c            | 11 +++-----
 kernel/locking/lockdep.c             |  4 +--
 kernel/locking/rtmutex-debug.c       |  2 +-
 kernel/sched/core.c                  |  6 ++---
 kernel/trace/ftrace.c                |  8 +++---
 lib/dump_stack.c                     |  2 +-
 64 files changed, 368 insertions(+), 311 deletions(-)

-- 
2.23.0


^ permalink raw reply	[flat|nested] 323+ messages in thread

* [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  3:04 ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

Add log level argument to show_stack().
Done in three stages:
1. Introducing show_stack_loglvl() for every architecture
2. Migrating old users with an explicit log level
3. Renaming show_stack_loglvl() into show_stack()

Justification:
o It's a design mistake to move a business-logic decision
  into platform realization detail.
o I have currently two patches sets that would benefit from this work:
  Removing console_loglevel jumps in sysrq driver [1]
  Hung task warning before panic [2] - suggested by Tetsuo (but he
  probably didn't realise what it would involve).
o While doing (1), (2) the backtraces were adjusted to headers
  and other messages for each situation - so there won't be a situation
  when the backtrace is printed, but the headers are missing because
  they have lesser log level (or the reverse).
o As the result in (2) plays with console_loglevel for kdb are removed.

The least important for upstream, but maybe still worth to note that
every company I've worked in so far had an off-list patch to print
backtrace with the needed log level (but only for the architecture they
cared about).
If you have other ideas how you will benefit from show_stack() with
a log level - please, reply to this cover letter.

Ok, to the scary part: I've tested it on x86_64 and build tested on a
couple of architectures. Though, I can't cover all platforms so
I hope I'll have a couple of reports and than it'll soak in linux-next
for some time. In my opinion the variety of architectures shouldn't
stop general improvements.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

Thanks,
Dmitry

[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
[2]: https://lkml.kernel.org/r/41fd7652-df1f-26f6-aba0-b87ebae07db6@i-love.sakura.ne.jp

Dmitry Safonov (50):
  kallsyms/printk: Add loglvl to print_ip_sym()
  alpha: Add show_stack_loglvl()
  arc: Add show_stack_loglvl()
  arm/asm: Add loglvl to c_backtrace()
  arm: Add loglvl to unwind_backtrace()
  arm: Add loglvl to dump_backtrace()
  arm: Wire up dump_backtrace_{entry,stm}
  arm: Add show_stack_loglvl()
  arm64: Add loglvl to dump_backtrace()
  arm64: Add show_stack_loglvl()
  c6x: Add show_stack_loglvl()
  csky: Add show_stack_loglvl()
  h8300: Add show_stack_loglvl()
  hexagon: Add show_stack_loglvl()
  ia64: Pass log level as arg into ia64_do_show_stack()
  ia64: Add show_stack_loglvl()
  m68k: Add show_stack_loglvl()
  microblaze: Add loglvl to microblaze_unwind_inner()
  microblaze: Add loglvl to microblaze_unwind()
  microblaze: Add show_stack_loglvl()
  mips: Add show_stack_loglvl()
  nds32: Add show_stack_loglvl()
  nios2: Add show_stack_loglvl()
  openrisc: Add show_stack_loglvl()
  parisc: Add show_stack_loglvl()
  powerpc: Add show_stack_loglvl()
  riscv: Add show_stack_loglvl()
  s390: Add show_stack_loglvl()
  sh: Add loglvl to dump_mem()
  sh: Remove needless printk()
  sh: Add loglvl to printk_address()
  sh: Add loglvl to show_trace()
  sh: Add show_stack_loglvl()
  sparc: Add show_stack_loglvl()
  um/sysrq: Remove needless variable sp
  um: Add show_stack_loglvl()
  unicore32: Remove unused pmode argument in c_backtrace()
  unicore32: Add loglvl to c_backtrace()
  unicore32: Add show_stack_loglvl()
  x86: Add missing const qualifiers for log_lvl
  x86: Add show_stack_loglvl()
  xtensa: Add loglvl to show_trace()
  xtensa: Add show_stack_loglvl()
  sysrq: Use show_stack_loglvl()
  x86/amd_gart: Print stacktrace for a leak with KERN_ERR
  power: Use show_stack_loglvl()
  kdb: Don't play with console_loglevel
  sched: Print stack trace with KERN_INFO
  kernel: Use show_stack_loglvl()
  kernel: Rename show_stack_loglvl() => show_stack()

 arch/alpha/kernel/traps.c            | 22 +++++++--------
 arch/arc/include/asm/bug.h           |  3 ++-
 arch/arc/kernel/stacktrace.c         | 17 +++++++-----
 arch/arc/kernel/troubleshoot.c       |  2 +-
 arch/arm/include/asm/bug.h           |  3 ++-
 arch/arm/include/asm/traps.h         |  3 ++-
 arch/arm/include/asm/unwind.h        |  3 ++-
 arch/arm/kernel/traps.c              | 40 ++++++++++++++++------------
 arch/arm/kernel/unwind.c             |  7 ++---
 arch/arm/lib/backtrace-clang.S       |  9 +++++--
 arch/arm/lib/backtrace.S             | 14 +++++++---
 arch/arm64/include/asm/stacktrace.h  |  3 ++-
 arch/arm64/kernel/process.c          |  2 +-
 arch/arm64/kernel/traps.c            | 19 ++++++-------
 arch/c6x/kernel/traps.c              | 18 +++++++------
 arch/csky/kernel/dumpstack.c         |  9 ++++---
 arch/csky/kernel/ptrace.c            |  4 +--
 arch/h8300/kernel/traps.c            | 12 ++++-----
 arch/hexagon/kernel/traps.c          | 25 ++++++++---------
 arch/ia64/include/asm/ptrace.h       |  1 -
 arch/ia64/kernel/mca.c               |  2 +-
 arch/ia64/kernel/process.c           | 17 ++++++------
 arch/m68k/kernel/traps.c             | 13 ++++-----
 arch/microblaze/include/asm/unwind.h |  3 ++-
 arch/microblaze/kernel/stacktrace.c  |  4 +--
 arch/microblaze/kernel/traps.c       | 12 ++++-----
 arch/microblaze/kernel/unwind.c      | 37 ++++++++++++++-----------
 arch/mips/kernel/traps.c             | 35 ++++++++++++------------
 arch/nds32/kernel/traps.c            | 15 ++++++-----
 arch/nios2/kernel/traps.c            | 17 ++++++------
 arch/openrisc/kernel/traps.c         | 12 +++++----
 arch/parisc/kernel/traps.c           | 24 ++++++++---------
 arch/powerpc/kernel/process.c        | 15 ++++++-----
 arch/powerpc/kernel/stacktrace.c     |  2 +-
 arch/riscv/kernel/stacktrace.c       |  9 ++++---
 arch/s390/kernel/dumpstack.c         | 11 ++++----
 arch/sh/include/asm/kdebug.h         |  6 +++--
 arch/sh/include/asm/processor_32.h   |  2 +-
 arch/sh/kernel/dumpstack.c           | 36 ++++++++++++-------------
 arch/sh/kernel/process_32.c          |  2 +-
 arch/sh/kernel/process_64.c          |  3 +--
 arch/sh/kernel/traps.c               |  4 +--
 arch/sh/mm/fault.c                   |  2 +-
 arch/sparc/kernel/process_32.c       | 10 +++----
 arch/sparc/kernel/process_64.c       |  2 +-
 arch/um/drivers/mconsole_kern.c      |  2 +-
 arch/um/kernel/sysrq.c               | 23 ++++++++--------
 arch/unicore32/kernel/setup.h        |  2 +-
 arch/unicore32/kernel/traps.c        | 34 +++++++++++------------
 arch/unicore32/lib/backtrace.S       | 24 +++++++++++------
 arch/x86/include/asm/stacktrace.h    |  2 +-
 arch/x86/kernel/amd_gart_64.c        |  2 +-
 arch/x86/kernel/dumpstack.c          |  9 ++++---
 arch/xtensa/kernel/traps.c           | 26 ++++++++++--------
 drivers/base/power/main.c            |  2 +-
 drivers/tty/sysrq.c                  |  2 +-
 include/linux/kallsyms.h             |  4 +--
 include/linux/sched/debug.h          |  3 ++-
 kernel/debug/kdb/kdb_bt.c            | 11 +++-----
 kernel/locking/lockdep.c             |  4 +--
 kernel/locking/rtmutex-debug.c       |  2 +-
 kernel/sched/core.c                  |  6 ++---
 kernel/trace/ftrace.c                |  8 +++---
 lib/dump_stack.c                     |  2 +-
 64 files changed, 368 insertions(+), 311 deletions(-)

-- 
2.23.0


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  3:04 ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: openrisc

Add log level argument to show_stack().
Done in three stages:
1. Introducing show_stack_loglvl() for every architecture
2. Migrating old users with an explicit log level
3. Renaming show_stack_loglvl() into show_stack()

Justification:
o It's a design mistake to move a business-logic decision
  into platform realization detail.
o I have currently two patches sets that would benefit from this work:
  Removing console_loglevel jumps in sysrq driver [1]
  Hung task warning before panic [2] - suggested by Tetsuo (but he
  probably didn't realise what it would involve).
o While doing (1), (2) the backtraces were adjusted to headers
  and other messages for each situation - so there won't be a situation
  when the backtrace is printed, but the headers are missing because
  they have lesser log level (or the reverse).
o As the result in (2) plays with console_loglevel for kdb are removed.

The least important for upstream, but maybe still worth to note that
every company I've worked in so far had an off-list patch to print
backtrace with the needed log level (but only for the architecture they
cared about).
If you have other ideas how you will benefit from show_stack() with
a log level - please, reply to this cover letter.

Ok, to the scary part: I've tested it on x86_64 and build tested on a
couple of architectures. Though, I can't cover all platforms so
I hope I'll have a couple of reports and than it'll soak in linux-next
for some time. In my opinion the variety of architectures shouldn't
stop general improvements.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

Thanks,
Dmitry

[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima at arista.com/T/#u
[2]: https://lkml.kernel.org/r/41fd7652-df1f-26f6-aba0-b87ebae07db6 at i-love.sakura.ne.jp

Dmitry Safonov (50):
  kallsyms/printk: Add loglvl to print_ip_sym()
  alpha: Add show_stack_loglvl()
  arc: Add show_stack_loglvl()
  arm/asm: Add loglvl to c_backtrace()
  arm: Add loglvl to unwind_backtrace()
  arm: Add loglvl to dump_backtrace()
  arm: Wire up dump_backtrace_{entry,stm}
  arm: Add show_stack_loglvl()
  arm64: Add loglvl to dump_backtrace()
  arm64: Add show_stack_loglvl()
  c6x: Add show_stack_loglvl()
  csky: Add show_stack_loglvl()
  h8300: Add show_stack_loglvl()
  hexagon: Add show_stack_loglvl()
  ia64: Pass log level as arg into ia64_do_show_stack()
  ia64: Add show_stack_loglvl()
  m68k: Add show_stack_loglvl()
  microblaze: Add loglvl to microblaze_unwind_inner()
  microblaze: Add loglvl to microblaze_unwind()
  microblaze: Add show_stack_loglvl()
  mips: Add show_stack_loglvl()
  nds32: Add show_stack_loglvl()
  nios2: Add show_stack_loglvl()
  openrisc: Add show_stack_loglvl()
  parisc: Add show_stack_loglvl()
  powerpc: Add show_stack_loglvl()
  riscv: Add show_stack_loglvl()
  s390: Add show_stack_loglvl()
  sh: Add loglvl to dump_mem()
  sh: Remove needless printk()
  sh: Add loglvl to printk_address()
  sh: Add loglvl to show_trace()
  sh: Add show_stack_loglvl()
  sparc: Add show_stack_loglvl()
  um/sysrq: Remove needless variable sp
  um: Add show_stack_loglvl()
  unicore32: Remove unused pmode argument in c_backtrace()
  unicore32: Add loglvl to c_backtrace()
  unicore32: Add show_stack_loglvl()
  x86: Add missing const qualifiers for log_lvl
  x86: Add show_stack_loglvl()
  xtensa: Add loglvl to show_trace()
  xtensa: Add show_stack_loglvl()
  sysrq: Use show_stack_loglvl()
  x86/amd_gart: Print stacktrace for a leak with KERN_ERR
  power: Use show_stack_loglvl()
  kdb: Don't play with console_loglevel
  sched: Print stack trace with KERN_INFO
  kernel: Use show_stack_loglvl()
  kernel: Rename show_stack_loglvl() => show_stack()

 arch/alpha/kernel/traps.c            | 22 +++++++--------
 arch/arc/include/asm/bug.h           |  3 ++-
 arch/arc/kernel/stacktrace.c         | 17 +++++++-----
 arch/arc/kernel/troubleshoot.c       |  2 +-
 arch/arm/include/asm/bug.h           |  3 ++-
 arch/arm/include/asm/traps.h         |  3 ++-
 arch/arm/include/asm/unwind.h        |  3 ++-
 arch/arm/kernel/traps.c              | 40 ++++++++++++++++------------
 arch/arm/kernel/unwind.c             |  7 ++---
 arch/arm/lib/backtrace-clang.S       |  9 +++++--
 arch/arm/lib/backtrace.S             | 14 +++++++---
 arch/arm64/include/asm/stacktrace.h  |  3 ++-
 arch/arm64/kernel/process.c          |  2 +-
 arch/arm64/kernel/traps.c            | 19 ++++++-------
 arch/c6x/kernel/traps.c              | 18 +++++++------
 arch/csky/kernel/dumpstack.c         |  9 ++++---
 arch/csky/kernel/ptrace.c            |  4 +--
 arch/h8300/kernel/traps.c            | 12 ++++-----
 arch/hexagon/kernel/traps.c          | 25 ++++++++---------
 arch/ia64/include/asm/ptrace.h       |  1 -
 arch/ia64/kernel/mca.c               |  2 +-
 arch/ia64/kernel/process.c           | 17 ++++++------
 arch/m68k/kernel/traps.c             | 13 ++++-----
 arch/microblaze/include/asm/unwind.h |  3 ++-
 arch/microblaze/kernel/stacktrace.c  |  4 +--
 arch/microblaze/kernel/traps.c       | 12 ++++-----
 arch/microblaze/kernel/unwind.c      | 37 ++++++++++++++-----------
 arch/mips/kernel/traps.c             | 35 ++++++++++++------------
 arch/nds32/kernel/traps.c            | 15 ++++++-----
 arch/nios2/kernel/traps.c            | 17 ++++++------
 arch/openrisc/kernel/traps.c         | 12 +++++----
 arch/parisc/kernel/traps.c           | 24 ++++++++---------
 arch/powerpc/kernel/process.c        | 15 ++++++-----
 arch/powerpc/kernel/stacktrace.c     |  2 +-
 arch/riscv/kernel/stacktrace.c       |  9 ++++---
 arch/s390/kernel/dumpstack.c         | 11 ++++----
 arch/sh/include/asm/kdebug.h         |  6 +++--
 arch/sh/include/asm/processor_32.h   |  2 +-
 arch/sh/kernel/dumpstack.c           | 36 ++++++++++++-------------
 arch/sh/kernel/process_32.c          |  2 +-
 arch/sh/kernel/process_64.c          |  3 +--
 arch/sh/kernel/traps.c               |  4 +--
 arch/sh/mm/fault.c                   |  2 +-
 arch/sparc/kernel/process_32.c       | 10 +++----
 arch/sparc/kernel/process_64.c       |  2 +-
 arch/um/drivers/mconsole_kern.c      |  2 +-
 arch/um/kernel/sysrq.c               | 23 ++++++++--------
 arch/unicore32/kernel/setup.h        |  2 +-
 arch/unicore32/kernel/traps.c        | 34 +++++++++++------------
 arch/unicore32/lib/backtrace.S       | 24 +++++++++++------
 arch/x86/include/asm/stacktrace.h    |  2 +-
 arch/x86/kernel/amd_gart_64.c        |  2 +-
 arch/x86/kernel/dumpstack.c          |  9 ++++---
 arch/xtensa/kernel/traps.c           | 26 ++++++++++--------
 drivers/base/power/main.c            |  2 +-
 drivers/tty/sysrq.c                  |  2 +-
 include/linux/kallsyms.h             |  4 +--
 include/linux/sched/debug.h          |  3 ++-
 kernel/debug/kdb/kdb_bt.c            | 11 +++-----
 kernel/locking/lockdep.c             |  4 +--
 kernel/locking/rtmutex-debug.c       |  2 +-
 kernel/sched/core.c                  |  6 ++---
 kernel/trace/ftrace.c                |  8 +++---
 lib/dump_stack.c                     |  2 +-
 64 files changed, 368 insertions(+), 311 deletions(-)

-- 
2.23.0


^ permalink raw reply	[flat|nested] 323+ messages in thread

* [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  3:04 ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

Add log level argument to show_stack().
Done in three stages:
1. Introducing show_stack_loglvl() for every architecture
2. Migrating old users with an explicit log level
3. Renaming show_stack_loglvl() into show_stack()

Justification:
o It's a design mistake to move a business-logic decision
  into platform realization detail.
o I have currently two patches sets that would benefit from this work:
  Removing console_loglevel jumps in sysrq driver [1]
  Hung task warning before panic [2] - suggested by Tetsuo (but he
  probably didn't realise what it would involve).
o While doing (1), (2) the backtraces were adjusted to headers
  and other messages for each situation - so there won't be a situation
  when the backtrace is printed, but the headers are missing because
  they have lesser log level (or the reverse).
o As the result in (2) plays with console_loglevel for kdb are removed.

The least important for upstream, but maybe still worth to note that
every company I've worked in so far had an off-list patch to print
backtrace with the needed log level (but only for the architecture they
cared about).
If you have other ideas how you will benefit from show_stack() with
a log level - please, reply to this cover letter.

Ok, to the scary part: I've tested it on x86_64 and build tested on a
couple of architectures. Though, I can't cover all platforms so
I hope I'll have a couple of reports and than it'll soak in linux-next
for some time. In my opinion the variety of architectures shouldn't
stop general improvements.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

Thanks,
Dmitry

[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
[2]: https://lkml.kernel.org/r/41fd7652-df1f-26f6-aba0-b87ebae07db6@i-love.sakura.ne.jp

Dmitry Safonov (50):
  kallsyms/printk: Add loglvl to print_ip_sym()
  alpha: Add show_stack_loglvl()
  arc: Add show_stack_loglvl()
  arm/asm: Add loglvl to c_backtrace()
  arm: Add loglvl to unwind_backtrace()
  arm: Add loglvl to dump_backtrace()
  arm: Wire up dump_backtrace_{entry,stm}
  arm: Add show_stack_loglvl()
  arm64: Add loglvl to dump_backtrace()
  arm64: Add show_stack_loglvl()
  c6x: Add show_stack_loglvl()
  csky: Add show_stack_loglvl()
  h8300: Add show_stack_loglvl()
  hexagon: Add show_stack_loglvl()
  ia64: Pass log level as arg into ia64_do_show_stack()
  ia64: Add show_stack_loglvl()
  m68k: Add show_stack_loglvl()
  microblaze: Add loglvl to microblaze_unwind_inner()
  microblaze: Add loglvl to microblaze_unwind()
  microblaze: Add show_stack_loglvl()
  mips: Add show_stack_loglvl()
  nds32: Add show_stack_loglvl()
  nios2: Add show_stack_loglvl()
  openrisc: Add show_stack_loglvl()
  parisc: Add show_stack_loglvl()
  powerpc: Add show_stack_loglvl()
  riscv: Add show_stack_loglvl()
  s390: Add show_stack_loglvl()
  sh: Add loglvl to dump_mem()
  sh: Remove needless printk()
  sh: Add loglvl to printk_address()
  sh: Add loglvl to show_trace()
  sh: Add show_stack_loglvl()
  sparc: Add show_stack_loglvl()
  um/sysrq: Remove needless variable sp
  um: Add show_stack_loglvl()
  unicore32: Remove unused pmode argument in c_backtrace()
  unicore32: Add loglvl to c_backtrace()
  unicore32: Add show_stack_loglvl()
  x86: Add missing const qualifiers for log_lvl
  x86: Add show_stack_loglvl()
  xtensa: Add loglvl to show_trace()
  xtensa: Add show_stack_loglvl()
  sysrq: Use show_stack_loglvl()
  x86/amd_gart: Print stacktrace for a leak with KERN_ERR
  power: Use show_stack_loglvl()
  kdb: Don't play with console_loglevel
  sched: Print stack trace with KERN_INFO
  kernel: Use show_stack_loglvl()
  kernel: Rename show_stack_loglvl() => show_stack()

 arch/alpha/kernel/traps.c            | 22 +++++++--------
 arch/arc/include/asm/bug.h           |  3 ++-
 arch/arc/kernel/stacktrace.c         | 17 +++++++-----
 arch/arc/kernel/troubleshoot.c       |  2 +-
 arch/arm/include/asm/bug.h           |  3 ++-
 arch/arm/include/asm/traps.h         |  3 ++-
 arch/arm/include/asm/unwind.h        |  3 ++-
 arch/arm/kernel/traps.c              | 40 ++++++++++++++++------------
 arch/arm/kernel/unwind.c             |  7 ++---
 arch/arm/lib/backtrace-clang.S       |  9 +++++--
 arch/arm/lib/backtrace.S             | 14 +++++++---
 arch/arm64/include/asm/stacktrace.h  |  3 ++-
 arch/arm64/kernel/process.c          |  2 +-
 arch/arm64/kernel/traps.c            | 19 ++++++-------
 arch/c6x/kernel/traps.c              | 18 +++++++------
 arch/csky/kernel/dumpstack.c         |  9 ++++---
 arch/csky/kernel/ptrace.c            |  4 +--
 arch/h8300/kernel/traps.c            | 12 ++++-----
 arch/hexagon/kernel/traps.c          | 25 ++++++++---------
 arch/ia64/include/asm/ptrace.h       |  1 -
 arch/ia64/kernel/mca.c               |  2 +-
 arch/ia64/kernel/process.c           | 17 ++++++------
 arch/m68k/kernel/traps.c             | 13 ++++-----
 arch/microblaze/include/asm/unwind.h |  3 ++-
 arch/microblaze/kernel/stacktrace.c  |  4 +--
 arch/microblaze/kernel/traps.c       | 12 ++++-----
 arch/microblaze/kernel/unwind.c      | 37 ++++++++++++++-----------
 arch/mips/kernel/traps.c             | 35 ++++++++++++------------
 arch/nds32/kernel/traps.c            | 15 ++++++-----
 arch/nios2/kernel/traps.c            | 17 ++++++------
 arch/openrisc/kernel/traps.c         | 12 +++++----
 arch/parisc/kernel/traps.c           | 24 ++++++++---------
 arch/powerpc/kernel/process.c        | 15 ++++++-----
 arch/powerpc/kernel/stacktrace.c     |  2 +-
 arch/riscv/kernel/stacktrace.c       |  9 ++++---
 arch/s390/kernel/dumpstack.c         | 11 ++++----
 arch/sh/include/asm/kdebug.h         |  6 +++--
 arch/sh/include/asm/processor_32.h   |  2 +-
 arch/sh/kernel/dumpstack.c           | 36 ++++++++++++-------------
 arch/sh/kernel/process_32.c          |  2 +-
 arch/sh/kernel/process_64.c          |  3 +--
 arch/sh/kernel/traps.c               |  4 +--
 arch/sh/mm/fault.c                   |  2 +-
 arch/sparc/kernel/process_32.c       | 10 +++----
 arch/sparc/kernel/process_64.c       |  2 +-
 arch/um/drivers/mconsole_kern.c      |  2 +-
 arch/um/kernel/sysrq.c               | 23 ++++++++--------
 arch/unicore32/kernel/setup.h        |  2 +-
 arch/unicore32/kernel/traps.c        | 34 +++++++++++------------
 arch/unicore32/lib/backtrace.S       | 24 +++++++++++------
 arch/x86/include/asm/stacktrace.h    |  2 +-
 arch/x86/kernel/amd_gart_64.c        |  2 +-
 arch/x86/kernel/dumpstack.c          |  9 ++++---
 arch/xtensa/kernel/traps.c           | 26 ++++++++++--------
 drivers/base/power/main.c            |  2 +-
 drivers/tty/sysrq.c                  |  2 +-
 include/linux/kallsyms.h             |  4 +--
 include/linux/sched/debug.h          |  3 ++-
 kernel/debug/kdb/kdb_bt.c            | 11 +++-----
 kernel/locking/lockdep.c             |  4 +--
 kernel/locking/rtmutex-debug.c       |  2 +-
 kernel/sched/core.c                  |  6 ++---
 kernel/trace/ftrace.c                |  8 +++---
 lib/dump_stack.c                     |  2 +-
 64 files changed, 368 insertions(+), 311 deletions(-)

-- 
2.23.0



^ permalink raw reply	[flat|nested] 323+ messages in thread

* [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  3:04 ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki, Ralf

Add log level argument to show_stack().
Done in three stages:
1. Introducing show_stack_loglvl() for every architecture
2. Migrating old users with an explicit log level
3. Renaming show_stack_loglvl() into show_stack()

Justification:
o It's a design mistake to move a business-logic decision
  into platform realization detail.
o I have currently two patches sets that would benefit from this work:
  Removing console_loglevel jumps in sysrq driver [1]
  Hung task warning before panic [2] - suggested by Tetsuo (but he
  probably didn't realise what it would involve).
o While doing (1), (2) the backtraces were adjusted to headers
  and other messages for each situation - so there won't be a situation
  when the backtrace is printed, but the headers are missing because
  they have lesser log level (or the reverse).
o As the result in (2) plays with console_loglevel for kdb are removed.

The least important for upstream, but maybe still worth to note that
every company I've worked in so far had an off-list patch to print
backtrace with the needed log level (but only for the architecture they
cared about).
If you have other ideas how you will benefit from show_stack() with
a log level - please, reply to this cover letter.

Ok, to the scary part: I've tested it on x86_64 and build tested on a
couple of architectures. Though, I can't cover all platforms so
I hope I'll have a couple of reports and than it'll soak in linux-next
for some time. In my opinion the variety of architectures shouldn't
stop general improvements.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

Thanks,
Dmitry

[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
[2]: https://lkml.kernel.org/r/41fd7652-df1f-26f6-aba0-b87ebae07db6@i-love.sakura.ne.jp

Dmitry Safonov (50):
  kallsyms/printk: Add loglvl to print_ip_sym()
  alpha: Add show_stack_loglvl()
  arc: Add show_stack_loglvl()
  arm/asm: Add loglvl to c_backtrace()
  arm: Add loglvl to unwind_backtrace()
  arm: Add loglvl to dump_backtrace()
  arm: Wire up dump_backtrace_{entry,stm}
  arm: Add show_stack_loglvl()
  arm64: Add loglvl to dump_backtrace()
  arm64: Add show_stack_loglvl()
  c6x: Add show_stack_loglvl()
  csky: Add show_stack_loglvl()
  h8300: Add show_stack_loglvl()
  hexagon: Add show_stack_loglvl()
  ia64: Pass log level as arg into ia64_do_show_stack()
  ia64: Add show_stack_loglvl()
  m68k: Add show_stack_loglvl()
  microblaze: Add loglvl to microblaze_unwind_inner()
  microblaze: Add loglvl to microblaze_unwind()
  microblaze: Add show_stack_loglvl()
  mips: Add show_stack_loglvl()
  nds32: Add show_stack_loglvl()
  nios2: Add show_stack_loglvl()
  openrisc: Add show_stack_loglvl()
  parisc: Add show_stack_loglvl()
  powerpc: Add show_stack_loglvl()
  riscv: Add show_stack_loglvl()
  s390: Add show_stack_loglvl()
  sh: Add loglvl to dump_mem()
  sh: Remove needless printk()
  sh: Add loglvl to printk_address()
  sh: Add loglvl to show_trace()
  sh: Add show_stack_loglvl()
  sparc: Add show_stack_loglvl()
  um/sysrq: Remove needless variable sp
  um: Add show_stack_loglvl()
  unicore32: Remove unused pmode argument in c_backtrace()
  unicore32: Add loglvl to c_backtrace()
  unicore32: Add show_stack_loglvl()
  x86: Add missing const qualifiers for log_lvl
  x86: Add show_stack_loglvl()
  xtensa: Add loglvl to show_trace()
  xtensa: Add show_stack_loglvl()
  sysrq: Use show_stack_loglvl()
  x86/amd_gart: Print stacktrace for a leak with KERN_ERR
  power: Use show_stack_loglvl()
  kdb: Don't play with console_loglevel
  sched: Print stack trace with KERN_INFO
  kernel: Use show_stack_loglvl()
  kernel: Rename show_stack_loglvl() => show_stack()

 arch/alpha/kernel/traps.c            | 22 +++++++--------
 arch/arc/include/asm/bug.h           |  3 ++-
 arch/arc/kernel/stacktrace.c         | 17 +++++++-----
 arch/arc/kernel/troubleshoot.c       |  2 +-
 arch/arm/include/asm/bug.h           |  3 ++-
 arch/arm/include/asm/traps.h         |  3 ++-
 arch/arm/include/asm/unwind.h        |  3 ++-
 arch/arm/kernel/traps.c              | 40 ++++++++++++++++------------
 arch/arm/kernel/unwind.c             |  7 ++---
 arch/arm/lib/backtrace-clang.S       |  9 +++++--
 arch/arm/lib/backtrace.S             | 14 +++++++---
 arch/arm64/include/asm/stacktrace.h  |  3 ++-
 arch/arm64/kernel/process.c          |  2 +-
 arch/arm64/kernel/traps.c            | 19 ++++++-------
 arch/c6x/kernel/traps.c              | 18 +++++++------
 arch/csky/kernel/dumpstack.c         |  9 ++++---
 arch/csky/kernel/ptrace.c            |  4 +--
 arch/h8300/kernel/traps.c            | 12 ++++-----
 arch/hexagon/kernel/traps.c          | 25 ++++++++---------
 arch/ia64/include/asm/ptrace.h       |  1 -
 arch/ia64/kernel/mca.c               |  2 +-
 arch/ia64/kernel/process.c           | 17 ++++++------
 arch/m68k/kernel/traps.c             | 13 ++++-----
 arch/microblaze/include/asm/unwind.h |  3 ++-
 arch/microblaze/kernel/stacktrace.c  |  4 +--
 arch/microblaze/kernel/traps.c       | 12 ++++-----
 arch/microblaze/kernel/unwind.c      | 37 ++++++++++++++-----------
 arch/mips/kernel/traps.c             | 35 ++++++++++++------------
 arch/nds32/kernel/traps.c            | 15 ++++++-----
 arch/nios2/kernel/traps.c            | 17 ++++++------
 arch/openrisc/kernel/traps.c         | 12 +++++----
 arch/parisc/kernel/traps.c           | 24 ++++++++---------
 arch/powerpc/kernel/process.c        | 15 ++++++-----
 arch/powerpc/kernel/stacktrace.c     |  2 +-
 arch/riscv/kernel/stacktrace.c       |  9 ++++---
 arch/s390/kernel/dumpstack.c         | 11 ++++----
 arch/sh/include/asm/kdebug.h         |  6 +++--
 arch/sh/include/asm/processor_32.h   |  2 +-
 arch/sh/kernel/dumpstack.c           | 36 ++++++++++++-------------
 arch/sh/kernel/process_32.c          |  2 +-
 arch/sh/kernel/process_64.c          |  3 +--
 arch/sh/kernel/traps.c               |  4 +--
 arch/sh/mm/fault.c                   |  2 +-
 arch/sparc/kernel/process_32.c       | 10 +++----
 arch/sparc/kernel/process_64.c       |  2 +-
 arch/um/drivers/mconsole_kern.c      |  2 +-
 arch/um/kernel/sysrq.c               | 23 ++++++++--------
 arch/unicore32/kernel/setup.h        |  2 +-
 arch/unicore32/kernel/traps.c        | 34 +++++++++++------------
 arch/unicore32/lib/backtrace.S       | 24 +++++++++++------
 arch/x86/include/asm/stacktrace.h    |  2 +-
 arch/x86/kernel/amd_gart_64.c        |  2 +-
 arch/x86/kernel/dumpstack.c          |  9 ++++---
 arch/xtensa/kernel/traps.c           | 26 ++++++++++--------
 drivers/base/power/main.c            |  2 +-
 drivers/tty/sysrq.c                  |  2 +-
 include/linux/kallsyms.h             |  4 +--
 include/linux/sched/debug.h          |  3 ++-
 kernel/debug/kdb/kdb_bt.c            | 11 +++-----
 kernel/locking/lockdep.c             |  4 +--
 kernel/locking/rtmutex-debug.c       |  2 +-
 kernel/sched/core.c                  |  6 ++---
 kernel/trace/ftrace.c                |  8 +++---
 lib/dump_stack.c                     |  2 +-
 64 files changed, 368 insertions(+), 311 deletions(-)

-- 
2.23.0

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [PATCH 01/50] kallsyms/printk: Add loglvl to print_ip_sym()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:04   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv

print_ip_sym() needs to have a log level parameter to comply with other
parts being printed. Otherwise, half of the expected backtrace would be
printed and other may be missing with some logging level.

The following callee(s) are using now the adjusted log level:
- microblaze/unwind: the same level as headers & userspace unwind.
  Note that pr_debug()'s there are for debugging the unwinder itself.
- nds32/traps: symbol addresses are printed with the same log level
  as backtrace headers.
- lockdep: ip for locking issues is printed with the same log level
  as other part of the warning.
- sched: ip where preemption was disabled is printed as error like
  the rest part of the message.
- ftrace: bug reports are now consistent in the log level being used.

Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Ben Segall <bsegall@google.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Will Deacon <will@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/microblaze/kernel/unwind.c | 2 +-
 arch/mips/kernel/traps.c        | 4 ++--
 arch/nds32/kernel/traps.c       | 4 ++--
 arch/riscv/kernel/stacktrace.c  | 2 +-
 include/linux/kallsyms.h        | 4 ++--
 kernel/locking/lockdep.c        | 4 ++--
 kernel/sched/core.c             | 4 ++--
 kernel/trace/ftrace.c           | 8 ++++----
 8 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/microblaze/kernel/unwind.c b/arch/microblaze/kernel/unwind.c
index 34c270cb11fc..4241cdd28ee7 100644
--- a/arch/microblaze/kernel/unwind.c
+++ b/arch/microblaze/kernel/unwind.c
@@ -254,7 +254,7 @@ static void microblaze_unwind_inner(struct task_struct *task,
 					task->comm);
 				break;
 			} else
-				print_ip_sym(pc);
+				print_ip_sym(KERN_INFO, pc);
 		}
 
 		/* Stop when we reach anything not part of the kernel */
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 342e41de9d64..861e79868055 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -123,7 +123,7 @@ static void show_raw_backtrace(unsigned long reg29)
 			break;
 		}
 		if (__kernel_text_address(addr))
-			print_ip_sym(addr);
+			print_ip_sym(KERN_DEFAULT, addr);
 	}
 	printk("\n");
 }
@@ -153,7 +153,7 @@ static void show_backtrace(struct task_struct *task, const struct pt_regs *regs)
 	}
 	printk("Call Trace:\n");
 	do {
-		print_ip_sym(pc);
+		print_ip_sym(KERN_DEFAULT, pc);
 		pc = unwind_stack(task, &sp, pc, &ra);
 	} while (pc);
 	pr_cont("\n");
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index f4d386b52622..40625760a125 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -108,7 +108,7 @@ static void __dump(struct task_struct *tsk, unsigned long *base_reg)
 			if (__kernel_text_address(ret_addr)) {
 				ret_addr = ftrace_graph_ret_addr(
 						tsk, &graph, ret_addr, NULL);
-				print_ip_sym(ret_addr);
+				print_ip_sym(KERN_EMERG, ret_addr);
 			}
 			if (--cnt < 0)
 				break;
@@ -124,7 +124,7 @@ static void __dump(struct task_struct *tsk, unsigned long *base_reg)
 
 				ret_addr = ftrace_graph_ret_addr(
 						tsk, &graph, ret_addr, NULL);
-				print_ip_sym(ret_addr);
+				print_ip_sym(KERN_EMERG, ret_addr);
 			}
 			if (--cnt < 0)
 				break;
diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 0940681d2f68..a76892b48fff 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -98,7 +98,7 @@ static void notrace walk_stackframe(struct task_struct *task,
 
 static bool print_trace_address(unsigned long pc, void *arg)
 {
-	print_ip_sym(pc);
+	print_ip_sym(KERN_DEFAULT, pc);
 	return false;
 }
 
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 657a83b943f0..98338dc6b5d2 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -165,9 +165,9 @@ static inline int kallsyms_show_value(void)
 
 #endif /*CONFIG_KALLSYMS*/
 
-static inline void print_ip_sym(unsigned long ip)
+static inline void print_ip_sym(const char *loglvl, unsigned long ip)
 {
-	printk("[<%px>] %pS\n", (void *) ip, (void *) ip);
+	printk("%s[<%px>] %pS\n", loglvl, (void *) ip, (void *) ip);
 }
 
 #endif /*_LINUX_KALLSYMS_H*/
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 233459c03b5a..914ff610b880 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3999,7 +3999,7 @@ static void print_unlock_imbalance_bug(struct task_struct *curr,
 		curr->comm, task_pid_nr(curr));
 	print_lockdep_cache(lock);
 	pr_cont(") at:\n");
-	print_ip_sym(ip);
+	print_ip_sym(KERN_WARNING, ip);
 	pr_warn("but there are no more locks to release!\n");
 	pr_warn("\nother info that might help us debug this:\n");
 	lockdep_print_held_locks(curr);
@@ -4604,7 +4604,7 @@ static void print_lock_contention_bug(struct task_struct *curr,
 		curr->comm, task_pid_nr(curr));
 	print_lockdep_cache(lock);
 	pr_cont(") at:\n");
-	print_ip_sym(ip);
+	print_ip_sym(KERN_WARNING, ip);
 	pr_warn("but there are no locks held!\n");
 	pr_warn("\nother info that might help us debug this:\n");
 	lockdep_print_held_locks(curr);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index dd05a378631a..774ff0d8dfe9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3858,7 +3858,7 @@ static noinline void __schedule_bug(struct task_struct *prev)
 	if (IS_ENABLED(CONFIG_DEBUG_PREEMPT)
 	    && in_atomic_preempt_off()) {
 		pr_err("Preemption disabled at:");
-		print_ip_sym(preempt_disable_ip);
+		print_ip_sym(KERN_ERR, preempt_disable_ip);
 		pr_cont("\n");
 	}
 	if (panic_on_warn)
@@ -6774,7 +6774,7 @@ void ___might_sleep(const char *file, int line, int preempt_offset)
 	if (IS_ENABLED(CONFIG_DEBUG_PREEMPT)
 	    && !preempt_count_equals(preempt_offset)) {
 		pr_err("Preemption disabled at:");
-		print_ip_sym(preempt_disable_ip);
+		print_ip_sym(KERN_ERR, preempt_disable_ip);
 		pr_cont("\n");
 	}
 	dump_stack();
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index f296d89be757..04a95cdf414f 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2002,12 +2002,12 @@ void ftrace_bug(int failed, struct dyn_ftrace *rec)
 	case -EFAULT:
 		FTRACE_WARN_ON_ONCE(1);
 		pr_info("ftrace faulted on modifying ");
-		print_ip_sym(ip);
+		print_ip_sym(KERN_INFO, ip);
 		break;
 	case -EINVAL:
 		FTRACE_WARN_ON_ONCE(1);
 		pr_info("ftrace failed to modify ");
-		print_ip_sym(ip);
+		print_ip_sym(KERN_INFO, ip);
 		print_ip_ins(" actual:   ", (unsigned char *)ip);
 		pr_cont("\n");
 		if (ftrace_expected) {
@@ -2018,12 +2018,12 @@ void ftrace_bug(int failed, struct dyn_ftrace *rec)
 	case -EPERM:
 		FTRACE_WARN_ON_ONCE(1);
 		pr_info("ftrace faulted on writing ");
-		print_ip_sym(ip);
+		print_ip_sym(KERN_INFO, ip);
 		break;
 	default:
 		FTRACE_WARN_ON_ONCE(1);
 		pr_info("ftrace faulted on unknown error ");
-		print_ip_sym(ip);
+		print_ip_sym(KERN_INFO, ip);
 	}
 	print_bug_type();
 	if (rec) {
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 01/50] kallsyms/printk: Add loglvl to print_ip_sym()
@ 2019-11-06  3:04   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Juri Lelli, Tetsuo Handa, James Hogan, Dmitry Safonov,
	Ben Segall, linux-riscv, Vincent Chen, Will Deacon, Ingo Molnar,
	Vincent Guittot, Paul Burton, Dmitry Safonov, Peter Zijlstra,
	Ingo Molnar, Mel Gorman, Jiri Slaby, Petr Mladek, Albert Ou,
	Steven Rostedt, Greentime Hu, Paul Walmsley, Thomas Gleixner,
	Dietmar Eggemann, Michal Simek, Greg Kroah-Hartman, linux-mips,
	Ralf Baechle, Sergey Senozhatsky, Palmer Dabbelt, Andrew Morton

print_ip_sym() needs to have a log level parameter to comply with other
parts being printed. Otherwise, half of the expected backtrace would be
printed and other may be missing with some logging level.

The following callee(s) are using now the adjusted log level:
- microblaze/unwind: the same level as headers & userspace unwind.
  Note that pr_debug()'s there are for debugging the unwinder itself.
- nds32/traps: symbol addresses are printed with the same log level
  as backtrace headers.
- lockdep: ip for locking issues is printed with the same log level
  as other part of the warning.
- sched: ip where preemption was disabled is printed as error like
  the rest part of the message.
- ftrace: bug reports are now consistent in the log level being used.

Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Ben Segall <bsegall@google.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Will Deacon <will@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-riscv@lists.infradead.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/microblaze/kernel/unwind.c | 2 +-
 arch/mips/kernel/traps.c        | 4 ++--
 arch/nds32/kernel/traps.c       | 4 ++--
 arch/riscv/kernel/stacktrace.c  | 2 +-
 include/linux/kallsyms.h        | 4 ++--
 kernel/locking/lockdep.c        | 4 ++--
 kernel/sched/core.c             | 4 ++--
 kernel/trace/ftrace.c           | 8 ++++----
 8 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/microblaze/kernel/unwind.c b/arch/microblaze/kernel/unwind.c
index 34c270cb11fc..4241cdd28ee7 100644
--- a/arch/microblaze/kernel/unwind.c
+++ b/arch/microblaze/kernel/unwind.c
@@ -254,7 +254,7 @@ static void microblaze_unwind_inner(struct task_struct *task,
 					task->comm);
 				break;
 			} else
-				print_ip_sym(pc);
+				print_ip_sym(KERN_INFO, pc);
 		}
 
 		/* Stop when we reach anything not part of the kernel */
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 342e41de9d64..861e79868055 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -123,7 +123,7 @@ static void show_raw_backtrace(unsigned long reg29)
 			break;
 		}
 		if (__kernel_text_address(addr))
-			print_ip_sym(addr);
+			print_ip_sym(KERN_DEFAULT, addr);
 	}
 	printk("\n");
 }
@@ -153,7 +153,7 @@ static void show_backtrace(struct task_struct *task, const struct pt_regs *regs)
 	}
 	printk("Call Trace:\n");
 	do {
-		print_ip_sym(pc);
+		print_ip_sym(KERN_DEFAULT, pc);
 		pc = unwind_stack(task, &sp, pc, &ra);
 	} while (pc);
 	pr_cont("\n");
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index f4d386b52622..40625760a125 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -108,7 +108,7 @@ static void __dump(struct task_struct *tsk, unsigned long *base_reg)
 			if (__kernel_text_address(ret_addr)) {
 				ret_addr = ftrace_graph_ret_addr(
 						tsk, &graph, ret_addr, NULL);
-				print_ip_sym(ret_addr);
+				print_ip_sym(KERN_EMERG, ret_addr);
 			}
 			if (--cnt < 0)
 				break;
@@ -124,7 +124,7 @@ static void __dump(struct task_struct *tsk, unsigned long *base_reg)
 
 				ret_addr = ftrace_graph_ret_addr(
 						tsk, &graph, ret_addr, NULL);
-				print_ip_sym(ret_addr);
+				print_ip_sym(KERN_EMERG, ret_addr);
 			}
 			if (--cnt < 0)
 				break;
diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 0940681d2f68..a76892b48fff 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -98,7 +98,7 @@ static void notrace walk_stackframe(struct task_struct *task,
 
 static bool print_trace_address(unsigned long pc, void *arg)
 {
-	print_ip_sym(pc);
+	print_ip_sym(KERN_DEFAULT, pc);
 	return false;
 }
 
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 657a83b943f0..98338dc6b5d2 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -165,9 +165,9 @@ static inline int kallsyms_show_value(void)
 
 #endif /*CONFIG_KALLSYMS*/
 
-static inline void print_ip_sym(unsigned long ip)
+static inline void print_ip_sym(const char *loglvl, unsigned long ip)
 {
-	printk("[<%px>] %pS\n", (void *) ip, (void *) ip);
+	printk("%s[<%px>] %pS\n", loglvl, (void *) ip, (void *) ip);
 }
 
 #endif /*_LINUX_KALLSYMS_H*/
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 233459c03b5a..914ff610b880 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3999,7 +3999,7 @@ static void print_unlock_imbalance_bug(struct task_struct *curr,
 		curr->comm, task_pid_nr(curr));
 	print_lockdep_cache(lock);
 	pr_cont(") at:\n");
-	print_ip_sym(ip);
+	print_ip_sym(KERN_WARNING, ip);
 	pr_warn("but there are no more locks to release!\n");
 	pr_warn("\nother info that might help us debug this:\n");
 	lockdep_print_held_locks(curr);
@@ -4604,7 +4604,7 @@ static void print_lock_contention_bug(struct task_struct *curr,
 		curr->comm, task_pid_nr(curr));
 	print_lockdep_cache(lock);
 	pr_cont(") at:\n");
-	print_ip_sym(ip);
+	print_ip_sym(KERN_WARNING, ip);
 	pr_warn("but there are no locks held!\n");
 	pr_warn("\nother info that might help us debug this:\n");
 	lockdep_print_held_locks(curr);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index dd05a378631a..774ff0d8dfe9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3858,7 +3858,7 @@ static noinline void __schedule_bug(struct task_struct *prev)
 	if (IS_ENABLED(CONFIG_DEBUG_PREEMPT)
 	    && in_atomic_preempt_off()) {
 		pr_err("Preemption disabled at:");
-		print_ip_sym(preempt_disable_ip);
+		print_ip_sym(KERN_ERR, preempt_disable_ip);
 		pr_cont("\n");
 	}
 	if (panic_on_warn)
@@ -6774,7 +6774,7 @@ void ___might_sleep(const char *file, int line, int preempt_offset)
 	if (IS_ENABLED(CONFIG_DEBUG_PREEMPT)
 	    && !preempt_count_equals(preempt_offset)) {
 		pr_err("Preemption disabled at:");
-		print_ip_sym(preempt_disable_ip);
+		print_ip_sym(KERN_ERR, preempt_disable_ip);
 		pr_cont("\n");
 	}
 	dump_stack();
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index f296d89be757..04a95cdf414f 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2002,12 +2002,12 @@ void ftrace_bug(int failed, struct dyn_ftrace *rec)
 	case -EFAULT:
 		FTRACE_WARN_ON_ONCE(1);
 		pr_info("ftrace faulted on modifying ");
-		print_ip_sym(ip);
+		print_ip_sym(KERN_INFO, ip);
 		break;
 	case -EINVAL:
 		FTRACE_WARN_ON_ONCE(1);
 		pr_info("ftrace failed to modify ");
-		print_ip_sym(ip);
+		print_ip_sym(KERN_INFO, ip);
 		print_ip_ins(" actual:   ", (unsigned char *)ip);
 		pr_cont("\n");
 		if (ftrace_expected) {
@@ -2018,12 +2018,12 @@ void ftrace_bug(int failed, struct dyn_ftrace *rec)
 	case -EPERM:
 		FTRACE_WARN_ON_ONCE(1);
 		pr_info("ftrace faulted on writing ");
-		print_ip_sym(ip);
+		print_ip_sym(KERN_INFO, ip);
 		break;
 	default:
 		FTRACE_WARN_ON_ONCE(1);
 		pr_info("ftrace faulted on unknown error ");
-		print_ip_sym(ip);
+		print_ip_sym(KERN_INFO, ip);
 	}
 	print_bug_type();
 	if (rec) {
-- 
2.23.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 02/50] alpha: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (5 preceding siblings ...)
  (?)
@ 2019-11-06  3:04 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Ivan Kokshaysky, Matt Turner, Richard Henderson, linux-alpha

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: linux-alpha@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/alpha/kernel/traps.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index f6b9664ac504..2402f1777f54 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -121,10 +121,10 @@ dik_show_code(unsigned int *pc)
 }
 
 static void
-dik_show_trace(unsigned long *sp)
+dik_show_trace(unsigned long *sp, const char *loglvl)
 {
 	long i = 0;
-	printk("Trace:\n");
+	printk("%sTrace:\n", loglvl);
 	while (0x1ff8 & (unsigned long) sp) {
 		extern char _stext[], _etext[];
 		unsigned long tmp = *sp;
@@ -133,24 +133,25 @@ dik_show_trace(unsigned long *sp)
 			continue;
 		if (tmp >= (unsigned long) &_etext)
 			continue;
-		printk("[<%lx>] %pSR\n", tmp, (void *)tmp);
+		printk("%s[<%lx>] %pSR\n", loglvl, tmp, (void *)tmp);
 		if (i > 40) {
-			printk(" ...");
+			printk("%s ...", loglvl);
 			break;
 		}
 	}
-	printk("\n");
+	printk("%s\n", loglvl);
 }
 
 static int kstack_depth_to_print = 24;
 
-void show_stack(struct task_struct *task, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+			const char *loglvl)
 {
 	unsigned long *stack;
 	int i;
 
 	/*
-	 * debugging aid: "show_stack(NULL);" prints the
+	 * debugging aid: "show_stack(NULL, NULL, KERN_EMERG);" prints the
 	 * back trace for this cpu.
 	 */
 	if(sp==NULL)
@@ -163,14 +164,19 @@ void show_stack(struct task_struct *task, unsigned long *sp)
 		if ((i % 4) == 0) {
 			if (i)
 				pr_cont("\n");
-			printk("       ");
+			printk("%s       ", loglvl);
 		} else {
 			pr_cont(" ");
 		}
 		pr_cont("%016lx", *stack++);
 	}
 	pr_cont("\n");
-	dik_show_trace(sp);
+	dik_show_trace(sp, loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
 }
 
 void
@@ -184,7 +190,7 @@ die_if_kernel(char * str, struct pt_regs *regs, long err, unsigned long *r9_15)
 	printk("%s(%d): %s %ld\n", current->comm, task_pid_nr(current), str, err);
 	dik_show_regs(regs, r9_15);
 	add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
-	dik_show_trace((unsigned long *)(regs+1));
+	dik_show_trace((unsigned long *)(regs+1), KERN_DEFAULT);
 	dik_show_code((unsigned int *)regs->pc);
 
 	if (test_and_set_thread_flag (TIF_DIE_IF_KERNEL)) {
@@ -625,7 +631,7 @@ do_entUna(void * va, unsigned long opcode, unsigned long reg,
 	printk("gp = %016lx  sp = %p\n", regs->gp, regs+1);
 
 	dik_show_code((unsigned int *)pc);
-	dik_show_trace((unsigned long *)(regs+1));
+	dik_show_trace((unsigned long *)(regs+1), KERN_DEFAULT);
 
 	if (test_and_set_thread_flag (TIF_DIE_IF_KERNEL)) {
 		printk("die_if_kernel recursion detected.\n");
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 03/50] arc: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:04   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Vineet Gupta,
	linux-snps-arc

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

As a good side-effect header "Stack Trace:" is now printed with the same
log level as the rest of backtrace.

Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arc/include/asm/bug.h     |  3 ++-
 arch/arc/kernel/stacktrace.c   | 21 +++++++++++++++------
 arch/arc/kernel/troubleshoot.c |  2 +-
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/arch/arc/include/asm/bug.h b/arch/arc/include/asm/bug.h
index 0be19fd1a412..4c453ba96c51 100644
--- a/arch/arc/include/asm/bug.h
+++ b/arch/arc/include/asm/bug.h
@@ -13,7 +13,8 @@
 struct task_struct;
 
 void show_regs(struct pt_regs *regs);
-void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs);
+void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs,
+		     const char *loglvl);
 void show_kernel_fault_diag(const char *str, struct pt_regs *regs,
 			    unsigned long address);
 void die(const char *str, struct pt_regs *regs, unsigned long address);
diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index 1e440bbfa876..24f9cd8a12c9 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -158,9 +158,11 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs,
 /* Call-back which plugs into unwinding core to dump the stack in
  * case of panic/OOPs/BUG etc
  */
-static int __print_sym(unsigned int address, void *unused)
+static int __print_sym(unsigned int address, void *arg)
 {
-	printk("  %pS\n", (void *)address);
+	const char *loglvl = arg;
+
+	printk("%s  %pS\n", loglvl, (void *)address);
 	return 0;
 }
 
@@ -217,17 +219,24 @@ static int __get_first_nonsched(unsigned int address, void *unused)
  *-------------------------------------------------------------------------
  */
 
-noinline void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs)
+noinline void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs,
+			      const char *loglvl)
 {
-	pr_info("\nStack Trace:\n");
-	arc_unwind_core(tsk, regs, __print_sym, NULL);
+	printk("%s\nStack Trace:\n", loglvl);
+	arc_unwind_core(tsk, regs, __print_sym, (void *)loglvl);
 }
 EXPORT_SYMBOL(show_stacktrace);
 
 /* Expected by sched Code */
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+			const char *loglvl)
+{
+	show_stacktrace(tsk, NULL, loglvl);
+}
+
 void show_stack(struct task_struct *tsk, unsigned long *sp)
 {
-	show_stacktrace(tsk, NULL);
+	show_stack_loglvl(tsk, sp, KERN_DEFAULT);
 }
 
 /* Another API expected by schedular, shows up in "ps" as Wait Channel
diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c
index b79886a6cec8..3f8fc1efcb60 100644
--- a/arch/arc/kernel/troubleshoot.c
+++ b/arch/arc/kernel/troubleshoot.c
@@ -245,5 +245,5 @@ void show_kernel_fault_diag(const char *str, struct pt_regs *regs,
 
 	/* Show stack trace if this Fatality happened in kernel mode */
 	if (!user_mode(regs))
-		show_stacktrace(current, regs);
+		show_stacktrace(current, regs, KERN_DEFAULT);
 }
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 03/50] arc: Add show_stack_loglvl()
@ 2019-11-06  3:04   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Dmitry Safonov, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, Steven Rostedt, Sergey Senozhatsky, Vineet Gupta,
	Jiri Slaby, Andrew Morton, linux-snps-arc, Ingo Molnar

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

As a good side-effect header "Stack Trace:" is now printed with the same
log level as the rest of backtrace.

Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arc/include/asm/bug.h     |  3 ++-
 arch/arc/kernel/stacktrace.c   | 21 +++++++++++++++------
 arch/arc/kernel/troubleshoot.c |  2 +-
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/arch/arc/include/asm/bug.h b/arch/arc/include/asm/bug.h
index 0be19fd1a412..4c453ba96c51 100644
--- a/arch/arc/include/asm/bug.h
+++ b/arch/arc/include/asm/bug.h
@@ -13,7 +13,8 @@
 struct task_struct;
 
 void show_regs(struct pt_regs *regs);
-void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs);
+void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs,
+		     const char *loglvl);
 void show_kernel_fault_diag(const char *str, struct pt_regs *regs,
 			    unsigned long address);
 void die(const char *str, struct pt_regs *regs, unsigned long address);
diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index 1e440bbfa876..24f9cd8a12c9 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -158,9 +158,11 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs *regs,
 /* Call-back which plugs into unwinding core to dump the stack in
  * case of panic/OOPs/BUG etc
  */
-static int __print_sym(unsigned int address, void *unused)
+static int __print_sym(unsigned int address, void *arg)
 {
-	printk("  %pS\n", (void *)address);
+	const char *loglvl = arg;
+
+	printk("%s  %pS\n", loglvl, (void *)address);
 	return 0;
 }
 
@@ -217,17 +219,24 @@ static int __get_first_nonsched(unsigned int address, void *unused)
  *-------------------------------------------------------------------------
  */
 
-noinline void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs)
+noinline void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs,
+			      const char *loglvl)
 {
-	pr_info("\nStack Trace:\n");
-	arc_unwind_core(tsk, regs, __print_sym, NULL);
+	printk("%s\nStack Trace:\n", loglvl);
+	arc_unwind_core(tsk, regs, __print_sym, (void *)loglvl);
 }
 EXPORT_SYMBOL(show_stacktrace);
 
 /* Expected by sched Code */
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+			const char *loglvl)
+{
+	show_stacktrace(tsk, NULL, loglvl);
+}
+
 void show_stack(struct task_struct *tsk, unsigned long *sp)
 {
-	show_stacktrace(tsk, NULL);
+	show_stack_loglvl(tsk, sp, KERN_DEFAULT);
 }
 
 /* Another API expected by schedular, shows up in "ps" as Wait Channel
diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c
index b79886a6cec8..3f8fc1efcb60 100644
--- a/arch/arc/kernel/troubleshoot.c
+++ b/arch/arc/kernel/troubleshoot.c
@@ -245,5 +245,5 @@ void show_kernel_fault_diag(const char *str, struct pt_regs *regs,
 
 	/* Show stack trace if this Fatality happened in kernel mode */
 	if (!user_mode(regs))
-		show_stacktrace(current, regs);
+		show_stacktrace(current, regs, KERN_DEFAULT);
 }
-- 
2.23.0


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 04/50] arm/asm: Add loglvl to c_backtrace()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:04   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Russell King,
	Will Deacon, linux-arm-kernel, clang-built-linux

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to c_backtrace() as a preparation for introducing
show_stack_loglvl().

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/include/asm/bug.h     |  3 ++-
 arch/arm/include/asm/traps.h   |  3 ++-
 arch/arm/kernel/traps.c        |  9 +++++----
 arch/arm/kernel/unwind.c       |  2 +-
 arch/arm/lib/backtrace-clang.S |  9 +++++++--
 arch/arm/lib/backtrace.S       | 14 ++++++++++----
 6 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index deef4d0cb3b5..673c7dd75ab9 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -82,7 +82,8 @@ void hook_ifault_code(int nr, int (*fn)(unsigned long, unsigned int,
 				       struct pt_regs *),
 		     int sig, int code, const char *name);
 
-extern asmlinkage void c_backtrace(unsigned long fp, int pmode);
+extern asmlinkage void c_backtrace(unsigned long fp, int pmode,
+				   const char *loglvl);
 
 struct mm_struct;
 void show_pte(const char *lvl, struct mm_struct *mm, unsigned long addr);
diff --git a/arch/arm/include/asm/traps.h b/arch/arm/include/asm/traps.h
index 172b08ff3760..987fefb0a4db 100644
--- a/arch/arm/include/asm/traps.h
+++ b/arch/arm/include/asm/traps.h
@@ -29,7 +29,8 @@ static inline int __in_irqentry_text(unsigned long ptr)
 }
 
 extern void __init early_trap_init(void *);
-extern void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame);
+extern void dump_backtrace_entry(unsigned long where, unsigned long from,
+				 unsigned long frame, const char *loglvl);
 extern void ptrace_break(struct pt_regs *regs);
 
 extern void *vectors_page;
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index c053abd1fb53..7c3f32b26585 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -62,7 +62,8 @@ __setup("user_debug=", user_debug_setup);
 
 static void dump_mem(const char *, const char *, unsigned long, unsigned long);
 
-void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame)
+void dump_backtrace_entry(unsigned long where, unsigned long from,
+			  unsigned long frame, const char *loglvl)
 {
 #ifdef CONFIG_KALLSYMS
 	printk("[<%08lx>] (%ps) from [<%08lx>] (%pS)\n", where, (void *)where, from, (void *)from);
@@ -74,7 +75,7 @@ void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long
 		dump_mem("", "Exception stack", frame + 4, frame + 4 + sizeof(struct pt_regs));
 }
 
-void dump_backtrace_stm(u32 *stack, u32 instruction)
+void dump_backtrace_stm(u32 *stack, u32 instruction, const char *loglvl)
 {
 	char str[80], *p;
 	unsigned int x;
@@ -236,7 +237,7 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 	pr_cont("\n");
 
 	if (ok)
-		c_backtrace(fp, mode);
+		c_backtrace(fp, mode, NULL);
 }
 #endif
 
@@ -662,7 +663,7 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
 		dump_instr("", regs);
 		if (user_mode(regs)) {
 			__show_regs(regs);
-			c_backtrace(frame_pointer(regs), processor_mode(regs));
+			c_backtrace(frame_pointer(regs), processor_mode(regs), NULL);
 		}
 	}
 #endif
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 4574e6aea0a5..0a65005e10f0 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -493,7 +493,7 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 		urc = unwind_frame(&frame);
 		if (urc < 0)
 			break;
-		dump_backtrace_entry(where, frame.pc, frame.sp - 4);
+		dump_backtrace_entry(where, frame.pc, frame.sp - 4, NULL);
 	}
 }
 
diff --git a/arch/arm/lib/backtrace-clang.S b/arch/arm/lib/backtrace-clang.S
index 2ff375144b55..6174c45f53a5 100644
--- a/arch/arm/lib/backtrace-clang.S
+++ b/arch/arm/lib/backtrace-clang.S
@@ -17,6 +17,7 @@
 #define sv_pc	r6
 #define mask	r7
 #define sv_lr	r8
+#define loglvl	r9
 
 ENTRY(c_backtrace)
 
@@ -99,6 +100,7 @@ ENDPROC(c_backtrace)
 						@ to ensure 8 byte alignment
 		movs	frame, r0		@ if frame pointer is zero
 		beq	no_frame		@ we have no stack frames
+		mov	loglvl, r2
 		tst	r1, #0x10		@ 26 or 32-bit mode?
 		moveq	mask, #0xfc000003
 		movne	mask, #0		@ mask for 32-bit
@@ -167,6 +169,7 @@ finished_setup:
 		mov	r1, sv_lr
 		mov	r2, frame
 		bic	r1, r1, mask		@ mask PC/LR for the mode
+		mov	r3, loglvl
 		bl	dump_backtrace_entry
 
 /*
@@ -183,6 +186,7 @@ finished_setup:
 		ldr	r0, [frame]		@ locals are stored in
 						@ the preceding frame
 		subeq	r0, r0, #4
+		mov	r2, loglvl
 		bleq	dump_backtrace_stm	@ dump saved registers
 
 /*
@@ -196,7 +200,8 @@ finished_setup:
 		bhi	for_each_frame
 
 1006:		adr	r0, .Lbad
-		mov	r1, frame
+		mov	r1, loglvl
+		mov	r2, frame
 		bl	printk
 no_frame:	ldmfd	sp!, {r4 - r9, fp, pc}
 ENDPROC(c_backtrace)
@@ -209,7 +214,7 @@ ENDPROC(c_backtrace)
 		.long   1005b, 1006b
 		.popsection
 
-.Lbad:		.asciz	"Backtrace aborted due to bad frame pointer <%p>\n"
+.Lbad:		.asciz	"%sBacktrace aborted due to bad frame pointer <%p>\n"
 		.align
 .Lopcode:	.word	0xe92d4800 >> 11	@ stmfd sp!, {... fp, lr}
 		.word	0x0b000000		@ bl if these bits are set
diff --git a/arch/arm/lib/backtrace.S b/arch/arm/lib/backtrace.S
index 582925238d65..872f658638d9 100644
--- a/arch/arm/lib/backtrace.S
+++ b/arch/arm/lib/backtrace.S
@@ -18,6 +18,7 @@
 #define sv_pc	r6
 #define mask	r7
 #define offset	r8
+#define loglvl	r9
 
 ENTRY(c_backtrace)
 
@@ -25,9 +26,10 @@ ENTRY(c_backtrace)
 		ret	lr
 ENDPROC(c_backtrace)
 #else
-		stmfd	sp!, {r4 - r8, lr}	@ Save an extra register so we have a location...
+		stmfd	sp!, {r4 - r9, lr}	@ Save an extra register so we have a location...
 		movs	frame, r0		@ if frame pointer is zero
 		beq	no_frame		@ we have no stack frames
+		mov	loglvl, r2
 
 		tst	r1, #0x10		@ 26 or 32-bit mode?
  ARM(		moveq	mask, #0xfc000003	)
@@ -73,6 +75,7 @@ for_each_frame:	tst	frame, mask		@ Check for address exceptions
 		ldr	r1, [frame, #-4]	@ get saved lr
 		mov	r2, frame
 		bic	r1, r1, mask		@ mask PC/LR for the mode
+		mov	r3, loglvl
 		bl	dump_backtrace_entry
 
 		ldr	r1, [sv_pc, #-4]	@ if stmfd sp!, {args} exists,
@@ -80,12 +83,14 @@ for_each_frame:	tst	frame, mask		@ Check for address exceptions
 		teq	r3, r1, lsr #11
 		ldreq	r0, [frame, #-8]	@ get sp
 		subeq	r0, r0, #4		@ point at the last arg
+		mov	r2, loglvl
 		bleq	dump_backtrace_stm	@ dump saved registers
 
 1004:		ldr	r1, [sv_pc, #0]		@ if stmfd sp!, {..., fp, ip, lr, pc}
 		ldr	r3, .Ldsi		@ instruction exists,
 		teq	r3, r1, lsr #11
 		subeq	r0, frame, #16
+		mov	r2, loglvl
 		bleq	dump_backtrace_stm	@ dump saved registers
 
 		teq	sv_fp, #0		@ zero saved fp means
@@ -96,9 +101,10 @@ for_each_frame:	tst	frame, mask		@ Check for address exceptions
 		bhi	for_each_frame
 
 1006:		adr	r0, .Lbad
-		mov	r1, frame
+		mov	r1, loglvl
+		mov	r2, frame
 		bl	printk
-no_frame:	ldmfd	sp!, {r4 - r8, pc}
+no_frame:	ldmfd	sp!, {r4 - r9, pc}
 ENDPROC(c_backtrace)
 		
 		.pushsection __ex_table,"a"
@@ -109,7 +115,7 @@ ENDPROC(c_backtrace)
 		.long	1004b, 1006b
 		.popsection
 
-.Lbad:		.asciz	"Backtrace aborted due to bad frame pointer <%p>\n"
+.Lbad:		.asciz	"%sBacktrace aborted due to bad frame pointer <%p>\n"
 		.align
 .Ldsi:		.word	0xe92dd800 >> 11	@ stmfd sp!, {... fp, ip, lr, pc}
 		.word	0xe92d0000 >> 11	@ stmfd sp!, {}
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 04/50] arm/asm: Add loglvl to c_backtrace()
@ 2019-11-06  3:04   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Dmitry Safonov, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, Russell King, Steven Rostedt, Sergey Senozhatsky,
	clang-built-linux, Jiri Slaby, Andrew Morton, Will Deacon,
	Ingo Molnar, linux-arm-kernel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to c_backtrace() as a preparation for introducing
show_stack_loglvl().

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/include/asm/bug.h     |  3 ++-
 arch/arm/include/asm/traps.h   |  3 ++-
 arch/arm/kernel/traps.c        |  9 +++++----
 arch/arm/kernel/unwind.c       |  2 +-
 arch/arm/lib/backtrace-clang.S |  9 +++++++--
 arch/arm/lib/backtrace.S       | 14 ++++++++++----
 6 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index deef4d0cb3b5..673c7dd75ab9 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
@@ -82,7 +82,8 @@ void hook_ifault_code(int nr, int (*fn)(unsigned long, unsigned int,
 				       struct pt_regs *),
 		     int sig, int code, const char *name);
 
-extern asmlinkage void c_backtrace(unsigned long fp, int pmode);
+extern asmlinkage void c_backtrace(unsigned long fp, int pmode,
+				   const char *loglvl);
 
 struct mm_struct;
 void show_pte(const char *lvl, struct mm_struct *mm, unsigned long addr);
diff --git a/arch/arm/include/asm/traps.h b/arch/arm/include/asm/traps.h
index 172b08ff3760..987fefb0a4db 100644
--- a/arch/arm/include/asm/traps.h
+++ b/arch/arm/include/asm/traps.h
@@ -29,7 +29,8 @@ static inline int __in_irqentry_text(unsigned long ptr)
 }
 
 extern void __init early_trap_init(void *);
-extern void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame);
+extern void dump_backtrace_entry(unsigned long where, unsigned long from,
+				 unsigned long frame, const char *loglvl);
 extern void ptrace_break(struct pt_regs *regs);
 
 extern void *vectors_page;
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index c053abd1fb53..7c3f32b26585 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -62,7 +62,8 @@ __setup("user_debug=", user_debug_setup);
 
 static void dump_mem(const char *, const char *, unsigned long, unsigned long);
 
-void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame)
+void dump_backtrace_entry(unsigned long where, unsigned long from,
+			  unsigned long frame, const char *loglvl)
 {
 #ifdef CONFIG_KALLSYMS
 	printk("[<%08lx>] (%ps) from [<%08lx>] (%pS)\n", where, (void *)where, from, (void *)from);
@@ -74,7 +75,7 @@ void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long
 		dump_mem("", "Exception stack", frame + 4, frame + 4 + sizeof(struct pt_regs));
 }
 
-void dump_backtrace_stm(u32 *stack, u32 instruction)
+void dump_backtrace_stm(u32 *stack, u32 instruction, const char *loglvl)
 {
 	char str[80], *p;
 	unsigned int x;
@@ -236,7 +237,7 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 	pr_cont("\n");
 
 	if (ok)
-		c_backtrace(fp, mode);
+		c_backtrace(fp, mode, NULL);
 }
 #endif
 
@@ -662,7 +663,7 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
 		dump_instr("", regs);
 		if (user_mode(regs)) {
 			__show_regs(regs);
-			c_backtrace(frame_pointer(regs), processor_mode(regs));
+			c_backtrace(frame_pointer(regs), processor_mode(regs), NULL);
 		}
 	}
 #endif
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 4574e6aea0a5..0a65005e10f0 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -493,7 +493,7 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 		urc = unwind_frame(&frame);
 		if (urc < 0)
 			break;
-		dump_backtrace_entry(where, frame.pc, frame.sp - 4);
+		dump_backtrace_entry(where, frame.pc, frame.sp - 4, NULL);
 	}
 }
 
diff --git a/arch/arm/lib/backtrace-clang.S b/arch/arm/lib/backtrace-clang.S
index 2ff375144b55..6174c45f53a5 100644
--- a/arch/arm/lib/backtrace-clang.S
+++ b/arch/arm/lib/backtrace-clang.S
@@ -17,6 +17,7 @@
 #define sv_pc	r6
 #define mask	r7
 #define sv_lr	r8
+#define loglvl	r9
 
 ENTRY(c_backtrace)
 
@@ -99,6 +100,7 @@ ENDPROC(c_backtrace)
 						@ to ensure 8 byte alignment
 		movs	frame, r0		@ if frame pointer is zero
 		beq	no_frame		@ we have no stack frames
+		mov	loglvl, r2
 		tst	r1, #0x10		@ 26 or 32-bit mode?
 		moveq	mask, #0xfc000003
 		movne	mask, #0		@ mask for 32-bit
@@ -167,6 +169,7 @@ finished_setup:
 		mov	r1, sv_lr
 		mov	r2, frame
 		bic	r1, r1, mask		@ mask PC/LR for the mode
+		mov	r3, loglvl
 		bl	dump_backtrace_entry
 
 /*
@@ -183,6 +186,7 @@ finished_setup:
 		ldr	r0, [frame]		@ locals are stored in
 						@ the preceding frame
 		subeq	r0, r0, #4
+		mov	r2, loglvl
 		bleq	dump_backtrace_stm	@ dump saved registers
 
 /*
@@ -196,7 +200,8 @@ finished_setup:
 		bhi	for_each_frame
 
 1006:		adr	r0, .Lbad
-		mov	r1, frame
+		mov	r1, loglvl
+		mov	r2, frame
 		bl	printk
 no_frame:	ldmfd	sp!, {r4 - r9, fp, pc}
 ENDPROC(c_backtrace)
@@ -209,7 +214,7 @@ ENDPROC(c_backtrace)
 		.long   1005b, 1006b
 		.popsection
 
-.Lbad:		.asciz	"Backtrace aborted due to bad frame pointer <%p>\n"
+.Lbad:		.asciz	"%sBacktrace aborted due to bad frame pointer <%p>\n"
 		.align
 .Lopcode:	.word	0xe92d4800 >> 11	@ stmfd sp!, {... fp, lr}
 		.word	0x0b000000		@ bl if these bits are set
diff --git a/arch/arm/lib/backtrace.S b/arch/arm/lib/backtrace.S
index 582925238d65..872f658638d9 100644
--- a/arch/arm/lib/backtrace.S
+++ b/arch/arm/lib/backtrace.S
@@ -18,6 +18,7 @@
 #define sv_pc	r6
 #define mask	r7
 #define offset	r8
+#define loglvl	r9
 
 ENTRY(c_backtrace)
 
@@ -25,9 +26,10 @@ ENTRY(c_backtrace)
 		ret	lr
 ENDPROC(c_backtrace)
 #else
-		stmfd	sp!, {r4 - r8, lr}	@ Save an extra register so we have a location...
+		stmfd	sp!, {r4 - r9, lr}	@ Save an extra register so we have a location...
 		movs	frame, r0		@ if frame pointer is zero
 		beq	no_frame		@ we have no stack frames
+		mov	loglvl, r2
 
 		tst	r1, #0x10		@ 26 or 32-bit mode?
  ARM(		moveq	mask, #0xfc000003	)
@@ -73,6 +75,7 @@ for_each_frame:	tst	frame, mask		@ Check for address exceptions
 		ldr	r1, [frame, #-4]	@ get saved lr
 		mov	r2, frame
 		bic	r1, r1, mask		@ mask PC/LR for the mode
+		mov	r3, loglvl
 		bl	dump_backtrace_entry
 
 		ldr	r1, [sv_pc, #-4]	@ if stmfd sp!, {args} exists,
@@ -80,12 +83,14 @@ for_each_frame:	tst	frame, mask		@ Check for address exceptions
 		teq	r3, r1, lsr #11
 		ldreq	r0, [frame, #-8]	@ get sp
 		subeq	r0, r0, #4		@ point at the last arg
+		mov	r2, loglvl
 		bleq	dump_backtrace_stm	@ dump saved registers
 
 1004:		ldr	r1, [sv_pc, #0]		@ if stmfd sp!, {..., fp, ip, lr, pc}
 		ldr	r3, .Ldsi		@ instruction exists,
 		teq	r3, r1, lsr #11
 		subeq	r0, frame, #16
+		mov	r2, loglvl
 		bleq	dump_backtrace_stm	@ dump saved registers
 
 		teq	sv_fp, #0		@ zero saved fp means
@@ -96,9 +101,10 @@ for_each_frame:	tst	frame, mask		@ Check for address exceptions
 		bhi	for_each_frame
 
 1006:		adr	r0, .Lbad
-		mov	r1, frame
+		mov	r1, loglvl
+		mov	r2, frame
 		bl	printk
-no_frame:	ldmfd	sp!, {r4 - r8, pc}
+no_frame:	ldmfd	sp!, {r4 - r9, pc}
 ENDPROC(c_backtrace)
 		
 		.pushsection __ex_table,"a"
@@ -109,7 +115,7 @@ ENDPROC(c_backtrace)
 		.long	1004b, 1006b
 		.popsection
 
-.Lbad:		.asciz	"Backtrace aborted due to bad frame pointer <%p>\n"
+.Lbad:		.asciz	"%sBacktrace aborted due to bad frame pointer <%p>\n"
 		.align
 .Ldsi:		.word	0xe92dd800 >> 11	@ stmfd sp!, {... fp, ip, lr, pc}
 		.word	0xe92d0000 >> 11	@ stmfd sp!, {}
-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 05/50] arm: Add loglvl to unwind_backtrace()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:04   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Russell King,
	Will Deacon, linux-arm-kernel, clang-built-linux

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to unwind_backtrace() as a preparation for
introducing show_stack_loglvl().

As a good side-effect arm_syscall() is now printing errors with the same
log level as the backtrace.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/include/asm/unwind.h | 3 ++-
 arch/arm/kernel/traps.c       | 6 +++---
 arch/arm/kernel/unwind.c      | 7 ++++---
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/unwind.h b/arch/arm/include/asm/unwind.h
index 6e282c33126b..0f8a3439902d 100644
--- a/arch/arm/include/asm/unwind.h
+++ b/arch/arm/include/asm/unwind.h
@@ -36,7 +36,8 @@ extern struct unwind_table *unwind_table_add(unsigned long start,
 					     unsigned long text_addr,
 					     unsigned long text_size);
 extern void unwind_table_del(struct unwind_table *tab);
-extern void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk);
+extern void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+			     const char *loglvl);
 
 #endif	/* !__ASSEMBLY__ */
 
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 7c3f32b26585..69e35462c9e9 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -202,7 +202,7 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
 #ifdef CONFIG_ARM_UNWIND
 static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 {
-	unwind_backtrace(regs, tsk);
+	unwind_backtrace(regs, tsk, KERN_DEBUG);
 }
 #else
 static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
@@ -660,10 +660,10 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
 	if (user_debug & UDBG_SYSCALL) {
 		pr_err("[%d] %s: arm syscall %d\n",
 		       task_pid_nr(current), current->comm, no);
-		dump_instr("", regs);
+		dump_instr(KERN_ERR, regs);
 		if (user_mode(regs)) {
 			__show_regs(regs);
-			c_backtrace(frame_pointer(regs), processor_mode(regs), NULL);
+			c_backtrace(frame_pointer(regs), processor_mode(regs), KERN_ERR);
 		}
 	}
 #endif
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 0a65005e10f0..caaae1b6f721 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -455,11 +455,12 @@ int unwind_frame(struct stackframe *frame)
 	return URC_OK;
 }
 
-void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
+void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+		      const char *loglvl)
 {
 	struct stackframe frame;
 
-	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);
 
 	if (!tsk)
 		tsk = current;
@@ -493,7 +494,7 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 		urc = unwind_frame(&frame);
 		if (urc < 0)
 			break;
-		dump_backtrace_entry(where, frame.pc, frame.sp - 4, NULL);
+		dump_backtrace_entry(where, frame.pc, frame.sp - 4, loglvl);
 	}
 }
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 05/50] arm: Add loglvl to unwind_backtrace()
@ 2019-11-06  3:04   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Dmitry Safonov, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, Russell King, Steven Rostedt, Sergey Senozhatsky,
	clang-built-linux, Jiri Slaby, Andrew Morton, Will Deacon,
	Ingo Molnar, linux-arm-kernel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to unwind_backtrace() as a preparation for
introducing show_stack_loglvl().

As a good side-effect arm_syscall() is now printing errors with the same
log level as the backtrace.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/include/asm/unwind.h | 3 ++-
 arch/arm/kernel/traps.c       | 6 +++---
 arch/arm/kernel/unwind.c      | 7 ++++---
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/unwind.h b/arch/arm/include/asm/unwind.h
index 6e282c33126b..0f8a3439902d 100644
--- a/arch/arm/include/asm/unwind.h
+++ b/arch/arm/include/asm/unwind.h
@@ -36,7 +36,8 @@ extern struct unwind_table *unwind_table_add(unsigned long start,
 					     unsigned long text_addr,
 					     unsigned long text_size);
 extern void unwind_table_del(struct unwind_table *tab);
-extern void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk);
+extern void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+			     const char *loglvl);
 
 #endif	/* !__ASSEMBLY__ */
 
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 7c3f32b26585..69e35462c9e9 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -202,7 +202,7 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
 #ifdef CONFIG_ARM_UNWIND
 static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 {
-	unwind_backtrace(regs, tsk);
+	unwind_backtrace(regs, tsk, KERN_DEBUG);
 }
 #else
 static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
@@ -660,10 +660,10 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
 	if (user_debug & UDBG_SYSCALL) {
 		pr_err("[%d] %s: arm syscall %d\n",
 		       task_pid_nr(current), current->comm, no);
-		dump_instr("", regs);
+		dump_instr(KERN_ERR, regs);
 		if (user_mode(regs)) {
 			__show_regs(regs);
-			c_backtrace(frame_pointer(regs), processor_mode(regs), NULL);
+			c_backtrace(frame_pointer(regs), processor_mode(regs), KERN_ERR);
 		}
 	}
 #endif
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 0a65005e10f0..caaae1b6f721 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -455,11 +455,12 @@ int unwind_frame(struct stackframe *frame)
 	return URC_OK;
 }
 
-void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
+void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+		      const char *loglvl)
 {
 	struct stackframe frame;
 
-	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);
 
 	if (!tsk)
 		tsk = current;
@@ -493,7 +494,7 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 		urc = unwind_frame(&frame);
 		if (urc < 0)
 			break;
-		dump_backtrace_entry(where, frame.pc, frame.sp - 4, NULL);
+		dump_backtrace_entry(where, frame.pc, frame.sp - 4, loglvl);
 	}
 }
 
-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 06/50] arm: Add loglvl to dump_backtrace()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:04   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Russell King,
	Will Deacon, linux-arm-kernel, clang-built-linux

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to dump_backtrace() as a preparation for
introducing show_stack_loglvl().

As a good side-effect __die() now prints not only "Stack:" header with
KERN_EMERG, but the backtrace itself.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/kernel/traps.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 69e35462c9e9..e4f4ec8a1899 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -200,17 +200,19 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
 }
 
 #ifdef CONFIG_ARM_UNWIND
-static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
+static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+				  const char *loglvl)
 {
-	unwind_backtrace(regs, tsk, KERN_DEBUG);
+	unwind_backtrace(regs, tsk, loglvl);
 }
 #else
-static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
+static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+			   const char *loglvl)
 {
 	unsigned int fp, mode;
 	int ok = 1;
 
-	printk("Backtrace: ");
+	printk("%sBacktrace: ", loglvl);
 
 	if (!tsk)
 		tsk = current;
@@ -237,13 +239,13 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 	pr_cont("\n");
 
 	if (ok)
-		c_backtrace(fp, mode, NULL);
+		c_backtrace(fp, mode, loglvl);
 }
 #endif
 
 void show_stack(struct task_struct *tsk, unsigned long *sp)
 {
-	dump_backtrace(NULL, tsk);
+	dump_backtrace(NULL, tsk, KERN_DEFAULT);
 	barrier();
 }
 
@@ -285,7 +287,7 @@ static int __die(const char *str, int err, struct pt_regs *regs)
 	if (!user_mode(regs) || in_interrupt()) {
 		dump_mem(KERN_EMERG, "Stack: ", regs->ARM_sp,
 			 THREAD_SIZE + (unsigned long)task_stack_page(tsk));
-		dump_backtrace(regs, tsk);
+		dump_backtrace(regs, tsk, KERN_EMERG);
 		dump_instr(KERN_EMERG, regs);
 	}
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 06/50] arm: Add loglvl to dump_backtrace()
@ 2019-11-06  3:04   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Dmitry Safonov, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, Russell King, Steven Rostedt, Sergey Senozhatsky,
	clang-built-linux, Jiri Slaby, Andrew Morton, Will Deacon,
	Ingo Molnar, linux-arm-kernel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to dump_backtrace() as a preparation for
introducing show_stack_loglvl().

As a good side-effect __die() now prints not only "Stack:" header with
KERN_EMERG, but the backtrace itself.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/kernel/traps.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 69e35462c9e9..e4f4ec8a1899 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -200,17 +200,19 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
 }
 
 #ifdef CONFIG_ARM_UNWIND
-static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
+static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+				  const char *loglvl)
 {
-	unwind_backtrace(regs, tsk, KERN_DEBUG);
+	unwind_backtrace(regs, tsk, loglvl);
 }
 #else
-static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
+static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+			   const char *loglvl)
 {
 	unsigned int fp, mode;
 	int ok = 1;
 
-	printk("Backtrace: ");
+	printk("%sBacktrace: ", loglvl);
 
 	if (!tsk)
 		tsk = current;
@@ -237,13 +239,13 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 	pr_cont("\n");
 
 	if (ok)
-		c_backtrace(fp, mode, NULL);
+		c_backtrace(fp, mode, loglvl);
 }
 #endif
 
 void show_stack(struct task_struct *tsk, unsigned long *sp)
 {
-	dump_backtrace(NULL, tsk);
+	dump_backtrace(NULL, tsk, KERN_DEFAULT);
 	barrier();
 }
 
@@ -285,7 +287,7 @@ static int __die(const char *str, int err, struct pt_regs *regs)
 	if (!user_mode(regs) || in_interrupt()) {
 		dump_mem(KERN_EMERG, "Stack: ", regs->ARM_sp,
 			 THREAD_SIZE + (unsigned long)task_stack_page(tsk));
-		dump_backtrace(regs, tsk);
+		dump_backtrace(regs, tsk, KERN_EMERG);
 		dump_instr(KERN_EMERG, regs);
 	}
 
-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 07/50] arm: Wire up dump_backtrace_{entry,stm}
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:04   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Russell King,
	Will Deacon, linux-arm-kernel, clang-built-linux

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Now that c_backtrace() always emits correct loglvl, use it for printing.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/kernel/traps.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index e4f4ec8a1899..16022b75a72f 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -66,13 +66,16 @@ void dump_backtrace_entry(unsigned long where, unsigned long from,
 			  unsigned long frame, const char *loglvl)
 {
 #ifdef CONFIG_KALLSYMS
-	printk("[<%08lx>] (%ps) from [<%08lx>] (%pS)\n", where, (void *)where, from, (void *)from);
+	printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n",
+		loglvl, where, (void *)where, from, (void *)from);
 #else
-	printk("Function entered at [<%08lx>] from [<%08lx>]\n", where, from);
+	printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n",
+		loglvl, where, from);
 #endif
 
 	if (in_entry_text(from))
-		dump_mem("", "Exception stack", frame + 4, frame + 4 + sizeof(struct pt_regs));
+		dump_mem(loglvl, "Exception stack",
+			frame + 4, frame + 4 + sizeof(struct pt_regs));
 }
 
 void dump_backtrace_stm(u32 *stack, u32 instruction, const char *loglvl)
@@ -87,12 +90,12 @@ void dump_backtrace_stm(u32 *stack, u32 instruction, const char *loglvl)
 			if (++x == 6) {
 				x = 0;
 				p = str;
-				printk("%s\n", str);
+				printk("%s%s\n", loglvl, str);
 			}
 		}
 	}
 	if (p != str)
-		printk("%s\n", str);
+		printk("%s%s\n", loglvl, str);
 }
 
 #ifndef CONFIG_ARM_UNWIND
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 07/50] arm: Wire up dump_backtrace_{entry,stm}
@ 2019-11-06  3:04   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Dmitry Safonov, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, Russell King, Steven Rostedt, Sergey Senozhatsky,
	clang-built-linux, Jiri Slaby, Andrew Morton, Will Deacon,
	Ingo Molnar, linux-arm-kernel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Now that c_backtrace() always emits correct loglvl, use it for printing.

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/kernel/traps.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index e4f4ec8a1899..16022b75a72f 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -66,13 +66,16 @@ void dump_backtrace_entry(unsigned long where, unsigned long from,
 			  unsigned long frame, const char *loglvl)
 {
 #ifdef CONFIG_KALLSYMS
-	printk("[<%08lx>] (%ps) from [<%08lx>] (%pS)\n", where, (void *)where, from, (void *)from);
+	printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n",
+		loglvl, where, (void *)where, from, (void *)from);
 #else
-	printk("Function entered at [<%08lx>] from [<%08lx>]\n", where, from);
+	printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n",
+		loglvl, where, from);
 #endif
 
 	if (in_entry_text(from))
-		dump_mem("", "Exception stack", frame + 4, frame + 4 + sizeof(struct pt_regs));
+		dump_mem(loglvl, "Exception stack",
+			frame + 4, frame + 4 + sizeof(struct pt_regs));
 }
 
 void dump_backtrace_stm(u32 *stack, u32 instruction, const char *loglvl)
@@ -87,12 +90,12 @@ void dump_backtrace_stm(u32 *stack, u32 instruction, const char *loglvl)
 			if (++x == 6) {
 				x = 0;
 				p = str;
-				printk("%s\n", str);
+				printk("%s%s\n", loglvl, str);
 			}
 		}
 	}
 	if (p != str)
-		printk("%s\n", str);
+		printk("%s%s\n", loglvl, str);
 }
 
 #ifndef CONFIG_ARM_UNWIND
-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 08/50] arm: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:04   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Russell King,
	Will Deacon, linux-arm-kernel, clang-built-linux

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/kernel/traps.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 16022b75a72f..f999a0e4bab8 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -246,12 +246,18 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 }
 #endif
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+		       const char *loglvl)
 {
-	dump_backtrace(NULL, tsk, KERN_DEFAULT);
+	dump_backtrace(NULL, tsk, loglvl);
 	barrier();
 }
 
+void show_stack(struct task_struct *tsk, unsigned long *sp)
+{
+	show_stack_loglvl(tsk, sp, KERN_DEFAULT);
+}
+
 #ifdef CONFIG_PREEMPT
 #define S_PREEMPT " PREEMPT"
 #else
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 08/50] arm: Add show_stack_loglvl()
@ 2019-11-06  3:04   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:04 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Dmitry Safonov, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, Russell King, Steven Rostedt, Sergey Senozhatsky,
	clang-built-linux, Jiri Slaby, Andrew Morton, Will Deacon,
	Ingo Molnar, linux-arm-kernel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: clang-built-linux@googlegroups.com
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm/kernel/traps.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 16022b75a72f..f999a0e4bab8 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -246,12 +246,18 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 }
 #endif
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+		       const char *loglvl)
 {
-	dump_backtrace(NULL, tsk, KERN_DEFAULT);
+	dump_backtrace(NULL, tsk, loglvl);
 	barrier();
 }
 
+void show_stack(struct task_struct *tsk, unsigned long *sp)
+{
+	show_stack_loglvl(tsk, sp, KERN_DEFAULT);
+}
+
 #ifdef CONFIG_PREEMPT
 #define S_PREEMPT " PREEMPT"
 #else
-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 09/50] arm64: Add loglvl to dump_backtrace()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Catalin Marinas, Russell King, Will Deacon, linux-arm-kernel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to dump_backtrace() as a preparation for
introducing show_stack_loglvl().

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm64/include/asm/stacktrace.h |  3 ++-
 arch/arm64/kernel/process.c         |  2 +-
 arch/arm64/kernel/traps.c           | 17 +++++++++--------
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/stacktrace.h b/arch/arm64/include/asm/stacktrace.h
index 4d9b1f48dc39..fdb913cc0bcb 100644
--- a/arch/arm64/include/asm/stacktrace.h
+++ b/arch/arm64/include/asm/stacktrace.h
@@ -64,7 +64,8 @@ struct stackframe {
 extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
 extern void walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
 			    int (*fn)(struct stackframe *, void *), void *data);
-extern void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk);
+extern void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+			   const char *loglvl);
 
 DECLARE_PER_CPU(unsigned long *, irq_stack_ptr);
 
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 71f788cd2b18..1a6b58b1be2c 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -291,7 +291,7 @@ void __show_regs(struct pt_regs *regs)
 void show_regs(struct pt_regs * regs)
 {
 	__show_regs(regs);
-	dump_backtrace(regs, NULL);
+	dump_backtrace(regs, NULL, KERN_DEFAULT);
 }
 
 static void tls_thread_flush(void)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 34739e80211b..59072c7b9fb4 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -52,9 +52,9 @@ static const char *handler[]= {
 
 int show_unhandled_signals = 0;
 
-static void dump_backtrace_entry(unsigned long where)
+static void dump_backtrace_entry(unsigned long where, const char *loglvl)
 {
-	printk(" %pS\n", (void *)where);
+	printk("%s %pS\n", loglvl, (void *)where);
 }
 
 static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
@@ -82,12 +82,13 @@ static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
 	printk("%sCode: %s\n", lvl, str);
 }
 
-void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
+void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+		    const char *loglvl)
 {
 	struct stackframe frame;
 	int skip = 0;
 
-	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);
 
 	if (regs) {
 		if (user_mode(regs))
@@ -114,11 +115,11 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 				thread_saved_pc(tsk));
 	}
 
-	printk("Call trace:\n");
+	printk("%sCall trace:\n", loglvl);
 	do {
 		/* skip until specified stack frame */
 		if (!skip) {
-			dump_backtrace_entry(frame.pc);
+			dump_backtrace_entry(frame.pc, loglvl);
 		} else if (frame.fp == regs->regs[29]) {
 			skip = 0;
 			/*
@@ -128,7 +129,7 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 			 * at which an exception has taken place, use regs->pc
 			 * instead.
 			 */
-			dump_backtrace_entry(regs->pc);
+			dump_backtrace_entry(regs->pc, loglvl);
 		}
 	} while (!unwind_frame(tsk, &frame));
 
@@ -137,7 +138,7 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 
 void show_stack(struct task_struct *tsk, unsigned long *sp)
 {
-	dump_backtrace(NULL, tsk);
+	dump_backtrace(NULL, tsk, KERN_DEFAULT);
 	barrier();
 }
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 09/50] arm64: Add loglvl to dump_backtrace()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Catalin Marinas, Dmitry Safonov, Tetsuo Handa,
	Greg Kroah-Hartman, Dmitry Safonov, Russell King, Steven Rostedt,
	Sergey Senozhatsky, Jiri Slaby, Andrew Morton, Will Deacon,
	Ingo Molnar, linux-arm-kernel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to dump_backtrace() as a preparation for
introducing show_stack_loglvl().

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm64/include/asm/stacktrace.h |  3 ++-
 arch/arm64/kernel/process.c         |  2 +-
 arch/arm64/kernel/traps.c           | 17 +++++++++--------
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/stacktrace.h b/arch/arm64/include/asm/stacktrace.h
index 4d9b1f48dc39..fdb913cc0bcb 100644
--- a/arch/arm64/include/asm/stacktrace.h
+++ b/arch/arm64/include/asm/stacktrace.h
@@ -64,7 +64,8 @@ struct stackframe {
 extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
 extern void walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
 			    int (*fn)(struct stackframe *, void *), void *data);
-extern void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk);
+extern void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+			   const char *loglvl);
 
 DECLARE_PER_CPU(unsigned long *, irq_stack_ptr);
 
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 71f788cd2b18..1a6b58b1be2c 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -291,7 +291,7 @@ void __show_regs(struct pt_regs *regs)
 void show_regs(struct pt_regs * regs)
 {
 	__show_regs(regs);
-	dump_backtrace(regs, NULL);
+	dump_backtrace(regs, NULL, KERN_DEFAULT);
 }
 
 static void tls_thread_flush(void)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 34739e80211b..59072c7b9fb4 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -52,9 +52,9 @@ static const char *handler[]= {
 
 int show_unhandled_signals = 0;
 
-static void dump_backtrace_entry(unsigned long where)
+static void dump_backtrace_entry(unsigned long where, const char *loglvl)
 {
-	printk(" %pS\n", (void *)where);
+	printk("%s %pS\n", loglvl, (void *)where);
 }
 
 static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
@@ -82,12 +82,13 @@ static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
 	printk("%sCode: %s\n", lvl, str);
 }
 
-void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
+void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+		    const char *loglvl)
 {
 	struct stackframe frame;
 	int skip = 0;
 
-	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);
 
 	if (regs) {
 		if (user_mode(regs))
@@ -114,11 +115,11 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 				thread_saved_pc(tsk));
 	}
 
-	printk("Call trace:\n");
+	printk("%sCall trace:\n", loglvl);
 	do {
 		/* skip until specified stack frame */
 		if (!skip) {
-			dump_backtrace_entry(frame.pc);
+			dump_backtrace_entry(frame.pc, loglvl);
 		} else if (frame.fp == regs->regs[29]) {
 			skip = 0;
 			/*
@@ -128,7 +129,7 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 			 * at which an exception has taken place, use regs->pc
 			 * instead.
 			 */
-			dump_backtrace_entry(regs->pc);
+			dump_backtrace_entry(regs->pc, loglvl);
 		}
 	} while (!unwind_frame(tsk, &frame));
 
@@ -137,7 +138,7 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 
 void show_stack(struct task_struct *tsk, unsigned long *sp)
 {
-	dump_backtrace(NULL, tsk);
+	dump_backtrace(NULL, tsk, KERN_DEFAULT);
 	barrier();
 }
 
-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 10/50] arm64: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Catalin Marinas, Russell King, Will Deacon, linux-arm-kernel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm64/kernel/traps.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 59072c7b9fb4..5b3ae8ed33fd 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -136,12 +136,18 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 	put_task_stack(tsk);
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+		       const char *loglvl)
 {
-	dump_backtrace(NULL, tsk, KERN_DEFAULT);
+	dump_backtrace(NULL, tsk, loglvl);
 	barrier();
 }
 
+void show_stack(struct task_struct *tsk, unsigned long *sp)
+{
+	show_stack_loglvl(tsk, sp, KERN_DEFAULT);
+}
+
 #ifdef CONFIG_PREEMPT
 #define S_PREEMPT " PREEMPT"
 #else
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 10/50] arm64: Add show_stack_loglvl()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Catalin Marinas, Dmitry Safonov, Tetsuo Handa,
	Greg Kroah-Hartman, Dmitry Safonov, Russell King, Steven Rostedt,
	Sergey Senozhatsky, Jiri Slaby, Andrew Morton, Will Deacon,
	Ingo Molnar, linux-arm-kernel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/arm64/kernel/traps.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 59072c7b9fb4..5b3ae8ed33fd 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -136,12 +136,18 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 	put_task_stack(tsk);
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+		       const char *loglvl)
 {
-	dump_backtrace(NULL, tsk, KERN_DEFAULT);
+	dump_backtrace(NULL, tsk, loglvl);
 	barrier();
 }
 
+void show_stack(struct task_struct *tsk, unsigned long *sp)
+{
+	show_stack_loglvl(tsk, sp, KERN_DEFAULT);
+}
+
 #ifdef CONFIG_PREEMPT
 #define S_PREEMPT " PREEMPT"
 #else
-- 
2.23.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 11/50] c6x: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (14 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Aurelien Jacquiot, Mark Salter, linux-c6x-dev

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: linux-c6x-dev@linux-c6x.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/c6x/kernel/traps.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/c6x/kernel/traps.c b/arch/c6x/kernel/traps.c
index ec61034fdf56..07704670236b 100644
--- a/arch/c6x/kernel/traps.c
+++ b/arch/c6x/kernel/traps.c
@@ -344,12 +344,13 @@ asmlinkage int process_exception(struct pt_regs *regs)
 
 static int kstack_depth_to_print = 48;
 
-static void show_trace(unsigned long *stack, unsigned long *endstack)
+static void show_trace(unsigned long *stack, unsigned long *endstack,
+		       const char *loglvl)
 {
 	unsigned long addr;
 	int i;
 
-	pr_debug("Call trace:");
+	printk("%sCall trace:", loglvl);
 	i = 0;
 	while (stack + 1 <= endstack) {
 		addr = *stack++;
@@ -364,16 +365,17 @@ static void show_trace(unsigned long *stack, unsigned long *endstack)
 		if (__kernel_text_address(addr)) {
 #ifndef CONFIG_KALLSYMS
 			if (i % 5 == 0)
-				pr_debug("\n	    ");
+				printk("%s\n	    ", loglvl);
 #endif
-			pr_debug(" [<%08lx>] %pS\n", addr, (void *)addr);
+			printk("%s [<%08lx>] %pS\n", loglvl, addr, (void *)addr);
 			i++;
 		}
 	}
-	pr_debug("\n");
+	printk("%s\n", loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *stack)
+void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+		const char *loglvl)
 {
 	unsigned long *p, *endstack;
 	int i;
@@ -389,7 +391,7 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 	endstack = (unsigned long *)(((unsigned long)stack + THREAD_SIZE - 1)
 				     & -THREAD_SIZE);
 
-	pr_debug("Stack from %08lx:", (unsigned long)stack);
+	printk("%sStack from %08lx:", loglvl, (unsigned long)stack);
 	for (i = 0, p = stack; i < kstack_depth_to_print; i++) {
 		if (p + 1 > endstack)
 			break;
@@ -398,7 +400,12 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 		pr_cont(" %08lx", *p++);
 	}
 	pr_cont("\n");
-	show_trace(stack, endstack);
+	show_trace(stack, endstack, loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *stack)
+{
+	show_stack_loglvl(task, stack, KERN_DEBUG);
 }
 
 int is_valid_bugaddr(unsigned long addr)
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 12/50] csky: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (15 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Guo Ren

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Guo Ren <guoren@kernel.org>
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/csky/kernel/dumpstack.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/csky/kernel/dumpstack.c b/arch/csky/kernel/dumpstack.c
index d67f9777cfd9..c500837390d3 100644
--- a/arch/csky/kernel/dumpstack.c
+++ b/arch/csky/kernel/dumpstack.c
@@ -5,7 +5,7 @@
 
 int kstack_depth_to_print = 48;
 
-void show_trace(unsigned long *stack)
+static void show_trace(unsigned long *stack, const char *loglvl)
 {
 	unsigned long *stack_end;
 	unsigned long *stack_start;
@@ -17,7 +17,7 @@ void show_trace(unsigned long *stack)
 	stack_end = (unsigned long *) (addr + THREAD_SIZE);
 
 	fp = stack;
-	pr_info("\nCall Trace:");
+	printk("%s\nCall Trace:", loglvl);
 
 	while (fp > stack_start && fp < stack_end) {
 #ifdef CONFIG_STACKTRACE
@@ -32,7 +32,8 @@ void show_trace(unsigned long *stack)
 	pr_cont("\n");
 }
 
-void show_stack(struct task_struct *task, unsigned long *stack)
+void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+		const char *loglvl)
 {
 	if (!stack) {
 		if (task)
@@ -45,5 +46,10 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 #endif
 	}
 
-	show_trace(stack);
+	show_trace(stack, loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *stack)
+{
+	show_stack_loglvl(task, stack, KERN_INFO);
 }
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 13/50] h8300: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (16 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Yoshinori Sato,
	uclinux-h8-devel

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: uclinux-h8-devel@lists.sourceforge.jp
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/h8300/kernel/traps.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/h8300/kernel/traps.c b/arch/h8300/kernel/traps.c
index e47a9e0dc278..6362446563d6 100644
--- a/arch/h8300/kernel/traps.c
+++ b/arch/h8300/kernel/traps.c
@@ -115,7 +115,8 @@ void die(const char *str, struct pt_regs *fp, unsigned long err)
 
 static int kstack_depth_to_print = 24;
 
-void show_stack(struct task_struct *task, unsigned long *esp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *esp,
+		       const char *loglvl)
 {
 	unsigned long *stack,  addr;
 	int i;
@@ -125,17 +126,17 @@ void show_stack(struct task_struct *task, unsigned long *esp)
 
 	stack = esp;
 
-	pr_info("Stack from %08lx:", (unsigned long)stack);
+	printk("%sStack from %08lx:", loglvl, (unsigned long)stack);
 	for (i = 0; i < kstack_depth_to_print; i++) {
 		if (((unsigned long)stack & (THREAD_SIZE - 1)) >=
 		    THREAD_SIZE-4)
 			break;
 		if (i % 8 == 0)
-			pr_info(" ");
+			printk("%s ", loglvl);
 		pr_cont(" %08lx", *stack++);
 	}
 
-	pr_info("\nCall Trace:\n");
+	printk("%s\nCall Trace:\n", loglvl);
 	i = 0;
 	stack = esp;
 	while (((unsigned long)stack & (THREAD_SIZE - 1)) < THREAD_SIZE-4) {
@@ -150,10 +151,15 @@ void show_stack(struct task_struct *task, unsigned long *esp)
 		 */
 		if (check_kernel_text(addr)) {
 			if (i % 4 == 0)
-				pr_info("       ");
+				printk("%s       ", loglvl);
 			pr_cont(" [<%08lx>]", addr);
 			i++;
 		}
 	}
-	pr_info("\n");
+	printk("%s\n", loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *esp)
+{
+	show_stack_loglvl(task, esp, KERN_INFO);
 }
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 14/50] hexagon: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (17 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Brian Cain,
	linux-hexagon

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

As a good side-effect die() now prints the stacktrace with KERN_EMERG
aligned with other messages.

Cc: Brian Cain <bcain@codeaurora.org>
Cc: linux-hexagon@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/hexagon/kernel/traps.c | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/hexagon/kernel/traps.c b/arch/hexagon/kernel/traps.c
index 69c623b14ddd..a8a3a210d781 100644
--- a/arch/hexagon/kernel/traps.c
+++ b/arch/hexagon/kernel/traps.c
@@ -79,7 +79,7 @@ static const char *ex_name(int ex)
 }
 
 static void do_show_stack(struct task_struct *task, unsigned long *fp,
-			  unsigned long ip)
+			  unsigned long ip, const char *loglvl)
 {
 	int kstack_depth_to_print = 24;
 	unsigned long offset, size;
@@ -93,9 +93,8 @@ static void do_show_stack(struct task_struct *task, unsigned long *fp,
 	if (task == NULL)
 		task = current;
 
-	printk(KERN_INFO "CPU#%d, %s/%d, Call Trace:\n",
-	       raw_smp_processor_id(), task->comm,
-	       task_pid_nr(task));
+	printk("%sCPU#%d, %s/%d, Call Trace:\n", loglvl, raw_smp_processor_id(),
+		task->comm, task_pid_nr(task));
 
 	if (fp == NULL) {
 		if (task == current) {
@@ -108,7 +107,7 @@ static void do_show_stack(struct task_struct *task, unsigned long *fp,
 	}
 
 	if ((((unsigned long) fp) & 0x3) || ((unsigned long) fp < 0x1000)) {
-		printk(KERN_INFO "-- Corrupt frame pointer %p\n", fp);
+		printk("%s-- Corrupt frame pointer %p\n", loglvl, fp);
 		return;
 	}
 
@@ -125,8 +124,7 @@ static void do_show_stack(struct task_struct *task, unsigned long *fp,
 
 		name = kallsyms_lookup(ip, &size, &offset, &modname, tmpstr);
 
-		printk(KERN_INFO "[%p] 0x%lx: %s + 0x%lx", fp, ip, name,
-			offset);
+		printk("%s[%p] 0x%lx: %s + 0x%lx", loglvl, fp, ip, name, offset);
 		if (((unsigned long) fp < low) || (high < (unsigned long) fp))
 			printk(KERN_CONT " (FP out of bounds!)");
 		if (modname)
@@ -136,8 +134,7 @@ static void do_show_stack(struct task_struct *task, unsigned long *fp,
 		newfp = (unsigned long *) *fp;
 
 		if (((unsigned long) newfp) & 0x3) {
-			printk(KERN_INFO "-- Corrupt frame pointer %p\n",
-				newfp);
+			printk("%s-- Corrupt frame pointer %p\n", loglvl, newfp);
 			break;
 		}
 
@@ -147,7 +144,7 @@ static void do_show_stack(struct task_struct *task, unsigned long *fp,
 						+ 8);
 
 			if (regs->syscall_nr != -1) {
-				printk(KERN_INFO "-- trap0 -- syscall_nr: %ld",
+				printk("%s-- trap0 -- syscall_nr: %ld", loglvl,
 					regs->syscall_nr);
 				printk(KERN_CONT "  psp: %lx  elr: %lx\n",
 					 pt_psp(regs), pt_elr(regs));
@@ -155,7 +152,7 @@ static void do_show_stack(struct task_struct *task, unsigned long *fp,
 			} else {
 				/* really want to see more ... */
 				kstack_depth_to_print += 6;
-				printk(KERN_INFO "-- %s (0x%lx)  badva: %lx\n",
+				printk("%s-- %s (0x%lx)  badva: %lx\n", loglvl,
 					ex_name(pt_cause(regs)), pt_cause(regs),
 					pt_badva(regs));
 			}
@@ -178,10 +175,16 @@ static void do_show_stack(struct task_struct *task, unsigned long *fp,
 	}
 }
 
-void show_stack(struct task_struct *task, unsigned long *fp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *fp,
+		       const char *loglvl)
 {
 	/* Saved link reg is one word above FP */
-	do_show_stack(task, fp, 0);
+	do_show_stack(task, fp, 0, loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *fp)
+{
+	show_stack_loglvl(task, fp, 0, KERN_INFO);
 }
 
 int die(const char *str, struct pt_regs *regs, long err)
@@ -207,7 +210,7 @@ int die(const char *str, struct pt_regs *regs, long err)
 
 	print_modules();
 	show_regs(regs);
-	do_show_stack(current, &regs->r30, pt_elr(regs));
+	do_show_stack(current, &regs->r30, pt_elr(regs), KERN_EMERG);
 
 	bust_spinlocks(0);
 	add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 15/50] ia64: Pass log level as arg into ia64_do_show_stack()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Fenghua Yu,
	Tony Luck, linux-ia64

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to ia64_do_show_stack() as a preparation to
introduce show_stack_loglvl().
Also, make ia64_do_show_stack() static as it's not used outside.

Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-ia64@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/ia64/include/asm/ptrace.h |  1 -
 arch/ia64/kernel/process.c     | 13 +++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/ia64/include/asm/ptrace.h b/arch/ia64/include/asm/ptrace.h
index 7ff574d56429..b3aa46090101 100644
--- a/arch/ia64/include/asm/ptrace.h
+++ b/arch/ia64/include/asm/ptrace.h
@@ -114,7 +114,6 @@ static inline long regs_return_value(struct pt_regs *regs)
   struct task_struct;			/* forward decl */
   struct unw_frame_info;		/* forward decl */
 
-  extern void ia64_do_show_stack (struct unw_frame_info *, void *);
   extern unsigned long ia64_get_user_rbs_end (struct task_struct *, struct pt_regs *,
 					      unsigned long *);
   extern long ia64_peek (struct task_struct *, struct switch_stack *, unsigned long,
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 968b5f33e725..0526cc51ff0b 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -64,12 +64,13 @@ EXPORT_SYMBOL(boot_option_idle_override);
 void (*pm_power_off) (void);
 EXPORT_SYMBOL(pm_power_off);
 
-void
+static void
 ia64_do_show_stack (struct unw_frame_info *info, void *arg)
 {
 	unsigned long ip, sp, bsp;
+	const char *loglvl = arg;
 
-	printk("\nCall Trace:\n");
+	printk("%s\nCall Trace:\n", loglvl);
 	do {
 		unw_get_ip(info, &ip);
 		if (ip == 0)
@@ -77,9 +78,9 @@ ia64_do_show_stack (struct unw_frame_info *info, void *arg)
 
 		unw_get_sp(info, &sp);
 		unw_get_bsp(info, &bsp);
-		printk(" [<%016lx>] %pS\n"
+		printk("%s [<%016lx>] %pS\n"
 			 "                                sp=%016lx bsp=%016lx\n",
-			 ip, (void *)ip, sp, bsp);
+			 loglvl, ip, (void *)ip, sp, bsp);
 	} while (unw_unwind(info) >= 0);
 }
 
@@ -87,12 +88,12 @@ void
 show_stack (struct task_struct *task, unsigned long *sp)
 {
 	if (!task)
-		unw_init_running(ia64_do_show_stack, NULL);
+		unw_init_running(ia64_do_show_stack, (void *)KERN_DEFAULT);
 	else {
 		struct unw_frame_info info;
 
 		unw_init_from_blocked_task(&info, task);
-		ia64_do_show_stack(&info, NULL);
+		ia64_do_show_stack(&info, (void *)KERN_DEFAULT);
 	}
 }
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 15/50] ia64: Pass log level as arg into ia64_do_show_stack()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Fenghua Yu,
	Tony Luck, linux-ia64

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to ia64_do_show_stack() as a preparation to
introduce show_stack_loglvl().
Also, make ia64_do_show_stack() static as it's not used outside.

Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-ia64@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/ia64/include/asm/ptrace.h |  1 -
 arch/ia64/kernel/process.c     | 13 +++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/ia64/include/asm/ptrace.h b/arch/ia64/include/asm/ptrace.h
index 7ff574d56429..b3aa46090101 100644
--- a/arch/ia64/include/asm/ptrace.h
+++ b/arch/ia64/include/asm/ptrace.h
@@ -114,7 +114,6 @@ static inline long regs_return_value(struct pt_regs *regs)
   struct task_struct;			/* forward decl */
   struct unw_frame_info;		/* forward decl */
 
-  extern void ia64_do_show_stack (struct unw_frame_info *, void *);
   extern unsigned long ia64_get_user_rbs_end (struct task_struct *, struct pt_regs *,
 					      unsigned long *);
   extern long ia64_peek (struct task_struct *, struct switch_stack *, unsigned long,
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 968b5f33e725..0526cc51ff0b 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -64,12 +64,13 @@ EXPORT_SYMBOL(boot_option_idle_override);
 void (*pm_power_off) (void);
 EXPORT_SYMBOL(pm_power_off);
 
-void
+static void
 ia64_do_show_stack (struct unw_frame_info *info, void *arg)
 {
 	unsigned long ip, sp, bsp;
+	const char *loglvl = arg;
 
-	printk("\nCall Trace:\n");
+	printk("%s\nCall Trace:\n", loglvl);
 	do {
 		unw_get_ip(info, &ip);
 		if (ip = 0)
@@ -77,9 +78,9 @@ ia64_do_show_stack (struct unw_frame_info *info, void *arg)
 
 		unw_get_sp(info, &sp);
 		unw_get_bsp(info, &bsp);
-		printk(" [<%016lx>] %pS\n"
+		printk("%s [<%016lx>] %pS\n"
 			 "                                sp=%016lx bsp=%016lx\n",
-			 ip, (void *)ip, sp, bsp);
+			 loglvl, ip, (void *)ip, sp, bsp);
 	} while (unw_unwind(info) >= 0);
 }
 
@@ -87,12 +88,12 @@ void
 show_stack (struct task_struct *task, unsigned long *sp)
 {
 	if (!task)
-		unw_init_running(ia64_do_show_stack, NULL);
+		unw_init_running(ia64_do_show_stack, (void *)KERN_DEFAULT);
 	else {
 		struct unw_frame_info info;
 
 		unw_init_from_blocked_task(&info, task);
-		ia64_do_show_stack(&info, NULL);
+		ia64_do_show_stack(&info, (void *)KERN_DEFAULT);
 	}
 }
 
-- 
2.23.0

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 16/50] ia64: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Fenghua Yu,
	Tony Luck, linux-ia64

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-ia64@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/ia64/kernel/process.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 0526cc51ff0b..b0eeb19bdd8d 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -85,18 +85,25 @@ ia64_do_show_stack (struct unw_frame_info *info, void *arg)
 }
 
 void
-show_stack (struct task_struct *task, unsigned long *sp)
+show_stack_loglvl (struct task_struct *task, unsigned long *sp,
+		   const char *loglvl)
 {
 	if (!task)
-		unw_init_running(ia64_do_show_stack, (void *)KERN_DEFAULT);
+		unw_init_running(ia64_do_show_stack, (void *)loglvl);
 	else {
 		struct unw_frame_info info;
 
 		unw_init_from_blocked_task(&info, task);
-		ia64_do_show_stack(&info, (void *)KERN_DEFAULT);
+		ia64_do_show_stack(&info, (void *)loglvl);
 	}
 }
 
+void
+show_stack (struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
+}
+
 void
 show_regs (struct pt_regs *regs)
 {
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 16/50] ia64: Add show_stack_loglvl()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Fenghua Yu,
	Tony Luck, linux-ia64

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-ia64@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/ia64/kernel/process.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 0526cc51ff0b..b0eeb19bdd8d 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -85,18 +85,25 @@ ia64_do_show_stack (struct unw_frame_info *info, void *arg)
 }
 
 void
-show_stack (struct task_struct *task, unsigned long *sp)
+show_stack_loglvl (struct task_struct *task, unsigned long *sp,
+		   const char *loglvl)
 {
 	if (!task)
-		unw_init_running(ia64_do_show_stack, (void *)KERN_DEFAULT);
+		unw_init_running(ia64_do_show_stack, (void *)loglvl);
 	else {
 		struct unw_frame_info info;
 
 		unw_init_from_blocked_task(&info, task);
-		ia64_do_show_stack(&info, (void *)KERN_DEFAULT);
+		ia64_do_show_stack(&info, (void *)loglvl);
 	}
 }
 
+void
+show_stack (struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
+}
+
 void
 show_regs (struct pt_regs *regs)
 {
-- 
2.23.0

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 17/50] m68k: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (20 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Geert Uytterhoeven, linux-m68k

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/m68k/kernel/traps.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index 344f93d36a9a..ffcc5ec4fac3 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -811,13 +811,13 @@ asmlinkage void buserr_c(struct frame *fp)
 
 static int kstack_depth_to_print = 48;
 
-void show_trace(unsigned long *stack)
+static void show_trace(unsigned long *stack, const char *loglvl)
 {
 	unsigned long *endstack;
 	unsigned long addr;
 	int i;
 
-	pr_info("Call Trace:");
+	printk("%sCall Trace:", loglvl);
 	addr = (unsigned long)stack + THREAD_SIZE - 1;
 	endstack = (unsigned long *)(addr & -THREAD_SIZE);
 	i = 0;
@@ -935,7 +935,8 @@ void show_registers(struct pt_regs *regs)
 	pr_cont("\n");
 }
 
-void show_stack(struct task_struct *task, unsigned long *stack)
+void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+		       const char *loglvl)
 {
 	unsigned long *p;
 	unsigned long *endstack;
@@ -949,7 +950,7 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 	}
 	endstack = (unsigned long *)(((unsigned long)stack + THREAD_SIZE - 1) & -THREAD_SIZE);
 
-	pr_info("Stack from %08lx:", (unsigned long)stack);
+	printk("%sStack from %08lx:", loglvl, (unsigned long)stack);
 	p = stack;
 	for (i = 0; i < kstack_depth_to_print; i++) {
 		if (p + 1 > endstack)
@@ -959,7 +960,12 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 		pr_cont(" %08lx", *p++);
 	}
 	pr_cont("\n");
-	show_trace(stack);
+	show_trace(stack, loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *stack)
+{
+	show_stack_loglvl(task, stack, KERN_INFO);
 }
 
 /*
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 18/50] microblaze: Add loglvl to microblaze_unwind_inner()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (21 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  2019-11-07  8:59   ` Michal Simek
  2019-11-08  7:52     ` kbuild test robot
  -1 siblings, 2 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Michal Simek

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to microblaze_unwind_inner() as a preparation for
introducing show_stack_loglvl().

Cc: Michal Simek <monstr@monstr.eu>
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/microblaze/kernel/unwind.c | 35 ++++++++++++++++++++-------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/arch/microblaze/kernel/unwind.c b/arch/microblaze/kernel/unwind.c
index 4241cdd28ee7..9a7343feadf5 100644
--- a/arch/microblaze/kernel/unwind.c
+++ b/arch/microblaze/kernel/unwind.c
@@ -162,16 +162,18 @@ static void microblaze_unwind_inner(struct task_struct *task,
  */
 #ifdef CONFIG_MMU
 static inline void unwind_trap(struct task_struct *task, unsigned long pc,
-				unsigned long fp, struct stack_trace *trace)
+				unsigned long fp, struct stack_trace *trace,
+				const char *loglvl)
 {
 	/* To be implemented */
 }
 #else
 static inline void unwind_trap(struct task_struct *task, unsigned long pc,
-				unsigned long fp, struct stack_trace *trace)
+				unsigned long fp, struct stack_trace *trace,
+				const char *loglvl)
 {
 	const struct pt_regs *regs = (const struct pt_regs *) fp;
-	microblaze_unwind_inner(task, regs->pc, regs->r1, regs->r15, trace);
+	microblaze_unwind_inner(task, regs->pc, regs->r1, regs->r15, trace, loglvl);
 }
 #endif
 
@@ -184,11 +186,13 @@ static inline void unwind_trap(struct task_struct *task, unsigned long pc,
  *				  the caller's return address.
  * @trace : Where to store stack backtrace (PC values).
  *	    NULL == print backtrace to kernel log
+ * @loglvl : Used for printk log level if (trace == NULL).
  */
 static void microblaze_unwind_inner(struct task_struct *task,
 			     unsigned long pc, unsigned long fp,
 			     unsigned long leaf_return,
-			     struct stack_trace *trace)
+			     struct stack_trace *trace,
+			     const char *loglvl)
 {
 	int ofs = 0;
 
@@ -214,11 +218,11 @@ static void microblaze_unwind_inner(struct task_struct *task,
 			const struct pt_regs *regs =
 				(const struct pt_regs *) fp;
 #endif
-			pr_info("HW EXCEPTION\n");
+			printk("%sHW EXCEPTION\n", loglvl);
 #ifndef CONFIG_MMU
 			microblaze_unwind_inner(task, regs->r17 - 4,
 						fp + EX_HANDLER_STACK_SIZ,
-						regs->r15, trace);
+						regs->r15, trace, loglvl);
 #endif
 			return;
 		}
@@ -228,8 +232,8 @@ static void microblaze_unwind_inner(struct task_struct *task,
 			if ((return_to >= handler->start_addr)
 			    && (return_to <= handler->end_addr)) {
 				if (!trace)
-					pr_info("%s\n", handler->trap_name);
-				unwind_trap(task, pc, fp, trace);
+					printk("%s%s\n", loglvl, handler->trap_name);
+				unwind_trap(task, pc, fp, trace, loglvl);
 				return;
 			}
 		}
@@ -248,13 +252,13 @@ static void microblaze_unwind_inner(struct task_struct *task,
 		} else {
 			/* Have we reached userland? */
 			if (unlikely(pc == task_pt_regs(task)->pc)) {
-				pr_info("[<%p>] PID %lu [%s]\n",
-					(void *) pc,
+				printk("%s[<%p>] PID %lu [%s]\n",
+					loglvl, (void *) pc,
 					(unsigned long) task->pid,
 					task->comm);
 				break;
 			} else
-				print_ip_sym(KERN_INFO, pc);
+				print_ip_sym(loglvl, pc);
 		}
 
 		/* Stop when we reach anything not part of the kernel */
@@ -285,11 +289,13 @@ static void microblaze_unwind_inner(struct task_struct *task,
  */
 void microblaze_unwind(struct task_struct *task, struct stack_trace *trace)
 {
+	const char *loglvl = KERN_INFO;
+
 	if (task) {
 		if (task == current) {
 			const struct pt_regs *regs = task_pt_regs(task);
 			microblaze_unwind_inner(task, regs->pc, regs->r1,
-						regs->r15, trace);
+						regs->r15, trace, loglvl);
 		} else {
 			struct thread_info *thread_info =
 				(struct thread_info *)(task->stack);
@@ -299,7 +305,8 @@ void microblaze_unwind(struct task_struct *task, struct stack_trace *trace)
 			microblaze_unwind_inner(task,
 						(unsigned long) &_switch_to,
 						cpu_context->r1,
-						cpu_context->r15, trace);
+						cpu_context->r15,
+						trace, loglvl);
 		}
 	} else {
 		unsigned long pc, fp;
@@ -314,7 +321,7 @@ void microblaze_unwind(struct task_struct *task, struct stack_trace *trace)
 		);
 
 		/* Since we are not a leaf function, use leaf_return = 0 */
-		microblaze_unwind_inner(current, pc, fp, 0, trace);
+		microblaze_unwind_inner(current, pc, fp, 0, trace, loglvl);
 	}
 }
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 19/50] microblaze: Add loglvl to microblaze_unwind()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (22 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Michal Simek

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level parameter to microblaze_unwind() as a preparation to add
show_stack_loglvl().

Cc: Michal Simek <monstr@monstr.eu>
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/microblaze/include/asm/unwind.h | 3 ++-
 arch/microblaze/kernel/stacktrace.c  | 4 ++--
 arch/microblaze/kernel/traps.c       | 2 +-
 arch/microblaze/kernel/unwind.c      | 6 +++---
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/microblaze/include/asm/unwind.h b/arch/microblaze/include/asm/unwind.h
index d248b7de4b13..7c28f8d5a243 100644
--- a/arch/microblaze/include/asm/unwind.h
+++ b/arch/microblaze/include/asm/unwind.h
@@ -23,7 +23,8 @@ extern struct trap_handler_info microblaze_trap_handlers;
 extern const char _hw_exception_handler;
 extern const char ex_handler_unhandled;
 
-void microblaze_unwind(struct task_struct *task, struct stack_trace *trace);
+void microblaze_unwind(struct task_struct *task, struct stack_trace *trace,
+		       const char *loglvl);
 
 #endif	/* __MICROBLAZE_UNWIND_H */
 
diff --git a/arch/microblaze/kernel/stacktrace.c b/arch/microblaze/kernel/stacktrace.c
index b4debe283a79..b266c4d6ed9d 100644
--- a/arch/microblaze/kernel/stacktrace.c
+++ b/arch/microblaze/kernel/stacktrace.c
@@ -20,12 +20,12 @@ void save_stack_trace(struct stack_trace *trace)
 {
 	/* Exclude our helper functions from the trace*/
 	trace->skip += 2;
-	microblaze_unwind(NULL, trace);
+	microblaze_unwind(NULL, trace, "");
 }
 EXPORT_SYMBOL_GPL(save_stack_trace);
 
 void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
 {
-	microblaze_unwind(tsk, trace);
+	microblaze_unwind(tsk, trace, "");
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
diff --git a/arch/microblaze/kernel/traps.c b/arch/microblaze/kernel/traps.c
index 45bbba9d919f..be726ee120fb 100644
--- a/arch/microblaze/kernel/traps.c
+++ b/arch/microblaze/kernel/traps.c
@@ -68,7 +68,7 @@ void show_stack(struct task_struct *task, unsigned long *sp)
 	print_hex_dump(KERN_INFO, "", DUMP_PREFIX_ADDRESS, 32, 4, (void *)fp,
 		       words_to_show << 2, 0);
 	pr_info("\n\nCall Trace:\n");
-	microblaze_unwind(task, NULL);
+	microblaze_unwind(task, NULL, KERN_INFO);
 	pr_info("\n");
 
 	if (!task)
diff --git a/arch/microblaze/kernel/unwind.c b/arch/microblaze/kernel/unwind.c
index 9a7343feadf5..74dded96c10a 100644
--- a/arch/microblaze/kernel/unwind.c
+++ b/arch/microblaze/kernel/unwind.c
@@ -286,11 +286,11 @@ static void microblaze_unwind_inner(struct task_struct *task,
  * @task  : Task whose stack we are to unwind (NULL == current)
  * @trace : Where to store stack backtrace (PC values).
  *	    NULL == print backtrace to kernel log
+ * @loglvl : Used for printk log level if (trace == NULL).
  */
-void microblaze_unwind(struct task_struct *task, struct stack_trace *trace)
+void microblaze_unwind(struct task_struct *task, struct stack_trace *trace,
+		       const char *loglvl)
 {
-	const char *loglvl = KERN_INFO;
-
 	if (task) {
 		if (task == current) {
 			const struct pt_regs *regs = task_pt_regs(task);
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 20/50] microblaze: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (23 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Michal Simek

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Michal Simek <monstr@monstr.eu>
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/microblaze/kernel/traps.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/microblaze/kernel/traps.c b/arch/microblaze/kernel/traps.c
index be726ee120fb..149ae534937e 100644
--- a/arch/microblaze/kernel/traps.c
+++ b/arch/microblaze/kernel/traps.c
@@ -31,7 +31,8 @@ static int __init kstack_setup(char *s)
 }
 __setup("kstack=", kstack_setup);
 
-void show_stack(struct task_struct *task, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl)
 {
 	unsigned long words_to_show;
 	u32 fp = (u32) sp;
@@ -50,7 +51,7 @@ void show_stack(struct task_struct *task, unsigned long *sp)
 	if (kstack_depth_to_print && (words_to_show > kstack_depth_to_print))
 		words_to_show = kstack_depth_to_print;
 
-	pr_info("Kernel Stack:\n");
+	printk("%sKernel Stack:\n", loglvl);
 
 	/*
 	 * Make the first line an 'odd' size if necessary to get
@@ -65,14 +66,19 @@ void show_stack(struct task_struct *task, unsigned long *sp)
 			words_to_show -= line1_words;
 		}
 	}
-	print_hex_dump(KERN_INFO, "", DUMP_PREFIX_ADDRESS, 32, 4, (void *)fp,
+	print_hex_dump(loglvl, "", DUMP_PREFIX_ADDRESS, 32, 4, (void *)fp,
 		       words_to_show << 2, 0);
-	pr_info("\n\nCall Trace:\n");
-	microblaze_unwind(task, NULL, KERN_INFO);
-	pr_info("\n");
+	printk("%s\n\nCall Trace:\n", loglvl);
+	microblaze_unwind(task, NULL, loglvl);
+	printk("%s\n", loglvl);
 
 	if (!task)
 		task = current;
 
 	debug_show_held_locks(task);
 }
+
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_INFO);
+}
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 21/50] mips: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (24 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, James Hogan,
	Paul Burton, Ralf Baechle, linux-mips

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/mips/kernel/traps.c | 41 +++++++++++++++++++++++-----------------
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 861e79868055..11cdb16311e1 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -106,26 +106,26 @@ void (*board_bind_eic_interrupt)(int irq, int regset);
 void (*board_ebase_setup)(void);
 void(*board_cache_error_setup)(void);
 
-static void show_raw_backtrace(unsigned long reg29)
+static void show_raw_backtrace(unsigned long reg29, const char *loglvl)
 {
 	unsigned long *sp = (unsigned long *)(reg29 & ~3);
 	unsigned long addr;
 
-	printk("Call Trace:");
+	printk("%sCall Trace:", loglvl);
 #ifdef CONFIG_KALLSYMS
-	printk("\n");
+	printk("%s\n", loglvl);
 #endif
 	while (!kstack_end(sp)) {
 		unsigned long __user *p =
 			(unsigned long __user *)(unsigned long)sp++;
 		if (__get_user(addr, p)) {
-			printk(" (Bad stack address)");
+			printk("%s (Bad stack address)", loglvl);
 			break;
 		}
 		if (__kernel_text_address(addr))
-			print_ip_sym(KERN_DEFAULT, addr);
+			print_ip_sym(loglvl, addr);
 	}
-	printk("\n");
+	printk("%s\n", loglvl);
 }
 
 #ifdef CONFIG_KALLSYMS
@@ -138,7 +138,8 @@ static int __init set_raw_show_trace(char *str)
 __setup("raw_show_trace", set_raw_show_trace);
 #endif
 
-static void show_backtrace(struct task_struct *task, const struct pt_regs *regs)
+static void show_backtrace(struct task_struct *task, const struct pt_regs *regs,
+			   const char *loglvl)
 {
 	unsigned long sp = regs->regs[29];
 	unsigned long ra = regs->regs[31];
@@ -148,12 +149,12 @@ static void show_backtrace(struct task_struct *task, const struct pt_regs *regs)
 		task = current;
 
 	if (raw_show_trace || user_mode(regs) || !__kernel_text_address(pc)) {
-		show_raw_backtrace(sp);
+		show_raw_backtrace(sp, loglvl);
 		return;
 	}
-	printk("Call Trace:\n");
+	printk("%sCall Trace:\n", loglvl);
 	do {
-		print_ip_sym(KERN_DEFAULT, pc);
+		print_ip_sym(loglvl, pc);
 		pc = unwind_stack(task, &sp, pc, &ra);
 	} while (pc);
 	pr_cont("\n");
@@ -164,19 +165,19 @@ static void show_backtrace(struct task_struct *task, const struct pt_regs *regs)
  * with at least a bit of error checking ...
  */
 static void show_stacktrace(struct task_struct *task,
-	const struct pt_regs *regs)
+	const struct pt_regs *regs, const char *loglvl)
 {
 	const int field = 2 * sizeof(unsigned long);
 	long stackdata;
 	int i;
 	unsigned long __user *sp = (unsigned long __user *)regs->regs[29];
 
-	printk("Stack :");
+	printk("%sStack :", loglvl);
 	i = 0;
 	while ((unsigned long) sp & (PAGE_SIZE - 1)) {
 		if (i && ((i % (64 / field)) == 0)) {
 			pr_cont("\n");
-			printk("       ");
+			printk("%s       ", loglvl);
 		}
 		if (i > 39) {
 			pr_cont(" ...");
@@ -192,10 +193,11 @@ static void show_stacktrace(struct task_struct *task,
 		i++;
 	}
 	pr_cont("\n");
-	show_backtrace(task, regs);
+	show_backtrace(task, regs, loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl)
 {
 	struct pt_regs regs;
 	mm_segment_t old_fs = get_fs();
@@ -224,10 +226,15 @@ void show_stack(struct task_struct *task, unsigned long *sp)
 	 * the stack in the kernel (not user) address space.
 	 */
 	set_fs(KERNEL_DS);
-	show_stacktrace(task, &regs);
+	show_stacktrace(task, &regs, loglvl);
 	set_fs(old_fs);
 }
 
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT)
+}
+
 static void show_code(unsigned int __user *pc)
 {
 	long i;
@@ -376,7 +383,7 @@ void show_registers(struct pt_regs *regs)
 	if (!user_mode(regs))
 		/* Necessary for getting the correct stack content */
 		set_fs(KERNEL_DS);
-	show_stacktrace(current, regs);
+	show_stacktrace(current, regs, KERN_DEFAULT);
 	show_code((unsigned int __user *) regs->cp0_epc);
 	printk("\n");
 	set_fs(old_fs);
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 22/50] nds32: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (25 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Greentime Hu,
	Vincent Chen

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Greentime Hu <green.hu@gmail.com>
Cc: Vincent Chen <deanbo422@gmail.com>
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/nds32/kernel/traps.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index 40625760a125..90f12582c218 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -97,18 +97,19 @@ static void dump_instr(struct pt_regs *regs)
 }
 
 #define LOOP_TIMES (100)
-static void __dump(struct task_struct *tsk, unsigned long *base_reg)
+static void __dump(struct task_struct *tsk, unsigned long *base_reg,
+		   const char *loglvl)
 {
 	unsigned long ret_addr;
 	int cnt = LOOP_TIMES, graph = 0;
-	pr_emerg("Call Trace:\n");
+	printk("%sCall Trace:\n", loglvl);
 	if (!IS_ENABLED(CONFIG_FRAME_POINTER)) {
 		while (!kstack_end(base_reg)) {
 			ret_addr = *base_reg++;
 			if (__kernel_text_address(ret_addr)) {
 				ret_addr = ftrace_graph_ret_addr(
 						tsk, &graph, ret_addr, NULL);
-				print_ip_sym(KERN_EMERG, ret_addr);
+				print_ip_sym(loglvl, ret_addr);
 			}
 			if (--cnt < 0)
 				break;
@@ -124,17 +125,18 @@ static void __dump(struct task_struct *tsk, unsigned long *base_reg)
 
 				ret_addr = ftrace_graph_ret_addr(
 						tsk, &graph, ret_addr, NULL);
-				print_ip_sym(KERN_EMERG, ret_addr);
+				print_ip_sym(loglvl, ret_addr);
 			}
 			if (--cnt < 0)
 				break;
 			base_reg = (unsigned long *)next_fp;
 		}
 	}
-	pr_emerg("\n");
+	printk("%s\n", loglvl);
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+		       const char *loglvl)
 {
 	unsigned long *base_reg;
 
@@ -151,10 +153,15 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
 		else
 			__asm__ __volatile__("\tori\t%0, $fp, #0\n":"=r"(base_reg));
 	}
-	__dump(tsk, base_reg);
+	__dump(tsk, base_reg, loglvl);
 	barrier();
 }
 
+void show_stack(struct task_struct *tsk, unsigned long *sp)
+{
+	show_stack_loglvl(tsk, sp, KERN_EMERG);
+}
+
 DEFINE_SPINLOCK(die_lock);
 
 /*
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 23/50] nios2: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (26 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Ley Foon Tan,
	nios2-dev

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Ley Foon Tan <lftan@altera.com>
Cc: nios2-dev@lists.rocketboards.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/nios2/kernel/traps.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/nios2/kernel/traps.c b/arch/nios2/kernel/traps.c
index 486db793923c..08071caa9b36 100644
--- a/arch/nios2/kernel/traps.c
+++ b/arch/nios2/kernel/traps.c
@@ -52,12 +52,14 @@ void _exception(int signo, struct pt_regs *regs, int code, unsigned long addr)
 }
 
 /*
- * The show_stack is an external API which we do not use ourselves.
+ * The show_stack(), show_stack_loglvl() are external API
+ * which we do not use ourselves.
  */
 
 int kstack_depth_to_print = 48;
 
-void show_stack(struct task_struct *task, unsigned long *stack)
+void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+		       const char *loglvl)
 {
 	unsigned long *endstack, addr;
 	int i;
@@ -72,16 +74,16 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 	addr = (unsigned long) stack;
 	endstack = (unsigned long *) PAGE_ALIGN(addr);
 
-	pr_emerg("Stack from %08lx:", (unsigned long)stack);
+	printk("%sStack from %08lx:", loglvl, (unsigned long)stack);
 	for (i = 0; i < kstack_depth_to_print; i++) {
 		if (stack + 1 > endstack)
 			break;
 		if (i % 8 == 0)
-			pr_emerg("\n       ");
-		pr_emerg(" %08lx", *stack++);
+			printk("%s\n       ", loglvl);
+		printk("%s %08lx", loglvl, *stack++);
 	}
 
-	pr_emerg("\nCall Trace:");
+	printk("%s\nCall Trace:", loglvl);
 	i = 0;
 	while (stack + 1 <= endstack) {
 		addr = *stack++;
@@ -97,11 +99,16 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 		     (addr <= (unsigned long) _etext))) {
 			if (i % 4 == 0)
 				pr_emerg("\n       ");
-			pr_emerg(" [<%08lx>]", addr);
+			printk("%s [<%08lx>]", loglvl, addr);
 			i++;
 		}
 	}
-	pr_emerg("\n");
+	printk("%s\n", loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *stack)
+{
+	show_stack_loglvl(task, stack, KERN_EMERG);
 }
 
 void __init trap_init(void)
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 24/50] openrisc: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Jonas Bonn,
	Stafford Horne, Stefan Kristiansson, openrisc

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Jonas Bonn <jonas@southpole.se>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: openrisc@lists.librecores.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/openrisc/kernel/traps.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
index 932a8ec2b520..9d5a85dd1992 100644
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -41,18 +41,26 @@ unsigned long __user *lwa_addr;
 
 void print_trace(void *data, unsigned long addr, int reliable)
 {
-	pr_emerg("[<%p>] %s%pS\n", (void *) addr, reliable ? "" : "? ",
+	const char *loglvl = data;
+
+	printk("%s[<%p>] %s%pS\n", loglvl, (void *) addr, reliable ? "" : "? ",
 	       (void *) addr);
 }
 
 /* displays a short stack trace */
-void show_stack(struct task_struct *task, unsigned long *esp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *esp,
+		const char *loglvl)
 {
 	if (esp == NULL)
 		esp = (unsigned long *)&esp;
 
-	pr_emerg("Call trace:\n");
-	unwind_stack(NULL, esp, print_trace);
+	printk("%sCall trace:\n", loglvl);
+	unwind_stack((void *)loglvl, esp, print_trace);
+}
+
+void show_stack(struct task_struct *task, unsigned long *esp)
+{
+	show_stack_loglvl(task, esp, KERN_EMERG);
 }
 
 void show_trace_task(struct task_struct *tsk)
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 24/50] openrisc: Add show_stack_loglvl()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: openrisc

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Jonas Bonn <jonas@southpole.se>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: openrisc at lists.librecores.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima at arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/openrisc/kernel/traps.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
index 932a8ec2b520..9d5a85dd1992 100644
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -41,18 +41,26 @@ unsigned long __user *lwa_addr;
 
 void print_trace(void *data, unsigned long addr, int reliable)
 {
-	pr_emerg("[<%p>] %s%pS\n", (void *) addr, reliable ? "" : "? ",
+	const char *loglvl = data;
+
+	printk("%s[<%p>] %s%pS\n", loglvl, (void *) addr, reliable ? "" : "? ",
 	       (void *) addr);
 }
 
 /* displays a short stack trace */
-void show_stack(struct task_struct *task, unsigned long *esp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *esp,
+		const char *loglvl)
 {
 	if (esp == NULL)
 		esp = (unsigned long *)&esp;
 
-	pr_emerg("Call trace:\n");
-	unwind_stack(NULL, esp, print_trace);
+	printk("%sCall trace:\n", loglvl);
+	unwind_stack((void *)loglvl, esp, print_trace);
+}
+
+void show_stack(struct task_struct *task, unsigned long *esp)
+{
+	show_stack_loglvl(task, esp, KERN_EMERG);
 }
 
 void show_trace_task(struct task_struct *tsk)
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 25/50] parisc: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (28 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Helge Deller,
	James E.J. Bottomley, linux-parisc

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Helge Deller <deller@gmx.de>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: linux-parisc@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/parisc/kernel/traps.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
index 82fc01189488..c2411de3730f 100644
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -49,7 +49,7 @@
 #include "../math-emu/math-emu.h"	/* for handle_fpe() */
 
 static void parisc_show_stack(struct task_struct *task,
-	struct pt_regs *regs);
+	struct pt_regs *regs, const char *loglvl);
 
 static int printbinary(char *buf, unsigned long x, int nbits)
 {
@@ -155,7 +155,7 @@ void show_regs(struct pt_regs *regs)
 		printk("%s IAOQ[1]: %pS\n", level, (void *) regs->iaoq[1]);
 		printk("%s RP(r2): %pS\n", level, (void *) regs->gr[2]);
 
-		parisc_show_stack(current, regs);
+		parisc_show_stack(current, regs, KERN_DEFAULT);
 	}
 }
 
@@ -170,37 +170,43 @@ static DEFINE_RATELIMIT_STATE(_hppa_rs,
 }
 
 
-static void do_show_stack(struct unwind_frame_info *info)
+static void do_show_stack(struct unwind_frame_info *info, const char *loglvl)
 {
 	int i = 1;
 
-	printk(KERN_CRIT "Backtrace:\n");
+	printk("%sBacktrace:\n", loglvl);
 	while (i <= MAX_UNWIND_ENTRIES) {
 		if (unwind_once(info) < 0 || info->ip == 0)
 			break;
 
 		if (__kernel_text_address(info->ip)) {
-			printk(KERN_CRIT " [<" RFMT ">] %pS\n",
-				info->ip, (void *) info->ip);
+			printk("%s [<" RFMT ">] %pS\n",
+				loglvl, info->ip, (void *) info->ip);
 			i++;
 		}
 	}
-	printk(KERN_CRIT "\n");
+	printk("%s\n", loglvl);
 }
 
 static void parisc_show_stack(struct task_struct *task,
-	struct pt_regs *regs)
+	struct pt_regs *regs, const char *loglvl)
 {
 	struct unwind_frame_info info;
 
 	unwind_frame_init_task(&info, task, regs);
 
-	do_show_stack(&info);
+	do_show_stack(&info, loglvl);
+}
+
+void show_stack_loglvl(struct task_struct *t, unsigned long *sp,
+		       const char *loglvl)
+{
+	parisc_show_stack(t, NULL, loglvl);
 }
 
 void show_stack(struct task_struct *t, unsigned long *sp)
 {
-	parisc_show_stack(t, NULL);
+	show_stack_loglvl(t, sp, KERN_CRIT)
 }
 
 int is_valid_bugaddr(unsigned long iaoq)
@@ -446,7 +452,7 @@ void parisc_terminate(char *msg, struct pt_regs *regs, int code, unsigned long o
 		/* show_stack(NULL, (unsigned long *)regs->gr[30]); */
 		struct unwind_frame_info info;
 		unwind_frame_init(&info, current, regs);
-		do_show_stack(&info);
+		do_show_stack(&info, KERN_CRIT);
 	}
 
 	printk("\n");
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 26/50] powerpc: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/powerpc/kernel/process.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 639ceae7da9d..34b46680a196 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2028,7 +2028,8 @@ unsigned long get_wchan(struct task_struct *p)
 
 static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
 
-void show_stack(struct task_struct *tsk, unsigned long *stack)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *stack,
+		       const char *loglvl)
 {
 	unsigned long sp, ip, lr, newsp;
 	int count = 0;
@@ -2053,7 +2054,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 	}
 
 	lr = 0;
-	printk("Call Trace:\n");
+	printk("%sCall Trace:\n", loglvl);
 	do {
 		if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
 			break;
@@ -2062,7 +2063,8 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 		newsp = stack[0];
 		ip = stack[STACK_FRAME_LR_SAVE];
 		if (!firstframe || ip != lr) {
-			printk("["REG"] ["REG"] %pS", sp, ip, (void *)ip);
+			printk("%s["REG"] ["REG"] %pS",
+				loglvl, sp, ip, (void *)ip);
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 			ret_addr = ftrace_graph_ret_addr(current,
 						&ftrace_idx, ip, stack);
@@ -2084,8 +2086,9 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 			struct pt_regs *regs = (struct pt_regs *)
 				(sp + STACK_FRAME_OVERHEAD);
 			lr = regs->link;
-			printk("--- interrupt: %lx at %pS\n    LR = %pS\n",
-			       regs->trap, (void *)regs->nip, (void *)lr);
+			printk("%s--- interrupt: %lx at %pS\n    LR = %pS\n",
+			       loglvl, regs->trap,
+			       (void *)regs->nip, (void *)lr);
 			firstframe = 1;
 		}
 
@@ -2095,6 +2098,11 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 	put_task_stack(tsk);
 }
 
+void show_stack(struct task_struct *tsk, unsigned long *stack)
+{
+	show_stack_loglvl(tsk, stack, KERN_DEFAULT);
+}
+
 #ifdef CONFIG_PPC64
 /* Called with hard IRQs off */
 void notrace __ppc64_runlatch_on(void)
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 26/50] powerpc: Add show_stack_loglvl()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Dmitry Safonov, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, Steven Rostedt, Sergey Senozhatsky,
	Paul Mackerras, Jiri Slaby, Andrew Morton, linuxppc-dev,
	Ingo Molnar

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/powerpc/kernel/process.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 639ceae7da9d..34b46680a196 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -2028,7 +2028,8 @@ unsigned long get_wchan(struct task_struct *p)
 
 static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
 
-void show_stack(struct task_struct *tsk, unsigned long *stack)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *stack,
+		       const char *loglvl)
 {
 	unsigned long sp, ip, lr, newsp;
 	int count = 0;
@@ -2053,7 +2054,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 	}
 
 	lr = 0;
-	printk("Call Trace:\n");
+	printk("%sCall Trace:\n", loglvl);
 	do {
 		if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
 			break;
@@ -2062,7 +2063,8 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 		newsp = stack[0];
 		ip = stack[STACK_FRAME_LR_SAVE];
 		if (!firstframe || ip != lr) {
-			printk("["REG"] ["REG"] %pS", sp, ip, (void *)ip);
+			printk("%s["REG"] ["REG"] %pS",
+				loglvl, sp, ip, (void *)ip);
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 			ret_addr = ftrace_graph_ret_addr(current,
 						&ftrace_idx, ip, stack);
@@ -2084,8 +2086,9 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 			struct pt_regs *regs = (struct pt_regs *)
 				(sp + STACK_FRAME_OVERHEAD);
 			lr = regs->link;
-			printk("--- interrupt: %lx at %pS\n    LR = %pS\n",
-			       regs->trap, (void *)regs->nip, (void *)lr);
+			printk("%s--- interrupt: %lx at %pS\n    LR = %pS\n",
+			       loglvl, regs->trap,
+			       (void *)regs->nip, (void *)lr);
 			firstframe = 1;
 		}
 
@@ -2095,6 +2098,11 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
 	put_task_stack(tsk);
 }
 
+void show_stack(struct task_struct *tsk, unsigned long *stack)
+{
+	show_stack_loglvl(tsk, stack, KERN_DEFAULT);
+}
+
 #ifdef CONFIG_PPC64
 /* Called with hard IRQs off */
 void notrace __ppc64_runlatch_on(void)
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 27/50] riscv: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Palmer Dabbelt, Paul Walmsley, linux-riscv

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: linux-riscv@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/riscv/kernel/stacktrace.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index a76892b48fff..5b414ba9848b 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -98,16 +98,23 @@ static void notrace walk_stackframe(struct task_struct *task,
 
 static bool print_trace_address(unsigned long pc, void *arg)
 {
-	print_ip_sym(KERN_DEFAULT, pc);
+	const char *loglvl = arg;
+
+	print_ip_sym(loglvl, pc);
 	return false;
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl)
 {
 	pr_cont("Call Trace:\n");
-	walk_stackframe(task, NULL, print_trace_address, NULL);
+	walk_stackframe(task, NULL, print_trace_address, (void *)loglvl);
 }
 
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
+}
 
 static bool save_wchan(unsigned long pc, void *arg)
 {
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 27/50] riscv: Add show_stack_loglvl()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Albert Ou, Dmitry Safonov, Tetsuo Handa,
	Greg Kroah-Hartman, Paul Walmsley, Dmitry Safonov,
	Steven Rostedt, Sergey Senozhatsky, linux-riscv, Palmer Dabbelt,
	Jiri Slaby, Andrew Morton, Ingo Molnar

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: linux-riscv@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/riscv/kernel/stacktrace.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index a76892b48fff..5b414ba9848b 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -98,16 +98,23 @@ static void notrace walk_stackframe(struct task_struct *task,
 
 static bool print_trace_address(unsigned long pc, void *arg)
 {
-	print_ip_sym(KERN_DEFAULT, pc);
+	const char *loglvl = arg;
+
+	print_ip_sym(loglvl, pc);
 	return false;
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl)
 {
 	pr_cont("Call Trace:\n");
-	walk_stackframe(task, NULL, print_trace_address, NULL);
+	walk_stackframe(task, NULL, print_trace_address, (void *)loglvl);
 }
 
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
+}
 
 static bool save_wchan(unsigned long pc, void *arg)
 {
-- 
2.23.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 28/50] s390: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (31 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: linux-s390@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/s390/kernel/dumpstack.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/s390/kernel/dumpstack.c b/arch/s390/kernel/dumpstack.c
index 34bdc60c0b11..1a89f0968742 100644
--- a/arch/s390/kernel/dumpstack.c
+++ b/arch/s390/kernel/dumpstack.c
@@ -123,20 +123,26 @@ int get_stack_info(unsigned long sp, struct task_struct *task,
 	return -EINVAL;
 }
 
-void show_stack(struct task_struct *task, unsigned long *stack)
+void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+		       const char *loglvl)
 {
 	struct unwind_state state;
 
-	printk("Call Trace:\n");
+	printk("%sCall Trace:\n", loglvl);
 	if (!task)
 		task = current;
 	unwind_for_each_frame(&state, task, NULL, (unsigned long) stack)
-		printk(state.reliable ? " [<%016lx>] %pSR \n" :
-					"([<%016lx>] %pSR)\n",
-		       state.ip, (void *) state.ip);
+		printk(state.reliable ? "%s [<%016lx>] %pSR \n" :
+					"%s([<%016lx>] %pSR)\n",
+		       loglvl, state.ip, (void *) state.ip);
 	debug_show_held_locks(task ? : current);
 }
 
+void show_stack(struct task_struct *task, unsigned long *stack)
+{
+	show_stack_loglvl(task, stack, KERN_DEFAULT);
+}
+
 static void show_last_breaking_event(struct pt_regs *regs)
 {
 	printk("Last Breaking-Event-Address:\n");
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 29/50] sh: Add loglvl to dump_mem()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	Yoshinori Sato, linux-sh

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to dump_mem() as a preparation to introduce
show_stack_loglvl().

Cc: Rich Felker <dalias@libc.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: linux-sh@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/include/asm/kdebug.h |  3 ++-
 arch/sh/kernel/dumpstack.c   | 17 +++++++++--------
 arch/sh/kernel/traps.c       |  4 ++--
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/sh/include/asm/kdebug.h b/arch/sh/include/asm/kdebug.h
index 5212f5fcd752..de8693fabb1d 100644
--- a/arch/sh/include/asm/kdebug.h
+++ b/arch/sh/include/asm/kdebug.h
@@ -13,6 +13,7 @@ enum die_val {
 
 /* arch/sh/kernel/dumpstack.c */
 extern void printk_address(unsigned long address, int reliable);
-extern void dump_mem(const char *str, unsigned long bottom, unsigned long top);
+extern void dump_mem(const char *str, const char *loglvl,
+		     unsigned long bottom, unsigned long top);
 
 #endif /* __ASM_SH_KDEBUG_H */
diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index 9f1c9c11d62d..6784b914fba0 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -16,30 +16,31 @@
 #include <asm/unwinder.h>
 #include <asm/stacktrace.h>
 
-void dump_mem(const char *str, unsigned long bottom, unsigned long top)
+void dump_mem(const char *str, const char *loglvl,
+	      unsigned long bottom, unsigned long top)
 {
 	unsigned long p;
 	int i;
 
-	printk("%s(0x%08lx to 0x%08lx)\n", str, bottom, top);
+	printk("%s%s(0x%08lx to 0x%08lx)\n", loglvl, str, bottom, top);
 
 	for (p = bottom & ~31; p < top; ) {
-		printk("%04lx: ", p & 0xffff);
+		printk("%s%04lx: ", loglvl,  p & 0xffff);
 
 		for (i = 0; i < 8; i++, p += 4) {
 			unsigned int val;
 
 			if (p < bottom || p >= top)
-				printk("         ");
+				printk("%s         ", loglvl);
 			else {
 				if (__get_user(val, (unsigned int __user *)p)) {
-					printk("\n");
+					printk("%s\n", loglvl);
 					return;
 				}
-				printk("%08x ", val);
+				printk("%s%08x ", loglvl, val);
 			}
 		}
-		printk("\n");
+		printk("%s\n", loglvl);
 	}
 }
 
@@ -156,7 +157,7 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
 		sp = (unsigned long *)tsk->thread.sp;
 
 	stack = (unsigned long)sp;
-	dump_mem("Stack: ", stack, THREAD_SIZE +
+	dump_mem("Stack: ", KERN_DEFAULT, stack, THREAD_SIZE +
 		 (unsigned long)task_stack_page(tsk));
 	show_trace(tsk, sp, NULL);
 }
diff --git a/arch/sh/kernel/traps.c b/arch/sh/kernel/traps.c
index 63cf17bc760d..faad65409075 100644
--- a/arch/sh/kernel/traps.c
+++ b/arch/sh/kernel/traps.c
@@ -38,8 +38,8 @@ void die(const char *str, struct pt_regs *regs, long err)
 			task_pid_nr(current), task_stack_page(current) + 1);
 
 	if (!user_mode(regs) || in_interrupt())
-		dump_mem("Stack: ", regs->regs[15], THREAD_SIZE +
-			 (unsigned long)task_stack_page(current));
+		dump_mem("Stack: ", KERN_DEFAULT, regs->regs[15],
+			THREAD_SIZE + (unsigned long)task_stack_page(current));
 
 	notify_die(DIE_OOPS, str, regs, err, 255, SIGSEGV);
 
-- 
2.23.0

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 29/50] sh: Add loglvl to dump_mem()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	Yoshinori Sato, linux-sh

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to dump_mem() as a preparation to introduce
show_stack_loglvl().

Cc: Rich Felker <dalias@libc.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: linux-sh@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/include/asm/kdebug.h |  3 ++-
 arch/sh/kernel/dumpstack.c   | 17 +++++++++--------
 arch/sh/kernel/traps.c       |  4 ++--
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/sh/include/asm/kdebug.h b/arch/sh/include/asm/kdebug.h
index 5212f5fcd752..de8693fabb1d 100644
--- a/arch/sh/include/asm/kdebug.h
+++ b/arch/sh/include/asm/kdebug.h
@@ -13,6 +13,7 @@ enum die_val {
 
 /* arch/sh/kernel/dumpstack.c */
 extern void printk_address(unsigned long address, int reliable);
-extern void dump_mem(const char *str, unsigned long bottom, unsigned long top);
+extern void dump_mem(const char *str, const char *loglvl,
+		     unsigned long bottom, unsigned long top);
 
 #endif /* __ASM_SH_KDEBUG_H */
diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index 9f1c9c11d62d..6784b914fba0 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -16,30 +16,31 @@
 #include <asm/unwinder.h>
 #include <asm/stacktrace.h>
 
-void dump_mem(const char *str, unsigned long bottom, unsigned long top)
+void dump_mem(const char *str, const char *loglvl,
+	      unsigned long bottom, unsigned long top)
 {
 	unsigned long p;
 	int i;
 
-	printk("%s(0x%08lx to 0x%08lx)\n", str, bottom, top);
+	printk("%s%s(0x%08lx to 0x%08lx)\n", loglvl, str, bottom, top);
 
 	for (p = bottom & ~31; p < top; ) {
-		printk("%04lx: ", p & 0xffff);
+		printk("%s%04lx: ", loglvl,  p & 0xffff);
 
 		for (i = 0; i < 8; i++, p += 4) {
 			unsigned int val;
 
 			if (p < bottom || p >= top)
-				printk("         ");
+				printk("%s         ", loglvl);
 			else {
 				if (__get_user(val, (unsigned int __user *)p)) {
-					printk("\n");
+					printk("%s\n", loglvl);
 					return;
 				}
-				printk("%08x ", val);
+				printk("%s%08x ", loglvl, val);
 			}
 		}
-		printk("\n");
+		printk("%s\n", loglvl);
 	}
 }
 
@@ -156,7 +157,7 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
 		sp = (unsigned long *)tsk->thread.sp;
 
 	stack = (unsigned long)sp;
-	dump_mem("Stack: ", stack, THREAD_SIZE +
+	dump_mem("Stack: ", KERN_DEFAULT, stack, THREAD_SIZE +
 		 (unsigned long)task_stack_page(tsk));
 	show_trace(tsk, sp, NULL);
 }
diff --git a/arch/sh/kernel/traps.c b/arch/sh/kernel/traps.c
index 63cf17bc760d..faad65409075 100644
--- a/arch/sh/kernel/traps.c
+++ b/arch/sh/kernel/traps.c
@@ -38,8 +38,8 @@ void die(const char *str, struct pt_regs *regs, long err)
 			task_pid_nr(current), task_stack_page(current) + 1);
 
 	if (!user_mode(regs) || in_interrupt())
-		dump_mem("Stack: ", regs->regs[15], THREAD_SIZE +
-			 (unsigned long)task_stack_page(current));
+		dump_mem("Stack: ", KERN_DEFAULT, regs->regs[15],
+			THREAD_SIZE + (unsigned long)task_stack_page(current));
 
 	notify_die(DIE_OOPS, str, regs, err, 255, SIGSEGV);
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 30/50] sh: Remove needless printk()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	Yoshinori Sato, linux-sh

Currently `data' is always an empty line "".
No need for additional printk() call.

Cc: Rich Felker <dalias@libc.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/kernel/dumpstack.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index 6784b914fba0..2c1a78e5776b 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -118,7 +118,6 @@ static int print_trace_stack(void *data, char *name)
  */
 static void print_trace_address(void *data, unsigned long addr, int reliable)
 {
-	printk("%s", (char *)data);
 	printk_address(addr, reliable);
 }
 
-- 
2.23.0

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 30/50] sh: Remove needless printk()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	Yoshinori Sato, linux-sh

Currently `data' is always an empty line "".
No need for additional printk() call.

Cc: Rich Felker <dalias@libc.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/kernel/dumpstack.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index 6784b914fba0..2c1a78e5776b 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -118,7 +118,6 @@ static int print_trace_stack(void *data, char *name)
  */
 static void print_trace_address(void *data, unsigned long addr, int reliable)
 {
-	printk("%s", (char *)data);
 	printk_address(addr, reliable);
 }
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 31/50] sh: Add loglvl to printk_address()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	linux-sh

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to printk_address() as a preparation to introduce
show_stack_loglvl().

As a good side-effect show_fault_oops() now prints the address with
KERN_EMREG as the rest of output, making sure there won't be situation
where "PC: " is printed without actual address.

Cc: Rich Felker <dalias@libc.org>
Cc: Rich Felker <dalias@libc.org>
Cc: linux-sh@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/include/asm/kdebug.h | 3 ++-
 arch/sh/kernel/dumpstack.c   | 6 +++---
 arch/sh/mm/fault.c           | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/sh/include/asm/kdebug.h b/arch/sh/include/asm/kdebug.h
index de8693fabb1d..960545306afa 100644
--- a/arch/sh/include/asm/kdebug.h
+++ b/arch/sh/include/asm/kdebug.h
@@ -12,7 +12,8 @@ enum die_val {
 };
 
 /* arch/sh/kernel/dumpstack.c */
-extern void printk_address(unsigned long address, int reliable);
+extern void printk_address(unsigned long address, int reliable,
+			   const char *loglvl);
 extern void dump_mem(const char *str, const char *loglvl,
 		     unsigned long bottom, unsigned long top);
 
diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index 2c1a78e5776b..959064b90055 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -44,9 +44,9 @@ void dump_mem(const char *str, const char *loglvl,
 	}
 }
 
-void printk_address(unsigned long address, int reliable)
+void printk_address(unsigned long address, int reliable, const char *loglvl)
 {
-	printk(" [<%p>] %s%pS\n", (void *) address,
+	printk("%s [<%p>] %s%pS\n", loglvl, (void *) address,
 			reliable ? "" : "? ", (void *) address);
 }
 
@@ -118,7 +118,7 @@ static int print_trace_stack(void *data, char *name)
  */
 static void print_trace_address(void *data, unsigned long addr, int reliable)
 {
-	printk_address(addr, reliable);
+	printk_address(addr, reliable, (char *)data);
 }
 
 static const struct stacktrace_ops print_trace_ops = {
diff --git a/arch/sh/mm/fault.c b/arch/sh/mm/fault.c
index 5f51456f4fc7..b11f0c5e65b6 100644
--- a/arch/sh/mm/fault.c
+++ b/arch/sh/mm/fault.c
@@ -196,7 +196,7 @@ show_fault_oops(struct pt_regs *regs, unsigned long address)
 
 	printk(KERN_CONT " at %08lx\n", address);
 	printk(KERN_ALERT "PC:");
-	printk_address(regs->pc, 1);
+	printk_address(regs->pc, 1, KERN_ALERT);
 
 	show_pte(NULL, address);
 }
-- 
2.23.0

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 31/50] sh: Add loglvl to printk_address()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	linux-sh

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to printk_address() as a preparation to introduce
show_stack_loglvl().

As a good side-effect show_fault_oops() now prints the address with
KERN_EMREG as the rest of output, making sure there won't be situation
where "PC: " is printed without actual address.

Cc: Rich Felker <dalias@libc.org>
Cc: Rich Felker <dalias@libc.org>
Cc: linux-sh@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/include/asm/kdebug.h | 3 ++-
 arch/sh/kernel/dumpstack.c   | 6 +++---
 arch/sh/mm/fault.c           | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/sh/include/asm/kdebug.h b/arch/sh/include/asm/kdebug.h
index de8693fabb1d..960545306afa 100644
--- a/arch/sh/include/asm/kdebug.h
+++ b/arch/sh/include/asm/kdebug.h
@@ -12,7 +12,8 @@ enum die_val {
 };
 
 /* arch/sh/kernel/dumpstack.c */
-extern void printk_address(unsigned long address, int reliable);
+extern void printk_address(unsigned long address, int reliable,
+			   const char *loglvl);
 extern void dump_mem(const char *str, const char *loglvl,
 		     unsigned long bottom, unsigned long top);
 
diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index 2c1a78e5776b..959064b90055 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -44,9 +44,9 @@ void dump_mem(const char *str, const char *loglvl,
 	}
 }
 
-void printk_address(unsigned long address, int reliable)
+void printk_address(unsigned long address, int reliable, const char *loglvl)
 {
-	printk(" [<%p>] %s%pS\n", (void *) address,
+	printk("%s [<%p>] %s%pS\n", loglvl, (void *) address,
 			reliable ? "" : "? ", (void *) address);
 }
 
@@ -118,7 +118,7 @@ static int print_trace_stack(void *data, char *name)
  */
 static void print_trace_address(void *data, unsigned long addr, int reliable)
 {
-	printk_address(addr, reliable);
+	printk_address(addr, reliable, (char *)data);
 }
 
 static const struct stacktrace_ops print_trace_ops = {
diff --git a/arch/sh/mm/fault.c b/arch/sh/mm/fault.c
index 5f51456f4fc7..b11f0c5e65b6 100644
--- a/arch/sh/mm/fault.c
+++ b/arch/sh/mm/fault.c
@@ -196,7 +196,7 @@ show_fault_oops(struct pt_regs *regs, unsigned long address)
 
 	printk(KERN_CONT " at %08lx\n", address);
 	printk(KERN_ALERT "PC:");
-	printk_address(regs->pc, 1);
+	printk_address(regs->pc, 1, KERN_ALERT);
 
 	show_pte(NULL, address);
 }
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 32/50] sh: Add loglvl to show_trace()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	linux-sh

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level parameter to show_trace() as a preparation to introduce
show_stack_loglvl().

Cc: Rich Felker <dalias@libc.org>
Cc: Rich Felker <dalias@libc.org>
Cc: linux-sh@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/include/asm/processor_32.h |  2 +-
 arch/sh/kernel/dumpstack.c         | 10 +++++-----
 arch/sh/kernel/process_32.c        |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/sh/include/asm/processor_32.h b/arch/sh/include/asm/processor_32.h
index 0e0ecc0132e3..d44409413418 100644
--- a/arch/sh/include/asm/processor_32.h
+++ b/arch/sh/include/asm/processor_32.h
@@ -171,7 +171,7 @@ static __inline__ void enable_fpu(void)
 #define thread_saved_pc(tsk)	(tsk->thread.pc)
 
 void show_trace(struct task_struct *tsk, unsigned long *sp,
-		struct pt_regs *regs);
+		struct pt_regs *regs, const char *loglvl);
 
 #ifdef CONFIG_DUMP_CODE
 void show_code(struct pt_regs *regs);
diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index 959064b90055..d488a47a1f0f 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -127,16 +127,16 @@ static const struct stacktrace_ops print_trace_ops = {
 };
 
 void show_trace(struct task_struct *tsk, unsigned long *sp,
-		struct pt_regs *regs)
+		struct pt_regs *regs, const char *loglvl)
 {
 	if (regs && user_mode(regs))
 		return;
 
-	printk("\nCall trace:\n");
+	printk("%s\nCall trace:\n", loglvl);
 
-	unwind_stack(tsk, regs, sp, &print_trace_ops, "");
+	unwind_stack(tsk, regs, sp, &print_trace_ops, (void *)loglvl);
 
-	printk("\n");
+	printk("%s\n", loglvl);
 
 	if (!tsk)
 		tsk = current;
@@ -158,5 +158,5 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
 	stack = (unsigned long)sp;
 	dump_mem("Stack: ", KERN_DEFAULT, stack, THREAD_SIZE +
 		 (unsigned long)task_stack_page(tsk));
-	show_trace(tsk, sp, NULL);
+	show_trace(tsk, sp, NULL, KERN_DEFAULT);
 }
diff --git a/arch/sh/kernel/process_32.c b/arch/sh/kernel/process_32.c
index a094633874c3..456cc8d171f7 100644
--- a/arch/sh/kernel/process_32.c
+++ b/arch/sh/kernel/process_32.c
@@ -59,7 +59,7 @@ void show_regs(struct pt_regs * regs)
 	printk("MACH: %08lx MACL: %08lx GBR : %08lx PR  : %08lx\n",
 	       regs->mach, regs->macl, regs->gbr, regs->pr);
 
-	show_trace(NULL, (unsigned long *)regs->regs[15], regs);
+	show_trace(NULL, (unsigned long *)regs->regs[15], regs, KERN_DEFAULT);
 	show_code(regs);
 }
 
-- 
2.23.0

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 32/50] sh: Add loglvl to show_trace()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	linux-sh

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level parameter to show_trace() as a preparation to introduce
show_stack_loglvl().

Cc: Rich Felker <dalias@libc.org>
Cc: Rich Felker <dalias@libc.org>
Cc: linux-sh@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/include/asm/processor_32.h |  2 +-
 arch/sh/kernel/dumpstack.c         | 10 +++++-----
 arch/sh/kernel/process_32.c        |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/sh/include/asm/processor_32.h b/arch/sh/include/asm/processor_32.h
index 0e0ecc0132e3..d44409413418 100644
--- a/arch/sh/include/asm/processor_32.h
+++ b/arch/sh/include/asm/processor_32.h
@@ -171,7 +171,7 @@ static __inline__ void enable_fpu(void)
 #define thread_saved_pc(tsk)	(tsk->thread.pc)
 
 void show_trace(struct task_struct *tsk, unsigned long *sp,
-		struct pt_regs *regs);
+		struct pt_regs *regs, const char *loglvl);
 
 #ifdef CONFIG_DUMP_CODE
 void show_code(struct pt_regs *regs);
diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index 959064b90055..d488a47a1f0f 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -127,16 +127,16 @@ static const struct stacktrace_ops print_trace_ops = {
 };
 
 void show_trace(struct task_struct *tsk, unsigned long *sp,
-		struct pt_regs *regs)
+		struct pt_regs *regs, const char *loglvl)
 {
 	if (regs && user_mode(regs))
 		return;
 
-	printk("\nCall trace:\n");
+	printk("%s\nCall trace:\n", loglvl);
 
-	unwind_stack(tsk, regs, sp, &print_trace_ops, "");
+	unwind_stack(tsk, regs, sp, &print_trace_ops, (void *)loglvl);
 
-	printk("\n");
+	printk("%s\n", loglvl);
 
 	if (!tsk)
 		tsk = current;
@@ -158,5 +158,5 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
 	stack = (unsigned long)sp;
 	dump_mem("Stack: ", KERN_DEFAULT, stack, THREAD_SIZE +
 		 (unsigned long)task_stack_page(tsk));
-	show_trace(tsk, sp, NULL);
+	show_trace(tsk, sp, NULL, KERN_DEFAULT);
 }
diff --git a/arch/sh/kernel/process_32.c b/arch/sh/kernel/process_32.c
index a094633874c3..456cc8d171f7 100644
--- a/arch/sh/kernel/process_32.c
+++ b/arch/sh/kernel/process_32.c
@@ -59,7 +59,7 @@ void show_regs(struct pt_regs * regs)
 	printk("MACH: %08lx MACL: %08lx GBR : %08lx PR  : %08lx\n",
 	       regs->mach, regs->macl, regs->gbr, regs->pr);
 
-	show_trace(NULL, (unsigned long *)regs->regs[15], regs);
+	show_trace(NULL, (unsigned long *)regs->regs[15], regs, KERN_DEFAULT);
 	show_code(regs);
 }
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 33/50] sh: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	Yoshinori Sato, linux-sh

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Rich Felker <dalias@libc.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: linux-sh@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/kernel/dumpstack.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index d488a47a1f0f..cc51e9d74667 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -144,7 +144,8 @@ void show_trace(struct task_struct *tsk, unsigned long *sp,
 	debug_show_held_locks(tsk);
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+		       const char *loglvl)
 {
 	unsigned long stack;
 
@@ -156,7 +157,12 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
 		sp = (unsigned long *)tsk->thread.sp;
 
 	stack = (unsigned long)sp;
-	dump_mem("Stack: ", KERN_DEFAULT, stack, THREAD_SIZE +
+	dump_mem("Stack: ", loglvl, stack, THREAD_SIZE +
 		 (unsigned long)task_stack_page(tsk));
-	show_trace(tsk, sp, NULL, KERN_DEFAULT);
+	show_trace(tsk, sp, NULL, loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
 }
-- 
2.23.0

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 33/50] sh: Add show_stack_loglvl()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Rich Felker,
	Yoshinori Sato, linux-sh

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Rich Felker <dalias@libc.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: linux-sh@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sh/kernel/dumpstack.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index d488a47a1f0f..cc51e9d74667 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -144,7 +144,8 @@ void show_trace(struct task_struct *tsk, unsigned long *sp,
 	debug_show_held_locks(tsk);
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+		       const char *loglvl)
 {
 	unsigned long stack;
 
@@ -156,7 +157,12 @@ void show_stack(struct task_struct *tsk, unsigned long *sp)
 		sp = (unsigned long *)tsk->thread.sp;
 
 	stack = (unsigned long)sp;
-	dump_mem("Stack: ", KERN_DEFAULT, stack, THREAD_SIZE +
+	dump_mem("Stack: ", loglvl, stack, THREAD_SIZE +
 		 (unsigned long)task_stack_page(tsk));
-	show_trace(tsk, sp, NULL, KERN_DEFAULT);
+	show_trace(tsk, sp, NULL, loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
 }
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 34/50] sparc: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	David S. Miller, sparclinux

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sparc/kernel/process_32.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/sparc/kernel/process_32.c b/arch/sparc/kernel/process_32.c
index 26cca65e9246..d2f3aea7b977 100644
--- a/arch/sparc/kernel/process_32.c
+++ b/arch/sparc/kernel/process_32.c
@@ -145,10 +145,12 @@ void show_regs(struct pt_regs *r)
 }
 
 /*
- * The show_stack is an external API which we do not use ourselves.
+ * The show_stack(), show_stack_loglvl() are external APIs which
+ * we do not use ourselves.
  * The oops is printed in die_if_kernel.
  */
-void show_stack(struct task_struct *tsk, unsigned long *_ksp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl)
 {
 	unsigned long pc, fp;
 	unsigned long task_base;
@@ -170,11 +172,16 @@ void show_stack(struct task_struct *tsk, unsigned long *_ksp)
 			break;
 		rw = (struct reg_window32 *) fp;
 		pc = rw->ins[7];
-		printk("[%08lx : ", pc);
-		printk("%pS ] ", (void *) pc);
+		printk("%s[%08lx : ", loglvl, pc);
+		printk("%s%pS ] ", loglvl, (void *) pc);
 		fp = rw->ins[6];
 	} while (++count < 16);
-	printk("\n");
+	printk("%s\n", loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
 }
 
 /*
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 34/50] sparc: Add show_stack_loglvl()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	David S. Miller, sparclinux

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/sparc/kernel/process_32.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/sparc/kernel/process_32.c b/arch/sparc/kernel/process_32.c
index 26cca65e9246..d2f3aea7b977 100644
--- a/arch/sparc/kernel/process_32.c
+++ b/arch/sparc/kernel/process_32.c
@@ -145,10 +145,12 @@ void show_regs(struct pt_regs *r)
 }
 
 /*
- * The show_stack is an external API which we do not use ourselves.
+ * The show_stack(), show_stack_loglvl() are external APIs which
+ * we do not use ourselves.
  * The oops is printed in die_if_kernel.
  */
-void show_stack(struct task_struct *tsk, unsigned long *_ksp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl)
 {
 	unsigned long pc, fp;
 	unsigned long task_base;
@@ -170,11 +172,16 @@ void show_stack(struct task_struct *tsk, unsigned long *_ksp)
 			break;
 		rw = (struct reg_window32 *) fp;
 		pc = rw->ins[7];
-		printk("[%08lx : ", pc);
-		printk("%pS ] ", (void *) pc);
+		printk("%s[%08lx : ", loglvl, pc);
+		printk("%s%pS ] ", loglvl, (void *) pc);
 		fp = rw->ins[6];
 	} while (++count < 16);
-	printk("\n");
+	printk("%s\n", loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
 }
 
 /*
-- 
2.23.0

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 35/50] um/sysrq: Remove needless variable sp
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um

`sp' is a needless excercise here.

Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: linux-um@lists.infradead.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/um/kernel/sysrq.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index c71b5ef7ea8c..c831a1c2eb94 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -27,7 +27,6 @@ static const struct stacktrace_ops stackops = {
 
 void show_stack(struct task_struct *task, unsigned long *stack)
 {
-	unsigned long *sp = stack;
 	struct pt_regs *segv_regs = current->thread.segv_regs;
 	int i;
 
@@ -38,10 +37,9 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 	}
 
 	if (!stack)
-		sp = get_stack_pointer(task, segv_regs);
+		stack = get_stack_pointer(task, segv_regs);
 
 	pr_info("Stack:\n");
-	stack = sp;
 	for (i = 0; i < 3 * STACKSLOTS_PER_LINE; i++) {
 		if (kstack_end(stack))
 			break;
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 35/50] um/sysrq: Remove needless variable sp
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Richard Weinberger, Dmitry Safonov, Tetsuo Handa,
	Greg Kroah-Hartman, Jeff Dike, Dmitry Safonov, Steven Rostedt,
	linux-um, Sergey Senozhatsky, Jiri Slaby, Andrew Morton,
	Ingo Molnar, Anton Ivanov

`sp' is a needless excercise here.

Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: linux-um@lists.infradead.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/um/kernel/sysrq.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index c71b5ef7ea8c..c831a1c2eb94 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -27,7 +27,6 @@ static const struct stacktrace_ops stackops = {
 
 void show_stack(struct task_struct *task, unsigned long *stack)
 {
-	unsigned long *sp = stack;
 	struct pt_regs *segv_regs = current->thread.segv_regs;
 	int i;
 
@@ -38,10 +37,9 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 	}
 
 	if (!stack)
-		sp = get_stack_pointer(task, segv_regs);
+		stack = get_stack_pointer(task, segv_regs);
 
 	pr_info("Stack:\n");
-	stack = sp;
 	for (i = 0; i < 3 * STACKSLOTS_PER_LINE; i++) {
 		if (kstack_end(stack))
 			break;
-- 
2.23.0


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 36/50] um: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
@ 2019-11-06  3:05   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: linux-um@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/um/kernel/sysrq.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index c831a1c2eb94..1b54b6431499 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -17,7 +17,9 @@
 
 static void _print_addr(void *data, unsigned long address, int reliable)
 {
-	pr_info(" [<%08lx>] %s%pS\n", address, reliable ? "" : "? ",
+	const char *loglvl = data;
+
+	printk("%s [<%08lx>] %s%pS\n", loglvl, address, reliable ? "" : "? ",
 		(void *)address);
 }
 
@@ -25,7 +27,8 @@ static const struct stacktrace_ops stackops = {
 	.address = _print_addr
 };
 
-void show_stack(struct task_struct *task, unsigned long *stack)
+void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+		       const char *loglvl)
 {
 	struct pt_regs *segv_regs = current->thread.segv_regs;
 	int i;
@@ -39,17 +42,22 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 	if (!stack)
 		stack = get_stack_pointer(task, segv_regs);
 
-	pr_info("Stack:\n");
+	printk("%sStack:\n", loglvl);
 	for (i = 0; i < 3 * STACKSLOTS_PER_LINE; i++) {
 		if (kstack_end(stack))
 			break;
 		if (i && ((i % STACKSLOTS_PER_LINE) == 0))
-			pr_cont("\n");
+			printk("%s\n", loglvl);
 		pr_cont(" %08lx", *stack++);
 	}
-	pr_cont("\n");
+	printk("%s\n", loglvl);
+
+	printk("%sCall Trace:\n", loglvl);
+	dump_trace(current, &stackops, (void *)loglvl);
+	printk("%s\n", loglvl);
+}
 
-	pr_info("Call Trace:\n");
-	dump_trace(current, &stackops, NULL);
-	pr_info("\n");
+void show_stack(struct task_struct *task, unsigned long *stack)
+{
+	show_stack_loglvl(task, stack, KERN_INFO);
 }
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 36/50] um: Add show_stack_loglvl()
@ 2019-11-06  3:05   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Petr Mladek, Richard Weinberger, Dmitry Safonov, Tetsuo Handa,
	Greg Kroah-Hartman, Jeff Dike, Dmitry Safonov, Steven Rostedt,
	linux-um, Sergey Senozhatsky, Jiri Slaby, Andrew Morton,
	Ingo Molnar, Anton Ivanov

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: linux-um@lists.infradead.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/um/kernel/sysrq.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index c831a1c2eb94..1b54b6431499 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -17,7 +17,9 @@
 
 static void _print_addr(void *data, unsigned long address, int reliable)
 {
-	pr_info(" [<%08lx>] %s%pS\n", address, reliable ? "" : "? ",
+	const char *loglvl = data;
+
+	printk("%s [<%08lx>] %s%pS\n", loglvl, address, reliable ? "" : "? ",
 		(void *)address);
 }
 
@@ -25,7 +27,8 @@ static const struct stacktrace_ops stackops = {
 	.address = _print_addr
 };
 
-void show_stack(struct task_struct *task, unsigned long *stack)
+void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+		       const char *loglvl)
 {
 	struct pt_regs *segv_regs = current->thread.segv_regs;
 	int i;
@@ -39,17 +42,22 @@ void show_stack(struct task_struct *task, unsigned long *stack)
 	if (!stack)
 		stack = get_stack_pointer(task, segv_regs);
 
-	pr_info("Stack:\n");
+	printk("%sStack:\n", loglvl);
 	for (i = 0; i < 3 * STACKSLOTS_PER_LINE; i++) {
 		if (kstack_end(stack))
 			break;
 		if (i && ((i % STACKSLOTS_PER_LINE) == 0))
-			pr_cont("\n");
+			printk("%s\n", loglvl);
 		pr_cont(" %08lx", *stack++);
 	}
-	pr_cont("\n");
+	printk("%s\n", loglvl);
+
+	printk("%sCall Trace:\n", loglvl);
+	dump_trace(current, &stackops, (void *)loglvl);
+	printk("%s\n", loglvl);
+}
 
-	pr_info("Call Trace:\n");
-	dump_trace(current, &stackops, NULL);
-	pr_info("\n");
+void show_stack(struct task_struct *task, unsigned long *stack)
+{
+	show_stack_loglvl(task, stack, KERN_INFO);
 }
-- 
2.23.0


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 37/50] unicore32: Remove unused pmode argument in c_backtrace()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (40 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Guan Xuetao

The pmode parameter isn't used in assembly - remove it.
Second argument will be reused for printk() log level.

Cc: Guan Xuetao <gxt@pku.edu.cn>
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/unicore32/kernel/setup.h |  2 +-
 arch/unicore32/kernel/traps.c | 14 +++++---------
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/unicore32/kernel/setup.h b/arch/unicore32/kernel/setup.h
index e40d3603c7e7..03e70e37f472 100644
--- a/arch/unicore32/kernel/setup.h
+++ b/arch/unicore32/kernel/setup.h
@@ -29,7 +29,7 @@ extern void kernel_thread_helper(void);
 extern void __init early_signal_init(void);
 
 extern asmlinkage void __backtrace(void);
-extern asmlinkage void c_backtrace(unsigned long fp, int pmode);
+extern asmlinkage void c_backtrace(unsigned long fp);
 
 extern void __show_regs(struct pt_regs *);
 
diff --git a/arch/unicore32/kernel/traps.c b/arch/unicore32/kernel/traps.c
index e24f67283864..3682a4c5d927 100644
--- a/arch/unicore32/kernel/traps.c
+++ b/arch/unicore32/kernel/traps.c
@@ -137,7 +137,7 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
 
 static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 {
-	unsigned int fp, mode;
+	unsigned int fp;
 	int ok = 1;
 
 	printk(KERN_DEFAULT "Backtrace: ");
@@ -145,16 +145,12 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 	if (!tsk)
 		tsk = current;
 
-	if (regs) {
+	if (regs)
 		fp = regs->UCreg_fp;
-		mode = processor_mode(regs);
-	} else if (tsk != current) {
+	else if (tsk != current)
 		fp = thread_saved_fp(tsk);
-		mode = 0x10;
-	} else {
+	else
 		asm("mov %0, fp" : "=r" (fp) : : "cc");
-		mode = 0x10;
-	}
 
 	if (!fp) {
 		printk("no frame pointer");
@@ -167,7 +163,7 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 	printk("\n");
 
 	if (ok)
-		c_backtrace(fp, mode);
+		c_backtrace(fp);
 }
 
 void show_stack(struct task_struct *tsk, unsigned long *sp)
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 38/50] unicore32: Add loglvl to c_backtrace()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (41 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Guan Xuetao

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level parameter to c_backtrace() as a preparation for
introducing show_stack_loglvl()

Cc: Guan Xuetao <gxt@pku.edu.cn>
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/unicore32/kernel/setup.h  |  2 +-
 arch/unicore32/kernel/traps.c  |  2 +-
 arch/unicore32/lib/backtrace.S | 24 ++++++++++++++++--------
 3 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/arch/unicore32/kernel/setup.h b/arch/unicore32/kernel/setup.h
index 03e70e37f472..967352323185 100644
--- a/arch/unicore32/kernel/setup.h
+++ b/arch/unicore32/kernel/setup.h
@@ -29,7 +29,7 @@ extern void kernel_thread_helper(void);
 extern void __init early_signal_init(void);
 
 extern asmlinkage void __backtrace(void);
-extern asmlinkage void c_backtrace(unsigned long fp);
+extern asmlinkage void c_backtrace(unsigned long fp, const char *loglvl);
 
 extern void __show_regs(struct pt_regs *);
 
diff --git a/arch/unicore32/kernel/traps.c b/arch/unicore32/kernel/traps.c
index 3682a4c5d927..2b7d73456865 100644
--- a/arch/unicore32/kernel/traps.c
+++ b/arch/unicore32/kernel/traps.c
@@ -163,7 +163,7 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 	printk("\n");
 
 	if (ok)
-		c_backtrace(fp);
+		c_backtrace(fp, KERN_DEFAULT);
 }
 
 void show_stack(struct task_struct *tsk, unsigned long *sp)
diff --git a/arch/unicore32/lib/backtrace.S b/arch/unicore32/lib/backtrace.S
index f303671e2a4e..6221944b81f3 100644
--- a/arch/unicore32/lib/backtrace.S
+++ b/arch/unicore32/lib/backtrace.S
@@ -16,6 +16,7 @@
 #define sv_fp	v5
 #define sv_pc	v6
 #define offset	v8
+#define loglvl	v9
 
 ENTRY(__backtrace)
 		mov	r0, fp
@@ -27,10 +28,11 @@ ENTRY(c_backtrace)
 ENDPROC(__backtrace)
 ENDPROC(c_backtrace)
 #else
-		stm.w	(v4 - v8, lr), [sp-]	@ Save an extra register
+		stm.w	(v4 - v10, lr), [sp-]	@ Save an extra register
 						@ so we have a location...
 		mov.a	frame, r0		@ if frame pointer is zero
 		beq	no_frame		@ we have no stack frames
+		mov	loglvl, r1
 
 1:		stm.w	(pc), [sp-]		@ calculate offset of PC stored
 		ldw.w	r0, [sp]+, #4		@ by stmfd for this CPU
@@ -95,9 +97,10 @@ for_each_frame:
 		bua	for_each_frame
 
 1006:		adr	r0, .Lbad
-		mov	r1, frame
+		mov	r1, loglvl
+		mov	r2, frame
 		b.l	printk
-no_frame:	ldm.w	(v4 - v8, pc), [sp]+
+no_frame:	ldm.w	(v4 - v10, pc), [sp]+
 ENDPROC(__backtrace)
 ENDPROC(c_backtrace)
 
@@ -128,8 +131,11 @@ ENDPROC(c_backtrace)
 		add	v7, v7, #1
 		cxor.a	v7, #6
 		cmoveq	v7, #1
-		cmoveq	r1, #'\n'
-		cmovne	r1, #' '
+		bne	201f
+		adr	r0, .Lcr
+		mov	r1, loglvl
+		b.l	printk
+201:
 		ldw.w	r3, [stack]+, #-4
 		mov	r2, reg
 		csub.a	r2, #8
@@ -141,18 +147,20 @@ ENDPROC(c_backtrace)
 		add	r2, r2, #0x10		@ so r2 need add 16
 201:
 		adr	r0, .Lfp
+		mov	r1, loglvl
 		b.l	printk
 2:		sub.a	reg, reg, #1
 		bns	1b
 		cxor.a	v7, #0
 		beq	201f
 		adr	r0, .Lcr
+		mov	r1, loglvl
 		b.l	printk
 201:		ldm.w	(instr, reg, stack, v7, pc), [sp]+
 
-.Lfp:		.asciz	"%cr%d:%08x"
-.Lcr:		.asciz	"\n"
-.Lbad:		.asciz	"Backtrace aborted due to bad frame pointer <%p>\n"
+.Lfp:		.asciz	"%sr%d:%08x "
+.Lcr:		.asciz	"%s\n"
+.Lbad:		.asciz	"%sBacktrace aborted due to bad frame pointer <%p>\n"
 		.align
 .Ldsi:		.word	0x92eec000 >> 14	@ stm.w sp, (... fp, ip, lr, pc)
 		.word	0x92e10000 >> 14	@ stm.w sp, ()
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 39/50] unicore32: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (42 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Guan Xuetao

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

As a nice side-effect - print backtrace in __die() with the same log
level as the rest of function.

Cc: Guan Xuetao <gxt@pku.edu.cn>
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/unicore32/kernel/traps.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/unicore32/kernel/traps.c b/arch/unicore32/kernel/traps.c
index 2b7d73456865..8b1335997f50 100644
--- a/arch/unicore32/kernel/traps.c
+++ b/arch/unicore32/kernel/traps.c
@@ -135,12 +135,13 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
 	set_fs(fs);
 }
 
-static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
+static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
+			   const char *loglvl)
 {
 	unsigned int fp;
 	int ok = 1;
 
-	printk(KERN_DEFAULT "Backtrace: ");
+	printk("%sBacktrace: ", loglvl);
 
 	if (!tsk)
 		tsk = current;
@@ -153,25 +154,31 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 		asm("mov %0, fp" : "=r" (fp) : : "cc");
 
 	if (!fp) {
-		printk("no frame pointer");
+		printk("%sno frame pointer", loglvl);
 		ok = 0;
 	} else if (verify_stack(fp)) {
-		printk("invalid frame pointer 0x%08x", fp);
+		printk("%sinvalid frame pointer 0x%08x", loglvl, fp);
 		ok = 0;
 	} else if (fp < (unsigned long)end_of_stack(tsk))
-		printk("frame pointer underflow");
-	printk("\n");
+		printk("%sframe pointer underflow", loglvl);
+	printk("%s\n", loglvl);
 
 	if (ok)
-		c_backtrace(fp, KERN_DEFAULT);
+		c_backtrace(fp, loglvl);
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+		       const char *loglvl)
 {
-	dump_backtrace(NULL, tsk);
+	dump_backtrace(NULL, tsk, loglvl);
 	barrier();
 }
 
+void show_stack(struct task_struct *tsk, unsigned long *sp)
+{
+	show_stack_loglvl(tsk, sp, KERN_DEFAULT)
+}
+
 static int __die(const char *str, int err, struct thread_info *thread,
 		struct pt_regs *regs)
 {
@@ -196,7 +203,7 @@ static int __die(const char *str, int err, struct thread_info *thread,
 	if (!user_mode(regs) || in_interrupt()) {
 		dump_mem(KERN_EMERG, "Stack: ", regs->UCreg_sp,
 			 THREAD_SIZE + (unsigned long)task_stack_page(tsk));
-		dump_backtrace(regs, tsk);
+		dump_backtrace(regs, tsk, KERN_EMERG);
 		dump_instr(KERN_EMERG, regs);
 	}
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 40/50] x86: Add missing const qualifiers for log_lvl
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (43 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Borislav Petkov, H. Peter Anvin, Ingo Molnar, Thomas Gleixner,
	x86

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Keep log_lvl const show_trace_log_lvl() and printk_stack_address()
as the new generic show_stack_loglvl() wants to have a proper const
qualifier.

And gcc rightfully produces warnings in case it's not keept:
arch/x86/kernel/dumpstack.c: In function ‘show_stack’:
arch/x86/kernel/dumpstack.c:294:37: warning: passing argument 4 of ‘show_trace_log_lv ’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
  294 |  show_trace_log_lvl(task, NULL, sp, loglvl);
      |                                     ^~~~~~
arch/x86/kernel/dumpstack.c:163:32: note: expected ‘char *’ but argument is of type ‘const char *’
  163 |    unsigned long *stack, char *log_lvl)
      |                          ~~~~~~^~~~~~~

Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/x86/include/asm/stacktrace.h | 2 +-
 arch/x86/kernel/dumpstack.c       | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/stacktrace.h b/arch/x86/include/asm/stacktrace.h
index 14db05086bbf..5ae5a68e469d 100644
--- a/arch/x86/include/asm/stacktrace.h
+++ b/arch/x86/include/asm/stacktrace.h
@@ -87,7 +87,7 @@ get_stack_pointer(struct task_struct *task, struct pt_regs *regs)
 }
 
 void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs,
-			unsigned long *stack, char *log_lvl);
+			unsigned long *stack, const char *log_lvl);
 
 /* The form of the top of the frame on the stack */
 struct stack_frame {
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index e07424e19274..147a06ee4a48 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -65,7 +65,7 @@ bool in_entry_stack(unsigned long *stack, struct stack_info *info)
 }
 
 static void printk_stack_address(unsigned long address, int reliable,
-				 char *log_lvl)
+				 const char *log_lvl)
 {
 	touch_nmi_watchdog();
 	printk("%s %s%pB\n", log_lvl, reliable ? "" : "? ", (void *)address);
@@ -160,7 +160,7 @@ static void show_regs_if_on_stack(struct stack_info *info, struct pt_regs *regs,
 }
 
 void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs,
-			unsigned long *stack, char *log_lvl)
+			unsigned long *stack, const char *log_lvl)
 {
 	struct unwind_state state;
 	struct stack_info stack_info = {0};
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 41/50] x86: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (44 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Borislav Petkov, H. Peter Anvin, Ingo Molnar, Thomas Gleixner,
	x86

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/x86/kernel/dumpstack.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 147a06ee4a48..940cd4c27b17 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -279,7 +279,8 @@ void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs,
 	}
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl)
 {
 	task = task ? : current;
 
@@ -290,7 +291,12 @@ void show_stack(struct task_struct *task, unsigned long *sp)
 	if (!sp && task == current)
 		sp = get_stack_pointer(current, NULL);
 
-	show_trace_log_lvl(task, NULL, sp, KERN_DEFAULT);
+	show_trace_log_lvl(task, NULL, sp, loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_DEFAULT);
 }
 
 void show_stack_regs(struct pt_regs *regs)
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 42/50] xtensa: Add loglvl to show_trace()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (45 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Chris Zankel,
	Max Filippov, linux-xtensa

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Add log level argument to show_trace() as a preparation for introducing
show_stack_loglvl().

Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: linux-xtensa@linux-xtensa.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/xtensa/kernel/traps.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/xtensa/kernel/traps.c b/arch/xtensa/kernel/traps.c
index 4a6c495ce9b6..cbc0d673f542 100644
--- a/arch/xtensa/kernel/traps.c
+++ b/arch/xtensa/kernel/traps.c
@@ -479,20 +479,24 @@ void show_regs(struct pt_regs * regs)
 
 static int show_trace_cb(struct stackframe *frame, void *data)
 {
+	const char *loglvl = data;
+
 	if (kernel_text_address(frame->pc))
-		pr_cont(" [<%08lx>] %pB\n", frame->pc, (void *)frame->pc);
+		printk("%s [<%08lx>] %pB\n",
+			loglvl, frame->pc, (void *)frame->pc);
 	return 0;
 }
 
-void show_trace(struct task_struct *task, unsigned long *sp)
+static void show_trace(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl)
 {
 	if (!sp)
 		sp = stack_pointer(task);
 
-	pr_info("Call Trace:\n");
-	walk_stackframe(sp, show_trace_cb, NULL);
+	printk("%sCall Trace:\n", loglvl);
+	walk_stackframe(sp, show_trace_cb, (void *)loglvl);
 #ifndef CONFIG_KALLSYMS
-	pr_cont("\n");
+	printk("%s\n", loglvl);
 #endif
 }
 
@@ -516,7 +520,7 @@ void show_stack(struct task_struct *task, unsigned long *sp)
 		if (i % 8 == 7)
 			pr_cont("\n");
 	}
-	show_trace(task, stack);
+	show_trace(task, stack, KERN_INFO);
 }
 
 DEFINE_SPINLOCK(die_lock);
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 43/50] xtensa: Add show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (46 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  2019-11-06  4:13   ` Max Filippov
  -1 siblings, 1 reply; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Chris Zankel,
	Max Filippov, linux-xtensa

Currently, the log-level of show_stack() depends on a platform
realization. It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on
a platform or user).

Furthermore, it forces the logic decision from user to an architecture
side. In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.
And in result it not only may print unwanted messages from other CPUs,
but also omit printing at all in the unlucky case where the printk()
was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
an easier approach than introducing more printk buffers.
Also, it will consolidate printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: linux-xtensa@linux-xtensa.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/xtensa/kernel/traps.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/xtensa/kernel/traps.c b/arch/xtensa/kernel/traps.c
index cbc0d673f542..ba6c150095c6 100644
--- a/arch/xtensa/kernel/traps.c
+++ b/arch/xtensa/kernel/traps.c
@@ -502,7 +502,8 @@ static void show_trace(struct task_struct *task, unsigned long *sp,
 
 static int kstack_depth_to_print = 24;
 
-void show_stack(struct task_struct *task, unsigned long *sp)
+void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl)
 {
 	int i = 0;
 	unsigned long *stack;
@@ -511,16 +512,21 @@ void show_stack(struct task_struct *task, unsigned long *sp)
 		sp = stack_pointer(task);
 	stack = sp;
 
-	pr_info("Stack:\n");
+	printk("%sStack:\n", loglvl);
 
 	for (i = 0; i < kstack_depth_to_print; i++) {
 		if (kstack_end(sp))
 			break;
-		pr_cont(" %08lx", *sp++);
+		printk("%s %08lx", loglvl, *sp++);
 		if (i % 8 == 7)
-			pr_cont("\n");
+			printk("%s\n", loglvl);
 	}
-	show_trace(task, stack, KERN_INFO);
+	show_trace(task, stack, loglvl);
+}
+
+void show_stack(struct task_struct *task, unsigned long *sp)
+{
+	show_stack_loglvl(task, sp, KERN_INFO);
 }
 
 DEFINE_SPINLOCK(die_lock);
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 44/50] sysrq: Use show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (47 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa

Show the stack trace on a CPU with the same log level as "CPU%d" header.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.com>
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 drivers/tty/sysrq.c         | 2 +-
 include/linux/sched/debug.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 573b2055173c..fc5f84fa5347 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -220,7 +220,7 @@ static void showacpu(void *dummy)
 
 	raw_spin_lock_irqsave(&show_lock, flags);
 	pr_info("CPU%d:\n", smp_processor_id());
-	show_stack(NULL, NULL);
+	show_stack_loglvl(NULL, NULL, KERN_INFO);
 	raw_spin_unlock_irqrestore(&show_lock, flags);
 }
 
diff --git a/include/linux/sched/debug.h b/include/linux/sched/debug.h
index 95fb9e025247..373e4e3faf2a 100644
--- a/include/linux/sched/debug.h
+++ b/include/linux/sched/debug.h
@@ -31,6 +31,8 @@ extern void show_regs(struct pt_regs *);
  * trace (or NULL if the entire call-chain of the task should be shown).
  */
 extern void show_stack(struct task_struct *task, unsigned long *sp);
+extern void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+			      const char *loglvl);
 
 extern void sched_show_task(struct task_struct *p);
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 45/50] x86/amd_gart: Print stacktrace for a leak with KERN_ERR
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (48 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Borislav Petkov, H. Peter Anvin, Ingo Molnar, Thomas Gleixner,
	x86

It's under CONFIG_IOMMU_LEAK option which is enabled by debug config.
Likely the backtrace is worth to be seen - so aligning with log level of
error message in iommu_full().

Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/x86/kernel/amd_gart_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index a6ac3712db8b..033503f394f7 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -159,7 +159,7 @@ static void dump_leak(void)
 		return;
 	dump = 1;
 
-	show_stack(NULL, NULL);
+	show_stack_loglvl(NULL, NULL, KERN_ERR);
 	debug_dma_dump_mappings(NULL);
 }
 #endif
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 46/50] power: Use show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (49 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Len Brown,
	Pavel Machek, Rafael J. Wysocki, linux-pm

Aligning with other watchdog messages just before panic - use
KERN_EMERG.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 drivers/base/power/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 134a8af51511..3f39c9524c4d 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -487,7 +487,7 @@ static void dpm_watchdog_handler(struct timer_list *t)
 	struct dpm_watchdog *wd = from_timer(wd, t, timer);
 
 	dev_emerg(wd->dev, "**** DPM device timeout ****\n");
-	show_stack(wd->tsk, NULL);
+	show_stack_loglvl(wd->tsk, NULL, KERN_EMERG);
 	panic("%s %s: unrecoverable failure\n",
 		dev_driver_string(wd->dev), dev_name(wd->dev));
 }
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 47/50] kdb: Don't play with console_loglevel
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (50 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

Print the stack trace with KERN_EMERG - it should be always visible.

Playing with console_loglevel is a bad idea as there may be more
messages printed than wanted. Also the stack trace might be not printed
at all if printk() was deferred and console_loglevel was raised back
before the trace got flushed.

Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: kgdb-bugreport@lists.sourceforge.net
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 kernel/debug/kdb/kdb_bt.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/debug/kdb/kdb_bt.c
index 7e2379aa0a1e..5ce1fe082a38 100644
--- a/kernel/debug/kdb/kdb_bt.c
+++ b/kernel/debug/kdb/kdb_bt.c
@@ -21,22 +21,19 @@
 
 static void kdb_show_stack(struct task_struct *p, void *addr)
 {
-	int old_lvl = console_loglevel;
-	console_loglevel = CONSOLE_LOGLEVEL_MOTORMOUTH;
 	kdb_trap_printk++;
 	kdb_set_current_task(p);
 	if (addr) {
-		show_stack((struct task_struct *)p, addr);
+		show_stack_loglvl(p, addr, KERN_EMERG);
 	} else if (kdb_current_regs) {
 #ifdef CONFIG_X86
-		show_stack(p, &kdb_current_regs->sp);
+		show_stack_loglvl(p, &kdb_current_regs->sp, KERN_EMERG);
 #else
-		show_stack(p, NULL);
+		show_stack_loglvl(p, NULL, KERN_EMERG);
 #endif
 	} else {
-		show_stack(p, NULL);
+		show_stack_loglvl(p, NULL, KERN_EMERG);
 	}
-	console_loglevel = old_lvl;
 	kdb_trap_printk--;
 }
 
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 48/50] sched: Print stack trace with KERN_INFO
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (51 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Ben Segall,
	Dietmar Eggemann, Ingo Molnar, Juri Lelli, Mel Gorman,
	Peter Zijlstra, Vincent Guittot

Aligning with other messages printed in sched_show_task() - use
KERN_INFO to print the backtrace.

Cc: Ben Segall <bsegall@google.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 kernel/sched/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 774ff0d8dfe9..eb50c70e73ea 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5932,7 +5932,7 @@ void sched_show_task(struct task_struct *p)
 		(unsigned long)task_thread_info(p)->flags);
 
 	print_worker_info(KERN_INFO, p);
-	show_stack(p, NULL);
+	show_stack_loglvl(p, NULL, KERN_INFO);
 	put_task_stack(p);
 }
 EXPORT_SYMBOL_GPL(sched_show_task);
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 49/50] kernel: Use show_stack_loglvl()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (52 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Ingo Molnar,
	Peter Zijlstra, Will Deacon

Align the last users of show_stack() by KERN_DEFAULT as the surrounding
headers/messages.

Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 kernel/locking/rtmutex-debug.c | 2 +-
 lib/dump_stack.c               | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/rtmutex-debug.c b/kernel/locking/rtmutex-debug.c
index fd4fe1f5b458..5e63d6e8a223 100644
--- a/kernel/locking/rtmutex-debug.c
+++ b/kernel/locking/rtmutex-debug.c
@@ -125,7 +125,7 @@ void debug_rt_mutex_print_deadlock(struct rt_mutex_waiter *waiter)
 
 	printk("\n%s/%d's [blocked] stackdump:\n\n",
 		task->comm, task_pid_nr(task));
-	show_stack(task, NULL);
+	show_stack_loglvl(task, NULL, KERN_DEFAULT);
 	printk("\n%s/%d's [current] stackdump:\n\n",
 		current->comm, task_pid_nr(current));
 	dump_stack();
diff --git a/lib/dump_stack.c b/lib/dump_stack.c
index 5cff72f18c4a..efb8e651709d 100644
--- a/lib/dump_stack.c
+++ b/lib/dump_stack.c
@@ -74,7 +74,7 @@ void show_regs_print_info(const char *log_lvl)
 static void __dump_stack(void)
 {
 	dump_stack_print_info(KERN_DEFAULT);
-	show_stack(NULL, NULL);
+	show_stack_loglvl(NULL, NULL, KERN_DEFAULT);
 }
 
 /**
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* [PATCH 50/50] kernel: Rename show_stack_loglvl() => show_stack()
  2019-11-06  3:04 ` Dmitry Safonov
                   ` (53 preceding siblings ...)
  (?)
@ 2019-11-06  3:05 ` Dmitry Safonov
  2019-11-08 10:08     ` kbuild test robot
  -1 siblings, 1 reply; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06  3:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa

Now the last users of show_stack() got converted to use an explicit log
level, show_stack_loglvl() can drop it's redundant suffix and become
once again well known show_stack().

Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 arch/alpha/kernel/traps.c        |  8 +-------
 arch/arc/kernel/stacktrace.c     |  8 +-------
 arch/arm/kernel/traps.c          |  8 +-------
 arch/arm64/kernel/traps.c        |  8 +-------
 arch/c6x/kernel/traps.c          |  7 +------
 arch/csky/kernel/dumpstack.c     |  7 +------
 arch/csky/kernel/ptrace.c        |  4 ++--
 arch/h8300/kernel/traps.c        |  8 +-------
 arch/hexagon/kernel/traps.c      |  8 +-------
 arch/ia64/kernel/mca.c           |  2 +-
 arch/ia64/kernel/process.c       | 11 ++---------
 arch/m68k/kernel/traps.c         | 11 +++--------
 arch/microblaze/kernel/traps.c   |  8 +-------
 arch/mips/kernel/traps.c         |  8 +-------
 arch/nds32/kernel/traps.c        |  8 +-------
 arch/nios2/kernel/traps.c        | 12 +++---------
 arch/openrisc/kernel/traps.c     | 10 ++--------
 arch/parisc/kernel/traps.c       |  8 +-------
 arch/powerpc/kernel/process.c    | 11 +++--------
 arch/powerpc/kernel/stacktrace.c |  2 +-
 arch/riscv/kernel/stacktrace.c   |  8 +-------
 arch/s390/kernel/dumpstack.c     |  7 +------
 arch/sh/kernel/dumpstack.c       |  8 +-------
 arch/sh/kernel/process_64.c      |  3 +--
 arch/sparc/kernel/process_32.c   | 11 ++---------
 arch/sparc/kernel/process_64.c   |  2 +-
 arch/um/drivers/mconsole_kern.c  |  2 +-
 arch/um/kernel/sysrq.c           |  7 +------
 arch/unicore32/kernel/traps.c    |  7 +------
 arch/x86/kernel/amd_gart_64.c    |  2 +-
 arch/x86/kernel/dumpstack.c      |  7 +------
 arch/xtensa/kernel/traps.c       | 10 ++--------
 drivers/base/power/main.c        |  2 +-
 drivers/tty/sysrq.c              |  2 +-
 include/linux/sched/debug.h      |  5 ++---
 kernel/debug/kdb/kdb_bt.c        |  8 ++++----
 kernel/locking/rtmutex-debug.c   |  2 +-
 kernel/sched/core.c              |  2 +-
 lib/dump_stack.c                 |  2 +-
 39 files changed, 54 insertions(+), 200 deletions(-)

diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index 2402f1777f54..8383ccfaccdc 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -144,8 +144,7 @@ dik_show_trace(unsigned long *sp, const char *loglvl)
 
 static int kstack_depth_to_print = 24;
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
-			const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *sp, const char *loglvl)
 {
 	unsigned long *stack;
 	int i;
@@ -174,11 +173,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
 	dik_show_trace(sp, loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
-{
-	show_stack_loglvl(task, sp, KERN_DEFAULT);
-}
-
 void
 die_if_kernel(char * str, struct pt_regs *regs, long err, unsigned long *r9_15)
 {
diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index 24f9cd8a12c9..feba91c9d969 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -228,17 +228,11 @@ noinline void show_stacktrace(struct task_struct *tsk, struct pt_regs *regs,
 EXPORT_SYMBOL(show_stacktrace);
 
 /* Expected by sched Code */
-void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
-			const char *loglvl)
+void show_stack(struct task_struct *tsk, unsigned long *sp, const char *loglvl)
 {
 	show_stacktrace(tsk, NULL, loglvl);
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
-{
-	show_stack_loglvl(tsk, sp, KERN_DEFAULT);
-}
-
 /* Another API expected by schedular, shows up in "ps" as Wait Channel
  * Of course just returning schedule( ) would be pointless so unwind until
  * the function is not in schedular code
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index f999a0e4bab8..02e9e297bf92 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -246,18 +246,12 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 }
 #endif
 
-void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *tsk, unsigned long *sp, const char *loglvl)
 {
 	dump_backtrace(NULL, tsk, loglvl);
 	barrier();
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
-{
-	show_stack_loglvl(tsk, sp, KERN_DEFAULT);
-}
-
 #ifdef CONFIG_PREEMPT
 #define S_PREEMPT " PREEMPT"
 #else
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5b3ae8ed33fd..b1d437ec93d2 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -136,18 +136,12 @@ void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 	put_task_stack(tsk);
 }
 
-void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *tsk, unsigned long *sp, const char *loglvl)
 {
 	dump_backtrace(NULL, tsk, loglvl);
 	barrier();
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
-{
-	show_stack_loglvl(tsk, sp, KERN_DEFAULT);
-}
-
 #ifdef CONFIG_PREEMPT
 #define S_PREEMPT " PREEMPT"
 #else
diff --git a/arch/c6x/kernel/traps.c b/arch/c6x/kernel/traps.c
index 07704670236b..33ac8c76c17f 100644
--- a/arch/c6x/kernel/traps.c
+++ b/arch/c6x/kernel/traps.c
@@ -374,7 +374,7 @@ static void show_trace(unsigned long *stack, unsigned long *endstack,
 	printk("%s\n", loglvl);
 }
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+void show_stack(struct task_struct *task, unsigned long *stack,
 		const char *loglvl)
 {
 	unsigned long *p, *endstack;
@@ -403,11 +403,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
 	show_trace(stack, endstack, loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *stack)
-{
-	show_stack_loglvl(task, stack, KERN_DEBUG);
-}
-
 int is_valid_bugaddr(unsigned long addr)
 {
 	return __kernel_text_address(addr);
diff --git a/arch/csky/kernel/dumpstack.c b/arch/csky/kernel/dumpstack.c
index c500837390d3..b9660b1944a1 100644
--- a/arch/csky/kernel/dumpstack.c
+++ b/arch/csky/kernel/dumpstack.c
@@ -32,7 +32,7 @@ static void show_trace(unsigned long *stack, const char *loglvl)
 	pr_cont("\n");
 }
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+void show_stack(struct task_struct *task, unsigned long *stack,
 		const char *loglvl)
 {
 	if (!stack) {
@@ -48,8 +48,3 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
 
 	show_trace(stack, loglvl);
 }
-
-void show_stack(struct task_struct *task, unsigned long *stack)
-{
-	show_stack_loglvl(task, stack, KERN_INFO);
-}
diff --git a/arch/csky/kernel/ptrace.c b/arch/csky/kernel/ptrace.c
index 313623a19ecb..7fa7202e025f 100644
--- a/arch/csky/kernel/ptrace.c
+++ b/arch/csky/kernel/ptrace.c
@@ -235,7 +235,7 @@ asmlinkage void syscall_trace_exit(struct pt_regs *regs)
 		trace_sys_exit(regs, syscall_get_return_value(current, regs));
 }
 
-extern void show_stack(struct task_struct *task, unsigned long *stack);
+extern void show_stack(struct task_struct *task, unsigned long *stack, const char *loglvl);
 void show_regs(struct pt_regs *fp)
 {
 	unsigned long   *sp;
@@ -311,6 +311,6 @@ void show_regs(struct pt_regs *fp)
 	}
 	pr_cont("\n");
 
-	show_stack(NULL, (unsigned long *)fp->regs[4]);
+	show_stack(NULL, (unsigned long *)fp->regs[4], KERN_INFO);
 	return;
 }
diff --git a/arch/h8300/kernel/traps.c b/arch/h8300/kernel/traps.c
index 6362446563d6..5d8b969cd8f3 100644
--- a/arch/h8300/kernel/traps.c
+++ b/arch/h8300/kernel/traps.c
@@ -115,8 +115,7 @@ void die(const char *str, struct pt_regs *fp, unsigned long err)
 
 static int kstack_depth_to_print = 24;
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *esp,
-		       const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *esp, const char *loglvl)
 {
 	unsigned long *stack,  addr;
 	int i;
@@ -158,8 +157,3 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *esp,
 	}
 	printk("%s\n", loglvl);
 }
-
-void show_stack(struct task_struct *task, unsigned long *esp)
-{
-	show_stack_loglvl(task, esp, KERN_INFO);
-}
diff --git a/arch/hexagon/kernel/traps.c b/arch/hexagon/kernel/traps.c
index a8a3a210d781..904134b37232 100644
--- a/arch/hexagon/kernel/traps.c
+++ b/arch/hexagon/kernel/traps.c
@@ -175,18 +175,12 @@ static void do_show_stack(struct task_struct *task, unsigned long *fp,
 	}
 }
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *fp,
-		       const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *fp, const char *loglvl)
 {
 	/* Saved link reg is one word above FP */
 	do_show_stack(task, fp, 0, loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *fp)
-{
-	show_stack_loglvl(task, fp, 0, KERN_INFO);
-}
-
 int die(const char *str, struct pt_regs *regs, long err)
 {
 	static struct {
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index bf2cb9294795..1d4b8f619fd2 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -1630,7 +1630,7 @@ default_monarch_init_process(struct notifier_block *self, unsigned long val, voi
 	if (read_trylock(&tasklist_lock)) {
 		do_each_thread (g, t) {
 			printk("\nBacktrace of pid %d (%s)\n", t->pid, t->comm);
-			show_stack(t, NULL);
+			show_stack(t, NULL, KERN_DEFAULT);
 		} while_each_thread (g, t);
 		read_unlock(&tasklist_lock);
 	}
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index b0eeb19bdd8d..aaabf515cef5 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -85,8 +85,7 @@ ia64_do_show_stack (struct unw_frame_info *info, void *arg)
 }
 
 void
-show_stack_loglvl (struct task_struct *task, unsigned long *sp,
-		   const char *loglvl)
+show_stack (struct task_struct *task, unsigned long *sp, const char *loglvl)
 {
 	if (!task)
 		unw_init_running(ia64_do_show_stack, (void *)loglvl);
@@ -98,12 +97,6 @@ show_stack_loglvl (struct task_struct *task, unsigned long *sp,
 	}
 }
 
-void
-show_stack (struct task_struct *task, unsigned long *sp)
-{
-	show_stack_loglvl(task, sp, KERN_DEFAULT);
-}
-
 void
 show_regs (struct pt_regs *regs)
 {
@@ -158,7 +151,7 @@ show_regs (struct pt_regs *regs)
 			       ((i == sof - 1) || (i % 3) == 2) ? "\n" : " ");
 		}
 	} else
-		show_stack(NULL, NULL);
+		show_stack(NULL, NULL, KERN_DEFAULT);
 }
 
 /* local support for deprecated console_print */
diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index ffcc5ec4fac3..df6fc782754f 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -916,7 +916,7 @@ void show_registers(struct pt_regs *regs)
 	default:
 		pr_cont("\n");
 	}
-	show_stack(NULL, (unsigned long *)addr);
+	show_stack(NULL, (unsigned long *)addr, KERN_INFO);
 
 	pr_info("Code:");
 	set_fs(KERNEL_DS);
@@ -935,8 +935,8 @@ void show_registers(struct pt_regs *regs)
 	pr_cont("\n");
 }
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
-		       const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *stack,
+		const char *loglvl)
 {
 	unsigned long *p;
 	unsigned long *endstack;
@@ -963,11 +963,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
 	show_trace(stack, loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *stack)
-{
-	show_stack_loglvl(task, stack, KERN_INFO);
-}
-
 /*
  * The vector number returned in the frame pointer may also contain
  * the "fs" (Fault Status) bits on ColdFire. These are in the bottom
diff --git a/arch/microblaze/kernel/traps.c b/arch/microblaze/kernel/traps.c
index 149ae534937e..94b6fe93147d 100644
--- a/arch/microblaze/kernel/traps.c
+++ b/arch/microblaze/kernel/traps.c
@@ -31,8 +31,7 @@ static int __init kstack_setup(char *s)
 }
 __setup("kstack=", kstack_setup);
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *sp, const char *loglvl)
 {
 	unsigned long words_to_show;
 	u32 fp = (u32) sp;
@@ -77,8 +76,3 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
 
 	debug_show_held_locks(task);
 }
-
-void show_stack(struct task_struct *task, unsigned long *sp)
-{
-	show_stack_loglvl(task, sp, KERN_INFO);
-}
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 11cdb16311e1..ece76ed129b3 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -196,8 +196,7 @@ static void show_stacktrace(struct task_struct *task,
 	show_backtrace(task, regs, loglvl);
 }
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *sp, const char *loglvl)
 {
 	struct pt_regs regs;
 	mm_segment_t old_fs = get_fs();
@@ -230,11 +229,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
 	set_fs(old_fs);
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
-{
-	show_stack_loglvl(task, sp, KERN_DEFAULT)
-}
-
 static void show_code(unsigned int __user *pc)
 {
 	long i;
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index 90f12582c218..6a9772ba7392 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -135,8 +135,7 @@ static void __dump(struct task_struct *tsk, unsigned long *base_reg,
 	printk("%s\n", loglvl);
 }
 
-void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *tsk, unsigned long *sp, const char *loglvl)
 {
 	unsigned long *base_reg;
 
@@ -157,11 +156,6 @@ void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
 	barrier();
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
-{
-	show_stack_loglvl(tsk, sp, KERN_EMERG);
-}
-
 DEFINE_SPINLOCK(die_lock);
 
 /*
diff --git a/arch/nios2/kernel/traps.c b/arch/nios2/kernel/traps.c
index 08071caa9b36..b172da4eb1a9 100644
--- a/arch/nios2/kernel/traps.c
+++ b/arch/nios2/kernel/traps.c
@@ -52,14 +52,13 @@ void _exception(int signo, struct pt_regs *regs, int code, unsigned long addr)
 }
 
 /*
- * The show_stack(), show_stack_loglvl() are external API
- * which we do not use ourselves.
+ * The show_stack() is external API which we do not use ourselves.
  */
 
 int kstack_depth_to_print = 48;
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
-		       const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *stack,
+		const char *loglvl)
 {
 	unsigned long *endstack, addr;
 	int i;
@@ -106,11 +105,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
 	printk("%s\n", loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *stack)
-{
-	show_stack_loglvl(task, stack, KERN_EMERG);
-}
-
 void __init trap_init(void)
 {
 	/* Nothing to do here */
diff --git a/arch/openrisc/kernel/traps.c b/arch/openrisc/kernel/traps.c
index 9d5a85dd1992..97163815bbc5 100644
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -48,8 +48,7 @@ void print_trace(void *data, unsigned long addr, int reliable)
 }
 
 /* displays a short stack trace */
-void show_stack_loglvl(struct task_struct *task, unsigned long *esp,
-		const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *esp, const char *loglvl)
 {
 	if (esp == NULL)
 		esp = (unsigned long *)&esp;
@@ -58,11 +57,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *esp,
 	unwind_stack((void *)loglvl, esp, print_trace);
 }
 
-void show_stack(struct task_struct *task, unsigned long *esp)
-{
-	show_stack_loglvl(task, esp, KERN_EMERG);
-}
-
 void show_trace_task(struct task_struct *tsk)
 {
 	/*
@@ -111,7 +105,7 @@ void show_registers(struct pt_regs *regs)
 	if (in_kernel) {
 
 		printk("\nStack: ");
-		show_stack(NULL, (unsigned long *)esp);
+		show_stack(NULL, (unsigned long *)esp, KERN_EMERG);
 
 		printk("\nCode: ");
 		if (regs->pc < PAGE_OFFSET)
diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
index c2411de3730f..0a89899f154a 100644
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -198,17 +198,11 @@ static void parisc_show_stack(struct task_struct *task,
 	do_show_stack(&info, loglvl);
 }
 
-void show_stack_loglvl(struct task_struct *t, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *t, unsigned long *sp, const char *loglvl)
 {
 	parisc_show_stack(t, NULL, loglvl);
 }
 
-void show_stack(struct task_struct *t, unsigned long *sp)
-{
-	show_stack_loglvl(t, sp, KERN_CRIT)
-}
-
 int is_valid_bugaddr(unsigned long iaoq)
 {
 	return 1;
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 34b46680a196..b37bc12b072b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1431,7 +1431,7 @@ void show_regs(struct pt_regs * regs)
 	printk("NIP ["REG"] %pS\n", regs->nip, (void *)regs->nip);
 	printk("LR ["REG"] %pS\n", regs->link, (void *)regs->link);
 #endif
-	show_stack(current, (unsigned long *) regs->gpr[1]);
+	show_stack(current, (unsigned long *) regs->gpr[1], KERN_DEFAULT);
 	if (!user_mode(regs))
 		show_instructions(regs);
 }
@@ -2028,8 +2028,8 @@ unsigned long get_wchan(struct task_struct *p)
 
 static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
 
-void show_stack_loglvl(struct task_struct *tsk, unsigned long *stack,
-		       const char *loglvl)
+void show_stack(struct task_struct *tsk, unsigned long *stack,
+		const char *loglvl)
 {
 	unsigned long sp, ip, lr, newsp;
 	int count = 0;
@@ -2098,11 +2098,6 @@ void show_stack_loglvl(struct task_struct *tsk, unsigned long *stack,
 	put_task_stack(tsk);
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *stack)
-{
-	show_stack_loglvl(tsk, stack, KERN_DEFAULT);
-}
-
 #ifdef CONFIG_PPC64
 /* Called with hard IRQs off */
 void notrace __ppc64_runlatch_on(void)
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index e2a46cfed5fd..5efef8f35ad3 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -260,7 +260,7 @@ static void raise_backtrace_ipi(cpumask_t *mask)
 			pr_cont(" current pointer corrupt? (%px)\n", p->__current);
 
 		pr_warn("Back trace of paca->saved_r1 (0x%016llx) (possibly stale):\n", p->saved_r1);
-		show_stack(p->__current, (unsigned long *)p->saved_r1);
+		show_stack(p->__current, (unsigned long *)p->saved_r1, KERN_WARNING);
 	}
 }
 
diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 5b414ba9848b..7d60aa44598e 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -104,18 +104,12 @@ static bool print_trace_address(unsigned long pc, void *arg)
 	return false;
 }
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *sp, const char *loglvl)
 {
 	pr_cont("Call Trace:\n");
 	walk_stackframe(task, NULL, print_trace_address, (void *)loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
-{
-	show_stack_loglvl(task, sp, KERN_DEFAULT);
-}
-
 static bool save_wchan(unsigned long pc, void *arg)
 {
 	if (!in_sched_functions(pc)) {
diff --git a/arch/s390/kernel/dumpstack.c b/arch/s390/kernel/dumpstack.c
index 1a89f0968742..1e383f7e0d3a 100644
--- a/arch/s390/kernel/dumpstack.c
+++ b/arch/s390/kernel/dumpstack.c
@@ -123,7 +123,7 @@ int get_stack_info(unsigned long sp, struct task_struct *task,
 	return -EINVAL;
 }
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+void show_stack(struct task_struct *task, unsigned long *stack,
 		       const char *loglvl)
 {
 	struct unwind_state state;
@@ -138,11 +138,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
 	debug_show_held_locks(task ? : current);
 }
 
-void show_stack(struct task_struct *task, unsigned long *stack)
-{
-	show_stack_loglvl(task, stack, KERN_DEFAULT);
-}
-
 static void show_last_breaking_event(struct pt_regs *regs)
 {
 	printk("Last Breaking-Event-Address:\n");
diff --git a/arch/sh/kernel/dumpstack.c b/arch/sh/kernel/dumpstack.c
index cc51e9d74667..a13c045804ed 100644
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -144,8 +144,7 @@ void show_trace(struct task_struct *tsk, unsigned long *sp,
 	debug_show_held_locks(tsk);
 }
 
-void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *tsk, unsigned long *sp, const char *loglvl)
 {
 	unsigned long stack;
 
@@ -161,8 +160,3 @@ void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
 		 (unsigned long)task_stack_page(tsk));
 	show_trace(tsk, sp, NULL, loglvl);
 }
-
-void show_stack(struct task_struct *task, unsigned long *sp)
-{
-	show_stack_loglvl(task, sp, KERN_DEFAULT);
-}
diff --git a/arch/sh/kernel/process_64.c b/arch/sh/kernel/process_64.c
index c2844a2e18cd..4c2144225c8e 100644
--- a/arch/sh/kernel/process_64.c
+++ b/arch/sh/kernel/process_64.c
@@ -275,13 +275,12 @@ void show_regs(struct pt_regs *regs)
 	 * If we're in kernel mode, dump the stack too..
 	 */
 	if (!user_mode(regs)) {
-		void show_stack(struct task_struct *tsk, unsigned long *sp);
 		unsigned long sp = regs->regs[15] & 0xffffffff;
 		struct task_struct *tsk = get_current();
 
 		tsk->thread.kregs = regs;
 
-		show_stack(tsk, (unsigned long *)sp);
+		show_stack(tsk, (unsigned long *)sp, KERN_DEFAULT);
 	}
 }
 
diff --git a/arch/sparc/kernel/process_32.c b/arch/sparc/kernel/process_32.c
index d2f3aea7b977..8d9831054e44 100644
--- a/arch/sparc/kernel/process_32.c
+++ b/arch/sparc/kernel/process_32.c
@@ -145,12 +145,10 @@ void show_regs(struct pt_regs *r)
 }
 
 /*
- * The show_stack(), show_stack_loglvl() are external APIs which
- * we do not use ourselves.
+ * The show_stack() is external API which we do not use ourselves.
  * The oops is printed in die_if_kernel.
  */
-void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *sp, const char *loglvl)
 {
 	unsigned long pc, fp;
 	unsigned long task_base;
@@ -179,11 +177,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
 	printk("%s\n", loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
-{
-	show_stack_loglvl(task, sp, KERN_DEFAULT);
-}
-
 /*
  * Free current thread data structures etc..
  */
diff --git a/arch/sparc/kernel/process_64.c b/arch/sparc/kernel/process_64.c
index 4282116e28e7..b2e3fe729b7e 100644
--- a/arch/sparc/kernel/process_64.c
+++ b/arch/sparc/kernel/process_64.c
@@ -195,7 +195,7 @@ void show_regs(struct pt_regs *regs)
 	       regs->u_regs[15]);
 	printk("RPC: <%pS>\n", (void *) regs->u_regs[15]);
 	show_regwindow(regs);
-	show_stack(current, (unsigned long *) regs->u_regs[UREG_FP]);
+	show_stack(current, (unsigned long *)regs->u_regs[UREG_FP], KERN_DEFAULT);
 }
 
 union global_cpu_snapshot global_cpu_snapshot[NR_CPUS];
diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c
index 0117489e9b30..f16ed66ffadc 100644
--- a/arch/um/drivers/mconsole_kern.c
+++ b/arch/um/drivers/mconsole_kern.c
@@ -642,7 +642,7 @@ static void stack_proc(void *arg)
 {
 	struct task_struct *task = arg;
 
-	show_stack(task, NULL);
+	show_stack(task, NULL, KERN_INFO);
 }
 
 /*
diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index 1b54b6431499..acbc879d2773 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -27,7 +27,7 @@ static const struct stacktrace_ops stackops = {
 	.address = _print_addr
 };
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
+void show_stack(struct task_struct *task, unsigned long *stack,
 		       const char *loglvl)
 {
 	struct pt_regs *segv_regs = current->thread.segv_regs;
@@ -56,8 +56,3 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *stack,
 	dump_trace(current, &stackops, (void *)loglvl);
 	printk("%s\n", loglvl);
 }
-
-void show_stack(struct task_struct *task, unsigned long *stack)
-{
-	show_stack_loglvl(task, stack, KERN_INFO);
-}
diff --git a/arch/unicore32/kernel/traps.c b/arch/unicore32/kernel/traps.c
index 8b1335997f50..a3ac01df1a2e 100644
--- a/arch/unicore32/kernel/traps.c
+++ b/arch/unicore32/kernel/traps.c
@@ -167,18 +167,13 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
 		c_backtrace(fp, loglvl);
 }
 
-void show_stack_loglvl(struct task_struct *tsk, unsigned long *sp,
+void show_stack(struct task_struct *tsk, unsigned long *sp,
 		       const char *loglvl)
 {
 	dump_backtrace(NULL, tsk, loglvl);
 	barrier();
 }
 
-void show_stack(struct task_struct *tsk, unsigned long *sp)
-{
-	show_stack_loglvl(tsk, sp, KERN_DEFAULT)
-}
-
 static int __die(const char *str, int err, struct thread_info *thread,
 		struct pt_regs *regs)
 {
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index 033503f394f7..4e11a199432a 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -159,7 +159,7 @@ static void dump_leak(void)
 		return;
 	dump = 1;
 
-	show_stack_loglvl(NULL, NULL, KERN_ERR);
+	show_stack(NULL, NULL, KERN_ERR);
 	debug_dma_dump_mappings(NULL);
 }
 #endif
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 940cd4c27b17..5c974462c087 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -279,7 +279,7 @@ void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs,
 	}
 }
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
+void show_stack(struct task_struct *task, unsigned long *sp,
 		       const char *loglvl)
 {
 	task = task ? : current;
@@ -294,11 +294,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
 	show_trace_log_lvl(task, NULL, sp, loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
-{
-	show_stack_loglvl(task, sp, KERN_DEFAULT);
-}
-
 void show_stack_regs(struct pt_regs *regs)
 {
 	show_trace_log_lvl(current, regs, NULL, KERN_DEFAULT);
diff --git a/arch/xtensa/kernel/traps.c b/arch/xtensa/kernel/traps.c
index ba6c150095c6..791441c5ddaa 100644
--- a/arch/xtensa/kernel/traps.c
+++ b/arch/xtensa/kernel/traps.c
@@ -502,8 +502,7 @@ static void show_trace(struct task_struct *task, unsigned long *sp,
 
 static int kstack_depth_to_print = 24;
 
-void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
-		       const char *loglvl)
+void show_stack(struct task_struct *task, unsigned long *sp, const char *loglvl)
 {
 	int i = 0;
 	unsigned long *stack;
@@ -524,11 +523,6 @@ void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
 	show_trace(task, stack, loglvl);
 }
 
-void show_stack(struct task_struct *task, unsigned long *sp)
-{
-	show_stack_loglvl(task, sp, KERN_INFO);
-}
-
 DEFINE_SPINLOCK(die_lock);
 
 void die(const char * str, struct pt_regs * regs, long err)
@@ -542,7 +536,7 @@ void die(const char * str, struct pt_regs * regs, long err)
 		IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "");
 	show_regs(regs);
 	if (!user_mode(regs))
-		show_stack(NULL, (unsigned long*)regs->areg[1]);
+		show_stack(NULL, (unsigned long *)regs->areg[1], KERN_INFO);
 
 	add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
 	spin_unlock_irq(&die_lock);
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 3f39c9524c4d..baf1aaaddb9f 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -487,7 +487,7 @@ static void dpm_watchdog_handler(struct timer_list *t)
 	struct dpm_watchdog *wd = from_timer(wd, t, timer);
 
 	dev_emerg(wd->dev, "**** DPM device timeout ****\n");
-	show_stack_loglvl(wd->tsk, NULL, KERN_EMERG);
+	show_stack(wd->tsk, NULL, KERN_EMERG);
 	panic("%s %s: unrecoverable failure\n",
 		dev_driver_string(wd->dev), dev_name(wd->dev));
 }
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index fc5f84fa5347..f9809bc7367d 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -220,7 +220,7 @@ static void showacpu(void *dummy)
 
 	raw_spin_lock_irqsave(&show_lock, flags);
 	pr_info("CPU%d:\n", smp_processor_id());
-	show_stack_loglvl(NULL, NULL, KERN_INFO);
+	show_stack(NULL, NULL, KERN_INFO);
 	raw_spin_unlock_irqrestore(&show_lock, flags);
 }
 
diff --git a/include/linux/sched/debug.h b/include/linux/sched/debug.h
index 373e4e3faf2a..00c45a0e6abe 100644
--- a/include/linux/sched/debug.h
+++ b/include/linux/sched/debug.h
@@ -30,9 +30,8 @@ extern void show_regs(struct pt_regs *);
  * task), SP is the stack pointer of the first frame that should be shown in the back
  * trace (or NULL if the entire call-chain of the task should be shown).
  */
-extern void show_stack(struct task_struct *task, unsigned long *sp);
-extern void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
-			      const char *loglvl);
+extern void show_stack(struct task_struct *task, unsigned long *sp,
+		       const char *loglvl);
 
 extern void sched_show_task(struct task_struct *p);
 
diff --git a/kernel/debug/kdb/kdb_bt.c b/kernel/debug/kdb/kdb_bt.c
index 5ce1fe082a38..00ae3516af5b 100644
--- a/kernel/debug/kdb/kdb_bt.c
+++ b/kernel/debug/kdb/kdb_bt.c
@@ -24,15 +24,15 @@ static void kdb_show_stack(struct task_struct *p, void *addr)
 	kdb_trap_printk++;
 	kdb_set_current_task(p);
 	if (addr) {
-		show_stack_loglvl(p, addr, KERN_EMERG);
+		show_stack(p, addr, KERN_EMERG);
 	} else if (kdb_current_regs) {
 #ifdef CONFIG_X86
-		show_stack_loglvl(p, &kdb_current_regs->sp, KERN_EMERG);
+		show_stack(p, &kdb_current_regs->sp, KERN_EMERG);
 #else
-		show_stack_loglvl(p, NULL, KERN_EMERG);
+		show_stack(p, NULL, KERN_EMERG);
 #endif
 	} else {
-		show_stack_loglvl(p, NULL, KERN_EMERG);
+		show_stack(p, NULL, KERN_EMERG);
 	}
 	kdb_trap_printk--;
 }
diff --git a/kernel/locking/rtmutex-debug.c b/kernel/locking/rtmutex-debug.c
index 5e63d6e8a223..36e69100e8e0 100644
--- a/kernel/locking/rtmutex-debug.c
+++ b/kernel/locking/rtmutex-debug.c
@@ -125,7 +125,7 @@ void debug_rt_mutex_print_deadlock(struct rt_mutex_waiter *waiter)
 
 	printk("\n%s/%d's [blocked] stackdump:\n\n",
 		task->comm, task_pid_nr(task));
-	show_stack_loglvl(task, NULL, KERN_DEFAULT);
+	show_stack(task, NULL, KERN_DEFAULT);
 	printk("\n%s/%d's [current] stackdump:\n\n",
 		current->comm, task_pid_nr(current));
 	dump_stack();
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index eb50c70e73ea..6de0229f2e6e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5932,7 +5932,7 @@ void sched_show_task(struct task_struct *p)
 		(unsigned long)task_thread_info(p)->flags);
 
 	print_worker_info(KERN_INFO, p);
-	show_stack_loglvl(p, NULL, KERN_INFO);
+	show_stack(p, NULL, KERN_INFO);
 	put_task_stack(p);
 }
 EXPORT_SYMBOL_GPL(sched_show_task);
diff --git a/lib/dump_stack.c b/lib/dump_stack.c
index efb8e651709d..54761a3d28db 100644
--- a/lib/dump_stack.c
+++ b/lib/dump_stack.c
@@ -74,7 +74,7 @@ void show_regs_print_info(const char *log_lvl)
 static void __dump_stack(void)
 {
 	dump_stack_print_info(KERN_DEFAULT);
-	show_stack_loglvl(NULL, NULL, KERN_DEFAULT);
+	show_stack(NULL, NULL, KERN_DEFAULT);
 }
 
 /**
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 323+ messages in thread

* Re: [PATCH 34/50] sparc: Add show_stack_loglvl()
  2019-11-06  3:05   ` Dmitry Safonov
@ 2019-11-06  3:33     ` David Miller
  -1 siblings, 0 replies; 323+ messages in thread
From: David Miller @ 2019-11-06  3:33 UTC (permalink / raw)
  To: dima
  Cc: linux-kernel, 0x7f454c46, akpm, gregkh, mingo, jslaby, pmladek,
	sergey.senozhatsky, rostedt, penguin-kernel, sparclinux

From: Dmitry Safonov <dima@arista.com>
Date: Wed,  6 Nov 2019 03:05:25 +0000

> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).
> 
> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
> 
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
> 
> Introduce show_stack_loglvl(), that eventually will substitute
> show_stack().
> 
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: sparclinux@vger.kernel.org
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>

Acked-by: David S. Miller <davem@davemloft.net>

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 34/50] sparc: Add show_stack_loglvl()
@ 2019-11-06  3:33     ` David Miller
  0 siblings, 0 replies; 323+ messages in thread
From: David Miller @ 2019-11-06  3:33 UTC (permalink / raw)
  To: dima
  Cc: linux-kernel, 0x7f454c46, akpm, gregkh, mingo, jslaby, pmladek,
	sergey.senozhatsky, rostedt, penguin-kernel, sparclinux

From: Dmitry Safonov <dima@arista.com>
Date: Wed,  6 Nov 2019 03:05:25 +0000

> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).
> 
> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
> 
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
> 
> Introduce show_stack_loglvl(), that eventually will substitute
> show_stack().
> 
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: sparclinux@vger.kernel.org
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>

Acked-by: David S. Miller <davem@davemloft.net>

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 43/50] xtensa: Add show_stack_loglvl()
  2019-11-06  3:05 ` [PATCH 43/50] xtensa: Add show_stack_loglvl() Dmitry Safonov
@ 2019-11-06  4:13   ` Max Filippov
  2019-11-06  8:15     ` Petr Mladek
  0 siblings, 1 reply; 323+ messages in thread
From: Max Filippov @ 2019-11-06  4:13 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: LKML, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Chris Zankel,
	open list:TENSILICA XTENSA PORT (xtensa)

Hi Dmitry,

On Tue, Nov 5, 2019 at 7:08 PM Dmitry Safonov <dima@arista.com> wrote:
>
> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).
>
> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
>
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
>
> Introduce show_stack_loglvl(), that eventually will substitute
> show_stack().
>
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Cc: linux-xtensa@linux-xtensa.org
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> ---
>  arch/xtensa/kernel/traps.c | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/arch/xtensa/kernel/traps.c b/arch/xtensa/kernel/traps.c
> index cbc0d673f542..ba6c150095c6 100644
> --- a/arch/xtensa/kernel/traps.c
> +++ b/arch/xtensa/kernel/traps.c
> @@ -502,7 +502,8 @@ static void show_trace(struct task_struct *task, unsigned long *sp,
>
>  static int kstack_depth_to_print = 24;
>
> -void show_stack(struct task_struct *task, unsigned long *sp)
> +void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
> +                      const char *loglvl)
>  {
>         int i = 0;
>         unsigned long *stack;
> @@ -511,16 +512,21 @@ void show_stack(struct task_struct *task, unsigned long *sp)
>                 sp = stack_pointer(task);
>         stack = sp;
>
> -       pr_info("Stack:\n");
> +       printk("%sStack:\n", loglvl);
>
>         for (i = 0; i < kstack_depth_to_print; i++) {
>                 if (kstack_end(sp))
>                         break;
> -               pr_cont(" %08lx", *sp++);
> +               printk("%s %08lx", loglvl, *sp++);
>                 if (i % 8 == 7)
> -                       pr_cont("\n");
> +                       printk("%s\n", loglvl);
>         }
> -       show_trace(task, stack, KERN_INFO);
> +       show_trace(task, stack, loglvl);
> +}
> +
> +void show_stack(struct task_struct *task, unsigned long *sp)
> +{
> +       show_stack_loglvl(task, sp, KERN_INFO);
>  }
>
>  DEFINE_SPINLOCK(die_lock);
> --
> 2.23.0

This change doesn't work well with printk timestamps, it changes
the following output on xtensa architecture

[    3.404675] Stack:
[    3.404861]  a05773e2 00000018 bb03dc34 bb03dc30 a0008640 bb03dc70
ba9ba410 37c3f000
[    3.405414]  37c3f000 d7c3f000 00000800 bb03dc50 a02b97ed bb03dc90
ba9ba400 ba9ba410
[    3.405969]  a05fc1bc bbff28dc 00000000 bb03dc70 a02b7fb9 bb03dce0
ba9ba410 a0579044

into this:
[    3.056825] Stack:
[    3.056963]  a04ebb20
[    3.056995]  bb03dc10
[    3.057138]  00000001
[    3.057277]  bb03dc10
[    3.057815]  a00083ca
[    3.057965]  bb03dc50
[    3.058107]  ba9ba410
[    3.058247]  37c3f000
[    3.058387]
[    3.058584]  a05773e2
[    3.058614]  00000001
[    3.058755]  a05ca0bc
[    3.058896]  bb03dc30
[    3.059035]  a000865c
[    3.059180]  bb03dc70
[    3.059319]  ba9ba410
[    3.059459]  37c3f000
[    3.059598]
[    3.059795]  37c3f000
[    3.059824]  d7c3f000
[    3.059964]  00000800
[    3.060103]  bb03dc50
[    3.060241]  a02b9809
[    3.060379]  bb03dc90
[    3.060519]  ba9ba400
[    3.060658]  ba9ba410
[    3.060796]

-- 
Thanks.
-- Max

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 01/50] kallsyms/printk: Add loglvl to print_ip_sym()
  2019-11-06  3:04   ` Dmitry Safonov
@ 2019-11-06  4:38     ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-06  4:38 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv

On (19/11/06 03:04), Dmitry Safonov wrote:
[..]
>  #endif /*_LINUX_KALLSYMS_H*/
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 233459c03b5a..914ff610b880 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -3999,7 +3999,7 @@ static void print_unlock_imbalance_bug(struct task_struct *curr,
>  		curr->comm, task_pid_nr(curr));
>  	print_lockdep_cache(lock);
>  	pr_cont(") at:\n");
> -	print_ip_sym(ip);
> +	print_ip_sym(KERN_WARNING, ip);
>  	pr_warn("but there are no more locks to release!\n");
>  	pr_warn("\nother info that might help us debug this:\n");
>  	lockdep_print_held_locks(curr);
> @@ -4604,7 +4604,7 @@ static void print_lock_contention_bug(struct task_struct *curr,
>  		curr->comm, task_pid_nr(curr));
>  	print_lockdep_cache(lock);
>  	pr_cont(") at:\n");
> -	print_ip_sym(ip);
> +	print_ip_sym(KERN_WARNING, ip);
>  	pr_warn("but there are no locks held!\n");
>  	pr_warn("\nother info that might help us debug this:\n");
>  	lockdep_print_held_locks(curr);
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index dd05a378631a..774ff0d8dfe9 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3858,7 +3858,7 @@ static noinline void __schedule_bug(struct task_struct *prev)
>  	if (IS_ENABLED(CONFIG_DEBUG_PREEMPT)
>  	    && in_atomic_preempt_off()) {
>  		pr_err("Preemption disabled at:");
> -		print_ip_sym(preempt_disable_ip);
> +		print_ip_sym(KERN_ERR, preempt_disable_ip);
>  		pr_cont("\n");

Is this working with pr_cont()?

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 01/50] kallsyms/printk: Add loglvl to print_ip_sym()
@ 2019-11-06  4:38     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-06  4:38 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Tetsuo Handa, James Hogan, Dmitry Safonov,
	linux-mips, Ben Segall, linux-riscv, Vincent Chen, Will Deacon,
	Ingo Molnar, Vincent Guittot, Paul Burton, Peter Zijlstra,
	Ingo Molnar, Mel Gorman, Jiri Slaby, Petr Mladek, Albert Ou,
	Steven Rostedt, Greentime Hu, Paul Walmsley, Thomas Gleixner,
	Dietmar Eggemann, Michal Simek, Greg Kroah-Hartman, linux-kernel,
	Ralf Baechle, Sergey Senozhatsky, Palmer Dabbelt, Andrew Morton

On (19/11/06 03:04), Dmitry Safonov wrote:
[..]
>  #endif /*_LINUX_KALLSYMS_H*/
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 233459c03b5a..914ff610b880 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -3999,7 +3999,7 @@ static void print_unlock_imbalance_bug(struct task_struct *curr,
>  		curr->comm, task_pid_nr(curr));
>  	print_lockdep_cache(lock);
>  	pr_cont(") at:\n");
> -	print_ip_sym(ip);
> +	print_ip_sym(KERN_WARNING, ip);
>  	pr_warn("but there are no more locks to release!\n");
>  	pr_warn("\nother info that might help us debug this:\n");
>  	lockdep_print_held_locks(curr);
> @@ -4604,7 +4604,7 @@ static void print_lock_contention_bug(struct task_struct *curr,
>  		curr->comm, task_pid_nr(curr));
>  	print_lockdep_cache(lock);
>  	pr_cont(") at:\n");
> -	print_ip_sym(ip);
> +	print_ip_sym(KERN_WARNING, ip);
>  	pr_warn("but there are no locks held!\n");
>  	pr_warn("\nother info that might help us debug this:\n");
>  	lockdep_print_held_locks(curr);
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index dd05a378631a..774ff0d8dfe9 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3858,7 +3858,7 @@ static noinline void __schedule_bug(struct task_struct *prev)
>  	if (IS_ENABLED(CONFIG_DEBUG_PREEMPT)
>  	    && in_atomic_preempt_off()) {
>  		pr_err("Preemption disabled at:");
> -		print_ip_sym(preempt_disable_ip);
> +		print_ip_sym(KERN_ERR, preempt_disable_ip);
>  		pr_cont("\n");

Is this working with pr_cont()?

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 43/50] xtensa: Add show_stack_loglvl()
  2019-11-06  4:13   ` Max Filippov
@ 2019-11-06  8:15     ` Petr Mladek
  2019-11-06 16:06       ` Dmitry Safonov
  2019-11-06 16:44       ` Max Filippov
  0 siblings, 2 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-06  8:15 UTC (permalink / raw)
  To: Max Filippov
  Cc: Dmitry Safonov, LKML, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Chris Zankel,
	open list:TENSILICA XTENSA PORT (xtensa)

On Tue 2019-11-05 20:13:22, Max Filippov wrote:
> Hi Dmitry,
> 
> On Tue, Nov 5, 2019 at 7:08 PM Dmitry Safonov <dima@arista.com> wrote:
> >
> > Currently, the log-level of show_stack() depends on a platform
> > realization. It creates situations where the headers are printed with
> > lower log level or higher than the stacktrace (depending on
> > a platform or user).
> >
> > Furthermore, it forces the logic decision from user to an architecture
> > side. In result, some users as sysrq/kdb/etc are doing tricks with
> > temporary rising console_loglevel while printing their messages.
> > And in result it not only may print unwanted messages from other CPUs,
> > but also omit printing at all in the unlucky case where the printk()
> > was deferred.
> >
> > Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> > an easier approach than introducing more printk buffers.
> > Also, it will consolidate printings with headers.
> >
> > Introduce show_stack_loglvl(), that eventually will substitute
> > show_stack().
> >
> > Cc: Chris Zankel <chris@zankel.net>
> > Cc: Max Filippov <jcmvbkbc@gmail.com>
> > Cc: linux-xtensa@linux-xtensa.org
> > [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> > Signed-off-by: Dmitry Safonov <dima@arista.com>
> > ---
> >  arch/xtensa/kernel/traps.c | 16 +++++++++++-----
> >  1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/xtensa/kernel/traps.c b/arch/xtensa/kernel/traps.c
> > index cbc0d673f542..ba6c150095c6 100644
> > --- a/arch/xtensa/kernel/traps.c
> > +++ b/arch/xtensa/kernel/traps.c
> > @@ -502,7 +502,8 @@ static void show_trace(struct task_struct *task, unsigned long *sp,
> >
> >  static int kstack_depth_to_print = 24;
> >
> > -void show_stack(struct task_struct *task, unsigned long *sp)
> > +void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
> > +                      const char *loglvl)
> >  {
> >         int i = 0;
> >         unsigned long *stack;
> > @@ -511,16 +512,21 @@ void show_stack(struct task_struct *task, unsigned long *sp)
> >                 sp = stack_pointer(task);
> >         stack = sp;
> >
> > -       pr_info("Stack:\n");
> > +       printk("%sStack:\n", loglvl);
> >
> >         for (i = 0; i < kstack_depth_to_print; i++) {
> >                 if (kstack_end(sp))
> >                         break;
> > -               pr_cont(" %08lx", *sp++);
> > +               printk("%s %08lx", loglvl, *sp++);

KERN_CONT can be combined with any other loglevel.
So you could keep using pr_cont() together with explicit loglevel:

			pr_cont("%s %08lx", loglvl, *sp++);

It should fix the problems reported below.

Well, the preferred solution would be to snprintf() the continuous
line into a temporary buffer. And printk() it when it is complete.
pr_cont() is not reliable when more CPUs print at the same time.

Best Regards,
Petr

> This change doesn't work well with printk timestamps, it changes
> the following output on xtensa architecture
> 
> [    3.404675] Stack:
> [    3.404861]  a05773e2 00000018 bb03dc34 bb03dc30 a0008640 bb03dc70
> ba9ba410 37c3f000
> [    3.405414]  37c3f000 d7c3f000 00000800 bb03dc50 a02b97ed bb03dc90
> ba9ba400 ba9ba410
> [    3.405969]  a05fc1bc bbff28dc 00000000 bb03dc70 a02b7fb9 bb03dce0
> ba9ba410 a0579044
> 
> into this:
> [    3.056825] Stack:
> [    3.056963]  a04ebb20
> [    3.056995]  bb03dc10
> [    3.057138]  00000001
> [    3.057277]  bb03dc10
> [    3.057815]  a00083ca
> [    3.057965]  bb03dc50
> [    3.058107]  ba9ba410
> [    3.058247]  37c3f000
> [    3.058387]
> [    3.058584]  a05773e2
> [    3.058614]  00000001
> [    3.058755]  a05ca0bc
> [    3.058896]  bb03dc30
> [    3.059035]  a000865c
> [    3.059180]  bb03dc70
> [    3.059319]  ba9ba410
> [    3.059459]  37c3f000
> [    3.059598]
> [    3.059795]  37c3f000
> [    3.059824]  d7c3f000
> [    3.059964]  00000800
> [    3.060103]  bb03dc50
> [    3.060241]  a02b9809
> [    3.060379]  bb03dc90
> [    3.060519]  ba9ba400
> [    3.060658]  ba9ba410
> [    3.060796]
> 
> -- 
> Thanks.
> -- Max

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06  3:04 ` Dmitry Safonov
                     ` (3 preceding siblings ...)
  (?)
@ 2019-11-06  8:35   ` Petr Mladek
  -1 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-06  8:35 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]

Just to clarify. The problem in sysrq driver is a bit different.
It modifies console_loglevel to show even less important message
on the console.

IMHO, it should be solved by printing the header line with pr_error().
It is not ideal. A cleaner solution might be to introduce another
loglevel that will always get pushed to the console. But I am
not sure if it is worth this single line.

>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

> The least important for upstream, but maybe still worth to note that
> every company I've worked in so far had an off-list patch to print
> backtrace with the needed log level (but only for the architecture they
> cared about).
> If you have other ideas how you will benefit from show_stack() with
> a log level - please, reply to this cover letter.

I agree with all the other justification.

I would add. The backtrace is really useful for debugging. It should
be possible to print it even in less critical situations.

I am afraid that many people use WARN() for this purpose. But WARN()
is not always appropriate. WARN() misuse huts when panic_on_warn
option is used.

Best Regards,
Petr

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  8:35   ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-06  8:35 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]

Just to clarify. The problem in sysrq driver is a bit different.
It modifies console_loglevel to show even less important message
on the console.

IMHO, it should be solved by printing the header line with pr_error().
It is not ideal. A cleaner solution might be to introduce another
loglevel that will always get pushed to the console. But I am
not sure if it is worth this single line.

>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

> The least important for upstream, but maybe still worth to note that
> every company I've worked in so far had an off-list patch to print
> backtrace with the needed log level (but only for the architecture they
> cared about).
> If you have other ideas how you will benefit from show_stack() with
> a log level - please, reply to this cover letter.

I agree with all the other justification.

I would add. The backtrace is really useful for debugging. It should
be possible to print it even in less critical situations.

I am afraid that many people use WARN() for this purpose. But WARN()
is not always appropriate. WARN() misuse huts when panic_on_warn
option is used.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  8:35   ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-06  8:35 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]

Just to clarify. The problem in sysrq driver is a bit different.
It modifies console_loglevel to show even less important message
on the console.

IMHO, it should be solved by printing the header line with pr_error().
It is not ideal. A cleaner solution might be to introduce another
loglevel that will always get pushed to the console. But I am
not sure if it is worth this single line.

>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

> The least important for upstream, but maybe still worth to note that
> every company I've worked in so far had an off-list patch to print
> backtrace with the needed log level (but only for the architecture they
> cared about).
> If you have other ideas how you will benefit from show_stack() with
> a log level - please, reply to this cover letter.

I agree with all the other justification.

I would add. The backtrace is really useful for debugging. It should
be possible to print it even in less critical situations.

I am afraid that many people use WARN() for this purpose. But WARN()
is not always appropriate. WARN() misuse huts when panic_on_warn
option is used.

Best Regards,
Petr

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  8:35   ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-06  8:35 UTC (permalink / raw)
  To: openrisc

On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]

Just to clarify. The problem in sysrq driver is a bit different.
It modifies console_loglevel to show even less important message
on the console.

IMHO, it should be solved by printing the header line with pr_error().
It is not ideal. A cleaner solution might be to introduce another
loglevel that will always get pushed to the console. But I am
not sure if it is worth this single line.

>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

> The least important for upstream, but maybe still worth to note that
> every company I've worked in so far had an off-list patch to print
> backtrace with the needed log level (but only for the architecture they
> cared about).
> If you have other ideas how you will benefit from show_stack() with
> a log level - please, reply to this cover letter.

I agree with all the other justification.

I would add. The backtrace is really useful for debugging. It should
be possible to print it even in less critical situations.

I am afraid that many people use WARN() for this purpose. But WARN()
is not always appropriate. WARN() misuse huts when panic_on_warn
option is used.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  8:35   ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-06  8:35 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Sergey Senozhatsky, Steven Rostedt,
	Tetsuo Handa, Albert Ou, Ben Segall, Dietmar Eggemann,
	Greentime Hu, Ingo Molnar, James Hogan, Juri Lelli, Mel Gorman,
	Michal Simek, Palmer Dabbelt, Paul Burton, Paul Walmsley,
	Peter Zijlstra, Ralf Baechle, Thomas Gleixner, Vincent Chen,
	Vincent Guittot, Will Deacon, linux-mips, linux-riscv,
	Ivan Kokshaysky, Matt Turner, Richard Henderson, linux-alpha,
	Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]

Just to clarify. The problem in sysrq driver is a bit different.
It modifies console_loglevel to show even less important message
on the console.

IMHO, it should be solved by printing the header line with pr_error().
It is not ideal. A cleaner solution might be to introduce another
loglevel that will always get pushed to the console. But I am
not sure if it is worth this single line.

>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

> The least important for upstream, but maybe still worth to note that
> every company I've worked in so far had an off-list patch to print
> backtrace with the needed log level (but only for the architecture they
> cared about).
> If you have other ideas how you will benefit from show_stack() with
> a log level - please, reply to this cover letter.

I agree with all the other justification.

I would add. The backtrace is really useful for debugging. It should
be possible to print it even in less critical situations.

I am afraid that many people use WARN() for this purpose. But WARN()
is not always appropriate. WARN() misuse huts when panic_on_warn
option is used.

Best Regards,
Petr


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  8:35   ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-06  8:35 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]

Just to clarify. The problem in sysrq driver is a bit different.
It modifies console_loglevel to show even less important message
on the console.

IMHO, it should be solved by printing the header line with pr_error().
It is not ideal. A cleaner solution might be to introduce another
loglevel that will always get pushed to the console. But I am
not sure if it is worth this single line.

>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

> The least important for upstream, but maybe still worth to note that
> every company I've worked in so far had an off-list patch to print
> backtrace with the needed log level (but only for the architecture they
> cared about).
> If you have other ideas how you will benefit from show_stack() with
> a log level - please, reply to this cover letter.

I agree with all the other justification.

I would add. The backtrace is really useful for debugging. It should
be possible to print it even in less critical situations.

I am afraid that many people use WARN() for this purpose. But WARN()
is not always appropriate. WARN() misuse huts when panic_on_warn
option is used.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 05/50] arm: Add loglvl to unwind_backtrace()
  2019-11-06  3:04   ` Dmitry Safonov
@ 2019-11-06  9:12     ` Russell King - ARM Linux admin
  -1 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-06  9:12 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Will Deacon, linux-arm-kernel,
	clang-built-linux

On Wed, Nov 06, 2019 at 03:04:56AM +0000, Dmitry Safonov wrote:
> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).
> 
> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
> 
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
> 
> Add log level argument to unwind_backtrace() as a preparation for
> introducing show_stack_loglvl().
> 
> As a good side-effect arm_syscall() is now printing errors with the same
> log level as the backtrace.
> 
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: clang-built-linux@googlegroups.com
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> ---
>  arch/arm/include/asm/unwind.h | 3 ++-
>  arch/arm/kernel/traps.c       | 6 +++---
>  arch/arm/kernel/unwind.c      | 7 ++++---
>  3 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/include/asm/unwind.h b/arch/arm/include/asm/unwind.h
> index 6e282c33126b..0f8a3439902d 100644
> --- a/arch/arm/include/asm/unwind.h
> +++ b/arch/arm/include/asm/unwind.h
> @@ -36,7 +36,8 @@ extern struct unwind_table *unwind_table_add(unsigned long start,
>  					     unsigned long text_addr,
>  					     unsigned long text_size);
>  extern void unwind_table_del(struct unwind_table *tab);
> -extern void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk);
> +extern void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
> +			     const char *loglvl);
>  
>  #endif	/* !__ASSEMBLY__ */
>  
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 7c3f32b26585..69e35462c9e9 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -202,7 +202,7 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
>  #ifdef CONFIG_ARM_UNWIND
>  static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>  {
> -	unwind_backtrace(regs, tsk);
> +	unwind_backtrace(regs, tsk, KERN_DEBUG);

Why demote this to debug level?  This is used as part of the kernel
panic message, surely we don't want this at debug level?  What about
the non-unwind version?

>  }
>  #else
>  static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> @@ -660,10 +660,10 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
>  	if (user_debug & UDBG_SYSCALL) {
>  		pr_err("[%d] %s: arm syscall %d\n",
>  		       task_pid_nr(current), current->comm, no);
> -		dump_instr("", regs);
> +		dump_instr(KERN_ERR, regs);
>  		if (user_mode(regs)) {
>  			__show_regs(regs);
> -			c_backtrace(frame_pointer(regs), processor_mode(regs), NULL);
> +			c_backtrace(frame_pointer(regs), processor_mode(regs), KERN_ERR);
>  		}
>  	}
>  #endif
> diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
> index 0a65005e10f0..caaae1b6f721 100644
> --- a/arch/arm/kernel/unwind.c
> +++ b/arch/arm/kernel/unwind.c
> @@ -455,11 +455,12 @@ int unwind_frame(struct stackframe *frame)
>  	return URC_OK;
>  }
>  
> -void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> +void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
> +		      const char *loglvl)
>  {
>  	struct stackframe frame;
>  
> -	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
> +	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);

Clearly, this isn't supposed to be part of the normal backtrace output...

Overall impression at this point is really not good.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 05/50] arm: Add loglvl to unwind_backtrace()
@ 2019-11-06  9:12     ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-06  9:12 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Petr Mladek, clang-built-linux, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, linux-kernel, Steven Rostedt, Sergey Senozhatsky,
	Jiri Slaby, Andrew Morton, Will Deacon, Ingo Molnar,
	linux-arm-kernel

On Wed, Nov 06, 2019 at 03:04:56AM +0000, Dmitry Safonov wrote:
> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).
> 
> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
> 
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
> 
> Add log level argument to unwind_backtrace() as a preparation for
> introducing show_stack_loglvl().
> 
> As a good side-effect arm_syscall() is now printing errors with the same
> log level as the backtrace.
> 
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: clang-built-linux@googlegroups.com
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> ---
>  arch/arm/include/asm/unwind.h | 3 ++-
>  arch/arm/kernel/traps.c       | 6 +++---
>  arch/arm/kernel/unwind.c      | 7 ++++---
>  3 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/include/asm/unwind.h b/arch/arm/include/asm/unwind.h
> index 6e282c33126b..0f8a3439902d 100644
> --- a/arch/arm/include/asm/unwind.h
> +++ b/arch/arm/include/asm/unwind.h
> @@ -36,7 +36,8 @@ extern struct unwind_table *unwind_table_add(unsigned long start,
>  					     unsigned long text_addr,
>  					     unsigned long text_size);
>  extern void unwind_table_del(struct unwind_table *tab);
> -extern void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk);
> +extern void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
> +			     const char *loglvl);
>  
>  #endif	/* !__ASSEMBLY__ */
>  
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 7c3f32b26585..69e35462c9e9 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -202,7 +202,7 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
>  #ifdef CONFIG_ARM_UNWIND
>  static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>  {
> -	unwind_backtrace(regs, tsk);
> +	unwind_backtrace(regs, tsk, KERN_DEBUG);

Why demote this to debug level?  This is used as part of the kernel
panic message, surely we don't want this at debug level?  What about
the non-unwind version?

>  }
>  #else
>  static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> @@ -660,10 +660,10 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs)
>  	if (user_debug & UDBG_SYSCALL) {
>  		pr_err("[%d] %s: arm syscall %d\n",
>  		       task_pid_nr(current), current->comm, no);
> -		dump_instr("", regs);
> +		dump_instr(KERN_ERR, regs);
>  		if (user_mode(regs)) {
>  			__show_regs(regs);
> -			c_backtrace(frame_pointer(regs), processor_mode(regs), NULL);
> +			c_backtrace(frame_pointer(regs), processor_mode(regs), KERN_ERR);
>  		}
>  	}
>  #endif
> diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
> index 0a65005e10f0..caaae1b6f721 100644
> --- a/arch/arm/kernel/unwind.c
> +++ b/arch/arm/kernel/unwind.c
> @@ -455,11 +455,12 @@ int unwind_frame(struct stackframe *frame)
>  	return URC_OK;
>  }
>  
> -void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> +void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
> +		      const char *loglvl)
>  {
>  	struct stackframe frame;
>  
> -	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
> +	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);

Clearly, this isn't supposed to be part of the normal backtrace output...

Overall impression at this point is really not good.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06  3:04 ` Dmitry Safonov
                     ` (3 preceding siblings ...)
  (?)
@ 2019-11-06  9:20   ` Peter Zijlstra
  -1 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06  9:20 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]
>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

I really don't understand that word salad. Why are you doing this?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  9:20   ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06  9:20 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]
>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

I really don't understand that word salad. Why are you doing this?

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  9:20   ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06  9:20 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]
>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

I really don't understand that word salad. Why are you doing this?

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  9:20   ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06  9:20 UTC (permalink / raw)
  To: openrisc

On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]
>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

I really don't understand that word salad. Why are you doing this?

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  9:20   ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06  9:20 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]
>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

I really don't understand that word salad. Why are you doing this?

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06  9:20   ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06  9:20 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
> 
> Justification:
> o It's a design mistake to move a business-logic decision
>   into platform realization detail.
> o I have currently two patches sets that would benefit from this work:
>   Removing console_loglevel jumps in sysrq driver [1]
>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>   probably didn't realise what it would involve).
> o While doing (1), (2) the backtraces were adjusted to headers
>   and other messages for each situation - so there won't be a situation
>   when the backtrace is printed, but the headers are missing because
>   they have lesser log level (or the reverse).
> o As the result in (2) plays with console_loglevel for kdb are removed.

I really don't understand that word salad. Why are you doing this?

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 26/50] powerpc: Add show_stack_loglvl()
  2019-11-06  3:05   ` Dmitry Safonov
@ 2019-11-06  9:52     ` Michael Ellerman
  -1 siblings, 0 replies; 323+ messages in thread
From: Michael Ellerman @ 2019-11-06  9:52 UTC (permalink / raw)
  To: Dmitry Safonov, linux-kernel
  Cc: Dmitry Safonov, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev

Dmitry Safonov <dima@arista.com> writes:
> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).

Yes, I've had bug reports where the stacktrace is missing, which is
annoying. Thanks for trying to fix the problem.

> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
>
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
>
> Introduce show_stack_loglvl(), that eventually will substitute
> show_stack().
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> ---
>  arch/powerpc/kernel/process.c | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)

This looks good to me.

Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)

cheers


> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 639ceae7da9d..34b46680a196 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -2028,7 +2028,8 @@ unsigned long get_wchan(struct task_struct *p)
>  
>  static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
>  
> -void show_stack(struct task_struct *tsk, unsigned long *stack)
> +void show_stack_loglvl(struct task_struct *tsk, unsigned long *stack,
> +		       const char *loglvl)
>  {
>  	unsigned long sp, ip, lr, newsp;
>  	int count = 0;
> @@ -2053,7 +2054,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
>  	}
>  
>  	lr = 0;
> -	printk("Call Trace:\n");
> +	printk("%sCall Trace:\n", loglvl);
>  	do {
>  		if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
>  			break;
> @@ -2062,7 +2063,8 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
>  		newsp = stack[0];
>  		ip = stack[STACK_FRAME_LR_SAVE];
>  		if (!firstframe || ip != lr) {
> -			printk("["REG"] ["REG"] %pS", sp, ip, (void *)ip);
> +			printk("%s["REG"] ["REG"] %pS",
> +				loglvl, sp, ip, (void *)ip);
>  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>  			ret_addr = ftrace_graph_ret_addr(current,
>  						&ftrace_idx, ip, stack);
> @@ -2084,8 +2086,9 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
>  			struct pt_regs *regs = (struct pt_regs *)
>  				(sp + STACK_FRAME_OVERHEAD);
>  			lr = regs->link;
> -			printk("--- interrupt: %lx at %pS\n    LR = %pS\n",
> -			       regs->trap, (void *)regs->nip, (void *)lr);
> +			printk("%s--- interrupt: %lx at %pS\n    LR = %pS\n",
> +			       loglvl, regs->trap,
> +			       (void *)regs->nip, (void *)lr);
>  			firstframe = 1;
>  		}
>  
> @@ -2095,6 +2098,11 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
>  	put_task_stack(tsk);
>  }
>  
> +void show_stack(struct task_struct *tsk, unsigned long *stack)
> +{
> +	show_stack_loglvl(tsk, stack, KERN_DEFAULT);
> +}
> +
>  #ifdef CONFIG_PPC64
>  /* Called with hard IRQs off */
>  void notrace __ppc64_runlatch_on(void)
> -- 
> 2.23.0

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 26/50] powerpc: Add show_stack_loglvl()
@ 2019-11-06  9:52     ` Michael Ellerman
  0 siblings, 0 replies; 323+ messages in thread
From: Michael Ellerman @ 2019-11-06  9:52 UTC (permalink / raw)
  To: Dmitry Safonov, linux-kernel
  Cc: Petr Mladek, Dmitry Safonov, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, Steven Rostedt, Sergey Senozhatsky,
	Paul Mackerras, Jiri Slaby, Andrew Morton, linuxppc-dev,
	Ingo Molnar

Dmitry Safonov <dima@arista.com> writes:
> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).

Yes, I've had bug reports where the stacktrace is missing, which is
annoying. Thanks for trying to fix the problem.

> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
>
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
>
> Introduce show_stack_loglvl(), that eventually will substitute
> show_stack().
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> ---
>  arch/powerpc/kernel/process.c | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)

This looks good to me.

Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)

cheers


> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 639ceae7da9d..34b46680a196 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -2028,7 +2028,8 @@ unsigned long get_wchan(struct task_struct *p)
>  
>  static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
>  
> -void show_stack(struct task_struct *tsk, unsigned long *stack)
> +void show_stack_loglvl(struct task_struct *tsk, unsigned long *stack,
> +		       const char *loglvl)
>  {
>  	unsigned long sp, ip, lr, newsp;
>  	int count = 0;
> @@ -2053,7 +2054,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
>  	}
>  
>  	lr = 0;
> -	printk("Call Trace:\n");
> +	printk("%sCall Trace:\n", loglvl);
>  	do {
>  		if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
>  			break;
> @@ -2062,7 +2063,8 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
>  		newsp = stack[0];
>  		ip = stack[STACK_FRAME_LR_SAVE];
>  		if (!firstframe || ip != lr) {
> -			printk("["REG"] ["REG"] %pS", sp, ip, (void *)ip);
> +			printk("%s["REG"] ["REG"] %pS",
> +				loglvl, sp, ip, (void *)ip);
>  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>  			ret_addr = ftrace_graph_ret_addr(current,
>  						&ftrace_idx, ip, stack);
> @@ -2084,8 +2086,9 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
>  			struct pt_regs *regs = (struct pt_regs *)
>  				(sp + STACK_FRAME_OVERHEAD);
>  			lr = regs->link;
> -			printk("--- interrupt: %lx at %pS\n    LR = %pS\n",
> -			       regs->trap, (void *)regs->nip, (void *)lr);
> +			printk("%s--- interrupt: %lx at %pS\n    LR = %pS\n",
> +			       loglvl, regs->trap,
> +			       (void *)regs->nip, (void *)lr);
>  			firstframe = 1;
>  		}
>  
> @@ -2095,6 +2098,11 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
>  	put_task_stack(tsk);
>  }
>  
> +void show_stack(struct task_struct *tsk, unsigned long *stack)
> +{
> +	show_stack_loglvl(tsk, stack, KERN_DEFAULT);
> +}
> +
>  #ifdef CONFIG_PPC64
>  /* Called with hard IRQs off */
>  void notrace __ppc64_runlatch_on(void)
> -- 
> 2.23.0

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 09/50] arm64: Add loglvl to dump_backtrace()
  2019-11-06  3:05   ` Dmitry Safonov
@ 2019-11-06 13:25     ` Will Deacon
  -1 siblings, 0 replies; 323+ messages in thread
From: Will Deacon @ 2019-11-06 13:25 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Catalin Marinas, Russell King,
	linux-arm-kernel

On Wed, Nov 06, 2019 at 03:05:00AM +0000, Dmitry Safonov wrote:
> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).
> 
> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
> 
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
> 
> Add log level argument to dump_backtrace() as a preparation for
> introducing show_stack_loglvl().
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> ---
>  arch/arm64/include/asm/stacktrace.h |  3 ++-
>  arch/arm64/kernel/process.c         |  2 +-
>  arch/arm64/kernel/traps.c           | 17 +++++++++--------
>  3 files changed, 12 insertions(+), 10 deletions(-)

[...]

> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 34739e80211b..59072c7b9fb4 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -52,9 +52,9 @@ static const char *handler[]= {
>  
>  int show_unhandled_signals = 0;
>  
> -static void dump_backtrace_entry(unsigned long where)
> +static void dump_backtrace_entry(unsigned long where, const char *loglvl)
>  {
> -	printk(" %pS\n", (void *)where);
> +	printk("%s %pS\n", loglvl, (void *)where);
>  }
>  
>  static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
> @@ -82,12 +82,13 @@ static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
>  	printk("%sCode: %s\n", lvl, str);
>  }
>  
> -void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> +void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
> +		    const char *loglvl)
>  {
>  	struct stackframe frame;
>  	int skip = 0;
>  
> -	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
> +	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);

This one needs to stay as pr_debug().

Will

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 09/50] arm64: Add loglvl to dump_backtrace()
@ 2019-11-06 13:25     ` Will Deacon
  0 siblings, 0 replies; 323+ messages in thread
From: Will Deacon @ 2019-11-06 13:25 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Petr Mladek, Catalin Marinas, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, linux-kernel, Steven Rostedt, Russell King,
	Sergey Senozhatsky, Jiri Slaby, Andrew Morton, Ingo Molnar,
	linux-arm-kernel

On Wed, Nov 06, 2019 at 03:05:00AM +0000, Dmitry Safonov wrote:
> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).
> 
> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
> 
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
> 
> Add log level argument to dump_backtrace() as a preparation for
> introducing show_stack_loglvl().
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Will Deacon <will@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> ---
>  arch/arm64/include/asm/stacktrace.h |  3 ++-
>  arch/arm64/kernel/process.c         |  2 +-
>  arch/arm64/kernel/traps.c           | 17 +++++++++--------
>  3 files changed, 12 insertions(+), 10 deletions(-)

[...]

> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 34739e80211b..59072c7b9fb4 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -52,9 +52,9 @@ static const char *handler[]= {
>  
>  int show_unhandled_signals = 0;
>  
> -static void dump_backtrace_entry(unsigned long where)
> +static void dump_backtrace_entry(unsigned long where, const char *loglvl)
>  {
> -	printk(" %pS\n", (void *)where);
> +	printk("%s %pS\n", loglvl, (void *)where);
>  }
>  
>  static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
> @@ -82,12 +82,13 @@ static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
>  	printk("%sCode: %s\n", lvl, str);
>  }
>  
> -void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> +void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
> +		    const char *loglvl)
>  {
>  	struct stackframe frame;
>  	int skip = 0;
>  
> -	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
> +	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);

This one needs to stay as pr_debug().

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 09/50] arm64: Add loglvl to dump_backtrace()
  2019-11-06 13:25     ` Will Deacon
@ 2019-11-06 16:00       ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:00 UTC (permalink / raw)
  To: Will Deacon
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Catalin Marinas, Russell King,
	linux-arm-kernel

On 11/6/19 1:25 PM, Will Deacon wrote:
> On Wed, Nov 06, 2019 at 03:05:00AM +0000, Dmitry Safonov wrote:
[..]
>> @@ -82,12 +82,13 @@ static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
>>  	printk("%sCode: %s\n", lvl, str);
>>  }
>>  
>> -void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>> +void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
>> +		    const char *loglvl)
>>  {
>>  	struct stackframe frame;
>>  	int skip = 0;
>>  
>> -	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
>> +	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);
> 
> This one needs to stay as pr_debug().

Makes sense, it's debug rather part of backtrace, will fix.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 09/50] arm64: Add loglvl to dump_backtrace()
@ 2019-11-06 16:00       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:00 UTC (permalink / raw)
  To: Will Deacon
  Cc: Petr Mladek, Catalin Marinas, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, linux-kernel, Steven Rostedt, Russell King,
	Sergey Senozhatsky, Jiri Slaby, Andrew Morton, Ingo Molnar,
	linux-arm-kernel

On 11/6/19 1:25 PM, Will Deacon wrote:
> On Wed, Nov 06, 2019 at 03:05:00AM +0000, Dmitry Safonov wrote:
[..]
>> @@ -82,12 +82,13 @@ static void dump_kernel_instr(const char *lvl, struct pt_regs *regs)
>>  	printk("%sCode: %s\n", lvl, str);
>>  }
>>  
>> -void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>> +void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
>> +		    const char *loglvl)
>>  {
>>  	struct stackframe frame;
>>  	int skip = 0;
>>  
>> -	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
>> +	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);
> 
> This one needs to stay as pr_debug().

Makes sense, it's debug rather part of backtrace, will fix.

Thanks,
          Dmitry

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 26/50] powerpc: Add show_stack_loglvl()
  2019-11-06  9:52     ` Michael Ellerman
@ 2019-11-06 16:01       ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:01 UTC (permalink / raw)
  To: Michael Ellerman, linux-kernel
  Cc: Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman, Ingo Molnar,
	Jiri Slaby, Petr Mladek, Sergey Senozhatsky, Steven Rostedt,
	Tetsuo Handa, Benjamin Herrenschmidt, Paul Mackerras,
	linuxppc-dev

On 11/6/19 9:52 AM, Michael Ellerman wrote:
> Dmitry Safonov <dima@arista.com> writes:
>> Currently, the log-level of show_stack() depends on a platform
>> realization. It creates situations where the headers are printed with
>> lower log level or higher than the stacktrace (depending on
>> a platform or user).
> 
> Yes, I've had bug reports where the stacktrace is missing, which is
> annoying. Thanks for trying to fix the problem.
> 
>> Furthermore, it forces the logic decision from user to an architecture
>> side. In result, some users as sysrq/kdb/etc are doing tricks with
>> temporary rising console_loglevel while printing their messages.
>> And in result it not only may print unwanted messages from other CPUs,
>> but also omit printing at all in the unlucky case where the printk()
>> was deferred.
>>
>> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
>> an easier approach than introducing more printk buffers.
>> Also, it will consolidate printings with headers.
>>
>> Introduce show_stack_loglvl(), that eventually will substitute
>> show_stack().
>>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
>> Signed-off-by: Dmitry Safonov <dima@arista.com>
>> ---
>>  arch/powerpc/kernel/process.c | 18 +++++++++++++-----
>>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> This looks good to me.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)

Thanks for the review and time!

-- 
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 26/50] powerpc: Add show_stack_loglvl()
@ 2019-11-06 16:01       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:01 UTC (permalink / raw)
  To: Michael Ellerman, linux-kernel
  Cc: Petr Mladek, Tetsuo Handa, Greg Kroah-Hartman, Dmitry Safonov,
	Steven Rostedt, Sergey Senozhatsky, Paul Mackerras, Jiri Slaby,
	Andrew Morton, linuxppc-dev, Ingo Molnar

On 11/6/19 9:52 AM, Michael Ellerman wrote:
> Dmitry Safonov <dima@arista.com> writes:
>> Currently, the log-level of show_stack() depends on a platform
>> realization. It creates situations where the headers are printed with
>> lower log level or higher than the stacktrace (depending on
>> a platform or user).
> 
> Yes, I've had bug reports where the stacktrace is missing, which is
> annoying. Thanks for trying to fix the problem.
> 
>> Furthermore, it forces the logic decision from user to an architecture
>> side. In result, some users as sysrq/kdb/etc are doing tricks with
>> temporary rising console_loglevel while printing their messages.
>> And in result it not only may print unwanted messages from other CPUs,
>> but also omit printing at all in the unlucky case where the printk()
>> was deferred.
>>
>> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
>> an easier approach than introducing more printk buffers.
>> Also, it will consolidate printings with headers.
>>
>> Introduce show_stack_loglvl(), that eventually will substitute
>> show_stack().
>>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
>> Signed-off-by: Dmitry Safonov <dima@arista.com>
>> ---
>>  arch/powerpc/kernel/process.c | 18 +++++++++++++-----
>>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> This looks good to me.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)

Thanks for the review and time!

-- 
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 34/50] sparc: Add show_stack_loglvl()
  2019-11-06  3:33     ` David Miller
@ 2019-11-06 16:02       ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:02 UTC (permalink / raw)
  To: David Miller
  Cc: linux-kernel, 0x7f454c46, akpm, gregkh, mingo, jslaby, pmladek,
	sergey.senozhatsky, rostedt, penguin-kernel, sparclinux

On 11/6/19 3:33 AM, David Miller wrote:
> From: Dmitry Safonov <dima@arista.com>
> Date: Wed,  6 Nov 2019 03:05:25 +0000
> 
>> Currently, the log-level of show_stack() depends on a platform
>> realization. It creates situations where the headers are printed with
>> lower log level or higher than the stacktrace (depending on
>> a platform or user).
>>
>> Furthermore, it forces the logic decision from user to an architecture
>> side. In result, some users as sysrq/kdb/etc are doing tricks with
>> temporary rising console_loglevel while printing their messages.
>> And in result it not only may print unwanted messages from other CPUs,
>> but also omit printing at all in the unlucky case where the printk()
>> was deferred.
>>
>> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
>> an easier approach than introducing more printk buffers.
>> Also, it will consolidate printings with headers.
>>
>> Introduce show_stack_loglvl(), that eventually will substitute
>> show_stack().
>>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: sparclinux@vger.kernel.org
>> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
>> Signed-off-by: Dmitry Safonov <dima@arista.com>
> 
> Acked-by: David S. Miller <davem@davemloft.net>

Thanks for the review and time, David!

-- 
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 34/50] sparc: Add show_stack_loglvl()
@ 2019-11-06 16:02       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:02 UTC (permalink / raw)
  To: David Miller
  Cc: linux-kernel, 0x7f454c46, akpm, gregkh, mingo, jslaby, pmladek,
	sergey.senozhatsky, rostedt, penguin-kernel, sparclinux

On 11/6/19 3:33 AM, David Miller wrote:
> From: Dmitry Safonov <dima@arista.com>
> Date: Wed,  6 Nov 2019 03:05:25 +0000
> 
>> Currently, the log-level of show_stack() depends on a platform
>> realization. It creates situations where the headers are printed with
>> lower log level or higher than the stacktrace (depending on
>> a platform or user).
>>
>> Furthermore, it forces the logic decision from user to an architecture
>> side. In result, some users as sysrq/kdb/etc are doing tricks with
>> temporary rising console_loglevel while printing their messages.
>> And in result it not only may print unwanted messages from other CPUs,
>> but also omit printing at all in the unlucky case where the printk()
>> was deferred.
>>
>> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
>> an easier approach than introducing more printk buffers.
>> Also, it will consolidate printings with headers.
>>
>> Introduce show_stack_loglvl(), that eventually will substitute
>> show_stack().
>>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: sparclinux@vger.kernel.org
>> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
>> Signed-off-by: Dmitry Safonov <dima@arista.com>
> 
> Acked-by: David S. Miller <davem@davemloft.net>

Thanks for the review and time, David!

-- 
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 43/50] xtensa: Add show_stack_loglvl()
  2019-11-06  8:15     ` Petr Mladek
@ 2019-11-06 16:06       ` Dmitry Safonov
  2019-11-06 16:44       ` Max Filippov
  1 sibling, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:06 UTC (permalink / raw)
  To: Petr Mladek, Max Filippov
  Cc: LKML, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Sergey Senozhatsky, Steven Rostedt,
	Tetsuo Handa, Chris Zankel,
	open list:TENSILICA XTENSA PORT (xtensa)

On 11/6/19 8:15 AM, Petr Mladek wrote:
> On Tue 2019-11-05 20:13:22, Max Filippov wrote:
[..]
>>> @@ -511,16 +512,21 @@ void show_stack(struct task_struct *task, unsigned long *sp)
>>>                 sp = stack_pointer(task);
>>>         stack = sp;
>>>
>>> -       pr_info("Stack:\n");
>>> +       printk("%sStack:\n", loglvl);
>>>
>>>         for (i = 0; i < kstack_depth_to_print; i++) {
>>>                 if (kstack_end(sp))
>>>                         break;
>>> -               pr_cont(" %08lx", *sp++);
>>> +               printk("%s %08lx", loglvl, *sp++);
> 
> KERN_CONT can be combined with any other loglevel.
> So you could keep using pr_cont() together with explicit loglevel:
> 
> 			pr_cont("%s %08lx", loglvl, *sp++);

Yes, that's what I had, but than misread the printk() code and thought
that it doesn't add '\n' to messages.. Will fix.

> It should fix the problems reported below.
> 
> Well, the preferred solution would be to snprintf() the continuous
> line into a temporary buffer. And printk() it when it is complete.
> pr_cont() is not reliable when more CPUs print at the same time.

Yep. Not sure if doing it now in those per-arch patches or keep the
changes to minimum.

> 
>> This change doesn't work well with printk timestamps, it changes
>> the following output on xtensa architecture
>>
>> [    3.404675] Stack:
>> [    3.404861]  a05773e2 00000018 bb03dc34 bb03dc30 a0008640 bb03dc70
>> ba9ba410 37c3f000
>> [    3.405414]  37c3f000 d7c3f000 00000800 bb03dc50 a02b97ed bb03dc90
>> ba9ba400 ba9ba410
>> [    3.405969]  a05fc1bc bbff28dc 00000000 bb03dc70 a02b7fb9 bb03dce0
>> ba9ba410 a0579044
>>
>> into this:
>> [    3.056825] Stack:
>> [    3.056963]  a04ebb20
>> [    3.056995]  bb03dc10
>> [    3.057138]  00000001
>> [    3.057277]  bb03dc10
>> [    3.057815]  a00083ca
>> [    3.057965]  bb03dc50
>> [    3.058107]  ba9ba410
>> [    3.058247]  37c3f000
>> [    3.058387]
>> [    3.058584]  a05773e2
>> [    3.058614]  00000001
>> [    3.058755]  a05ca0bc
>> [    3.058896]  bb03dc30
>> [    3.059035]  a000865c
>> [    3.059180]  bb03dc70
>> [    3.059319]  ba9ba410
>> [    3.059459]  37c3f000
>> [    3.059598]
>> [    3.059795]  37c3f000
>> [    3.059824]  d7c3f000
>> [    3.059964]  00000800
>> [    3.060103]  bb03dc50
>> [    3.060241]  a02b9809
>> [    3.060379]  bb03dc90
>> [    3.060519]  ba9ba400
>> [    3.060658]  ba9ba410
>> [    3.060796]

Hey Max,

thanks for the testing and the report - will fix it in v2.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06  8:35   ` Petr Mladek
                       ` (3 preceding siblings ...)
  (?)
@ 2019-11-06 16:12     ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On 11/6/19 8:35 AM, Petr Mladek wrote:
> On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
> 
> Just to clarify. The problem in sysrq driver is a bit different.
> It modifies console_loglevel to show even less important message
> on the console.
> 
> IMHO, it should be solved by printing the header line with pr_error().
> It is not ideal. A cleaner solution might be to introduce another
> loglevel that will always get pushed to the console. But I am
> not sure if it is worth this single line.

I believe why it's not done - there is a comment in sysrq code that said
the userspace relies on the loglevel of sysrq messages (and may trigger
alerts from emerg/err log level):
  * Raise the apparent loglevel to maximum so that the sysrq header
  * is shown to provide the user with positive feedback.  We do not
  * simply emit this at KERN_EMERG as that would change message
  * routing in the consumers of /proc/kmsg.

But I don't mind any solution.

>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
>> The least important for upstream, but maybe still worth to note that
>> every company I've worked in so far had an off-list patch to print
>> backtrace with the needed log level (but only for the architecture they
>> cared about).
>> If you have other ideas how you will benefit from show_stack() with
>> a log level - please, reply to this cover letter.
> 
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.
> 
> I am afraid that many people use WARN() for this purpose. But WARN()
> is not always appropriate. WARN() misuse huts when panic_on_warn
> option is used.

Thanks, Petr.

-- 
          Dmitry

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:12     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On 11/6/19 8:35 AM, Petr Mladek wrote:
> On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
> 
> Just to clarify. The problem in sysrq driver is a bit different.
> It modifies console_loglevel to show even less important message
> on the console.
> 
> IMHO, it should be solved by printing the header line with pr_error().
> It is not ideal. A cleaner solution might be to introduce another
> loglevel that will always get pushed to the console. But I am
> not sure if it is worth this single line.

I believe why it's not done - there is a comment in sysrq code that said
the userspace relies on the loglevel of sysrq messages (and may trigger
alerts from emerg/err log level):
  * Raise the apparent loglevel to maximum so that the sysrq header
  * is shown to provide the user with positive feedback.  We do not
  * simply emit this at KERN_EMERG as that would change message
  * routing in the consumers of /proc/kmsg.

But I don't mind any solution.

>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
>> The least important for upstream, but maybe still worth to note that
>> every company I've worked in so far had an off-list patch to print
>> backtrace with the needed log level (but only for the architecture they
>> cared about).
>> If you have other ideas how you will benefit from show_stack() with
>> a log level - please, reply to this cover letter.
> 
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.
> 
> I am afraid that many people use WARN() for this purpose. But WARN()
> is not always appropriate. WARN() misuse huts when panic_on_warn
> option is used.

Thanks, Petr.

-- 
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:12     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On 11/6/19 8:35 AM, Petr Mladek wrote:
> On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
> 
> Just to clarify. The problem in sysrq driver is a bit different.
> It modifies console_loglevel to show even less important message
> on the console.
> 
> IMHO, it should be solved by printing the header line with pr_error().
> It is not ideal. A cleaner solution might be to introduce another
> loglevel that will always get pushed to the console. But I am
> not sure if it is worth this single line.

I believe why it's not done - there is a comment in sysrq code that said
the userspace relies on the loglevel of sysrq messages (and may trigger
alerts from emerg/err log level):
  * Raise the apparent loglevel to maximum so that the sysrq header
  * is shown to provide the user with positive feedback.  We do not
  * simply emit this at KERN_EMERG as that would change message
  * routing in the consumers of /proc/kmsg.

But I don't mind any solution.

>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
>> The least important for upstream, but maybe still worth to note that
>> every company I've worked in so far had an off-list patch to print
>> backtrace with the needed log level (but only for the architecture they
>> cared about).
>> If you have other ideas how you will benefit from show_stack() with
>> a log level - please, reply to this cover letter.
> 
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.
> 
> I am afraid that many people use WARN() for this purpose. But WARN()
> is not always appropriate. WARN() misuse huts when panic_on_warn
> option is used.

Thanks, Petr.

-- 
          Dmitry

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:12     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:12 UTC (permalink / raw)
  To: openrisc

On 11/6/19 8:35 AM, Petr Mladek wrote:
> On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
> 
> Just to clarify. The problem in sysrq driver is a bit different.
> It modifies console_loglevel to show even less important message
> on the console.
> 
> IMHO, it should be solved by printing the header line with pr_error().
> It is not ideal. A cleaner solution might be to introduce another
> loglevel that will always get pushed to the console. But I am
> not sure if it is worth this single line.

I believe why it's not done - there is a comment in sysrq code that said
the userspace relies on the loglevel of sysrq messages (and may trigger
alerts from emerg/err log level):
  * Raise the apparent loglevel to maximum so that the sysrq header
  * is shown to provide the user with positive feedback.  We do not
  * simply emit this at KERN_EMERG as that would change message
  * routing in the consumers of /proc/kmsg.

But I don't mind any solution.

>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
>> The least important for upstream, but maybe still worth to note that
>> every company I've worked in so far had an off-list patch to print
>> backtrace with the needed log level (but only for the architecture they
>> cared about).
>> If you have other ideas how you will benefit from show_stack() with
>> a log level - please, reply to this cover letter.
> 
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.
> 
> I am afraid that many people use WARN() for this purpose. But WARN()
> is not always appropriate. WARN() misuse huts when panic_on_warn
> option is used.

Thanks, Petr.

-- 
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:12     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Sergey Senozhatsky, Steven Rostedt,
	Tetsuo Handa, Albert Ou, Ben Segall, Dietmar Eggemann,
	Greentime Hu, Ingo Molnar, James Hogan, Juri Lelli, Mel Gorman,
	Michal Simek, Palmer Dabbelt, Paul Burton, Paul Walmsley,
	Peter Zijlstra, Ralf Baechle, Thomas Gleixner, Vincent Chen,
	Vincent Guittot, Will Deacon, linux-mips, linux-riscv,
	Ivan Kokshaysky, Matt Turner, Richard Henderson, linux-alpha,
	Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On 11/6/19 8:35 AM, Petr Mladek wrote:
> On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
> 
> Just to clarify. The problem in sysrq driver is a bit different.
> It modifies console_loglevel to show even less important message
> on the console.
> 
> IMHO, it should be solved by printing the header line with pr_error().
> It is not ideal. A cleaner solution might be to introduce another
> loglevel that will always get pushed to the console. But I am
> not sure if it is worth this single line.

I believe why it's not done - there is a comment in sysrq code that said
the userspace relies on the loglevel of sysrq messages (and may trigger
alerts from emerg/err log level):
  * Raise the apparent loglevel to maximum so that the sysrq header
  * is shown to provide the user with positive feedback.  We do not
  * simply emit this at KERN_EMERG as that would change message
  * routing in the consumers of /proc/kmsg.

But I don't mind any solution.

>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
>> The least important for upstream, but maybe still worth to note that
>> every company I've worked in so far had an off-list patch to print
>> backtrace with the needed log level (but only for the architecture they
>> cared about).
>> If you have other ideas how you will benefit from show_stack() with
>> a log level - please, reply to this cover letter.
> 
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.
> 
> I am afraid that many people use WARN() for this purpose. But WARN()
> is not always appropriate. WARN() misuse huts when panic_on_warn
> option is used.

Thanks, Petr.

-- 
          Dmitry


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:12     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

On 11/6/19 8:35 AM, Petr Mladek wrote:
> On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
> 
> Just to clarify. The problem in sysrq driver is a bit different.
> It modifies console_loglevel to show even less important message
> on the console.
> 
> IMHO, it should be solved by printing the header line with pr_error().
> It is not ideal. A cleaner solution might be to introduce another
> loglevel that will always get pushed to the console. But I am
> not sure if it is worth this single line.

I believe why it's not done - there is a comment in sysrq code that said
the userspace relies on the loglevel of sysrq messages (and may trigger
alerts from emerg/err log level):
  * Raise the apparent loglevel to maximum so that the sysrq header
  * is shown to provide the user with positive feedback.  We do not
  * simply emit this at KERN_EMERG as that would change message
  * routing in the consumers of /proc/kmsg.

But I don't mind any solution.

>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
>> The least important for upstream, but maybe still worth to note that
>> every company I've worked in so far had an off-list patch to print
>> backtrace with the needed log level (but only for the architecture they
>> cared about).
>> If you have other ideas how you will benefit from show_stack() with
>> a log level - please, reply to this cover letter.
> 
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.
> 
> I am afraid that many people use WARN() for this purpose. But WARN()
> is not always appropriate. WARN() misuse huts when panic_on_warn
> option is used.

Thanks, Petr.

-- 
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06  9:20   ` Peter Zijlstra
                       ` (3 preceding siblings ...)
  (?)
@ 2019-11-06 16:27     ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:27 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

Hi Peter,

On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
> I really don't understand that word salad. Why are you doing this?
> 

Sorry, I should have tried to describe better.

I'm trying to remove external users of console_loglevel by following
reasons:
- changing console_loglevel on SMP means that unwanted messages from
other CPUs will appear (that have lower log level)
- on UMP unwanted messages may appear if the code is preempted while it
hasn't set the console_loglevel back to old
- rising console_loglevel to print wanted message(s) may not work at all
if printk() has being delayed and the console_loglevel is already set
back to old value

Sysrq driver changes console_loglevel because it needs to print message
with a specific log level (the code said userspace relies on this).
Kdb changes console_loglevel to print backtrace as the log level depends
on architecture realisation.

I also have patches in wip those needs to print backtrace with specific
loglevel (higher when it's critical, lower when it's notice and
shouldn't go to serial console).

Besides on local tests I see hits those have headers (messages like
"Backtrace: ") without an actual backtrace and the reverse - a backtrace
without a reason for it. It's quite annoying and worth addressing by
syncing headers log levels to backtraces.

Thanks,
          Dmitry

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:27     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:27 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

Hi Peter,

On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
> I really don't understand that word salad. Why are you doing this?
> 

Sorry, I should have tried to describe better.

I'm trying to remove external users of console_loglevel by following
reasons:
- changing console_loglevel on SMP means that unwanted messages from
other CPUs will appear (that have lower log level)
- on UMP unwanted messages may appear if the code is preempted while it
hasn't set the console_loglevel back to old
- rising console_loglevel to print wanted message(s) may not work at all
if printk() has being delayed and the console_loglevel is already set
back to old value

Sysrq driver changes console_loglevel because it needs to print message
with a specific log level (the code said userspace relies on this).
Kdb changes console_loglevel to print backtrace as the log level depends
on architecture realisation.

I also have patches in wip those needs to print backtrace with specific
loglevel (higher when it's critical, lower when it's notice and
shouldn't go to serial console).

Besides on local tests I see hits those have headers (messages like
"Backtrace: ") without an actual backtrace and the reverse - a backtrace
without a reason for it. It's quite annoying and worth addressing by
syncing headers log levels to backtraces.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:27     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:27 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

Hi Peter,

On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
> I really don't understand that word salad. Why are you doing this?
> 

Sorry, I should have tried to describe better.

I'm trying to remove external users of console_loglevel by following
reasons:
- changing console_loglevel on SMP means that unwanted messages from
other CPUs will appear (that have lower log level)
- on UMP unwanted messages may appear if the code is preempted while it
hasn't set the console_loglevel back to old
- rising console_loglevel to print wanted message(s) may not work at all
if printk() has being delayed and the console_loglevel is already set
back to old value

Sysrq driver changes console_loglevel because it needs to print message
with a specific log level (the code said userspace relies on this).
Kdb changes console_loglevel to print backtrace as the log level depends
on architecture realisation.

I also have patches in wip those needs to print backtrace with specific
loglevel (higher when it's critical, lower when it's notice and
shouldn't go to serial console).

Besides on local tests I see hits those have headers (messages like
"Backtrace: ") without an actual backtrace and the reverse - a backtrace
without a reason for it. It's quite annoying and worth addressing by
syncing headers log levels to backtraces.

Thanks,
          Dmitry

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:27     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:27 UTC (permalink / raw)
  To: openrisc

Hi Peter,

On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
> I really don't understand that word salad. Why are you doing this?
> 

Sorry, I should have tried to describe better.

I'm trying to remove external users of console_loglevel by following
reasons:
- changing console_loglevel on SMP means that unwanted messages from
other CPUs will appear (that have lower log level)
- on UMP unwanted messages may appear if the code is preempted while it
hasn't set the console_loglevel back to old
- rising console_loglevel to print wanted message(s) may not work at all
if printk() has being delayed and the console_loglevel is already set
back to old value

Sysrq driver changes console_loglevel because it needs to print message
with a specific log level (the code said userspace relies on this).
Kdb changes console_loglevel to print backtrace as the log level depends
on architecture realisation.

I also have patches in wip those needs to print backtrace with specific
loglevel (higher when it's critical, lower when it's notice and
shouldn't go to serial console).

Besides on local tests I see hits those have headers (messages like
"Backtrace: ") without an actual backtrace and the reverse - a backtrace
without a reason for it. It's quite annoying and worth addressing by
syncing headers log levels to backtraces.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:27     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:27 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Ralf Baechle, Thomas Gleixner,
	Vincent Chen, Vincent Guittot, Will Deacon, linux-mips,
	linux-riscv, Ivan Kokshaysky, Matt Turner, Richard Henderson,
	linux-alpha, Vineet Gupta, linux-snps-arc, Russell King,
	linux-arm-kernel, clang-built-linux, Catalin Marinas,
	Aurelien Jacquiot, Mark Salter, linux-c6x-dev, Guo Ren,
	Yoshinori Sato, uclinux-h8-devel, Brian Cain, linux-hexagon,
	Fenghua Yu, Tony Luck, linux-ia64, Geert Uytterhoeven,
	linux-m68k, Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

Hi Peter,

On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
> I really don't understand that word salad. Why are you doing this?
> 

Sorry, I should have tried to describe better.

I'm trying to remove external users of console_loglevel by following
reasons:
- changing console_loglevel on SMP means that unwanted messages from
other CPUs will appear (that have lower log level)
- on UMP unwanted messages may appear if the code is preempted while it
hasn't set the console_loglevel back to old
- rising console_loglevel to print wanted message(s) may not work at all
if printk() has being delayed and the console_loglevel is already set
back to old value

Sysrq driver changes console_loglevel because it needs to print message
with a specific log level (the code said userspace relies on this).
Kdb changes console_loglevel to print backtrace as the log level depends
on architecture realisation.

I also have patches in wip those needs to print backtrace with specific
loglevel (higher when it's critical, lower when it's notice and
shouldn't go to serial console).

Besides on local tests I see hits those have headers (messages like
"Backtrace: ") without an actual backtrace and the reverse - a backtrace
without a reason for it. It's quite annoying and worth addressing by
syncing headers log levels to backtraces.

Thanks,
          Dmitry


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 16:27     ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:27 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

Hi Peter,

On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming show_stack_loglvl() into show_stack()
>>
>> Justification:
>> o It's a design mistake to move a business-logic decision
>>   into platform realization detail.
>> o I have currently two patches sets that would benefit from this work:
>>   Removing console_loglevel jumps in sysrq driver [1]
>>   Hung task warning before panic [2] - suggested by Tetsuo (but he
>>   probably didn't realise what it would involve).
>> o While doing (1), (2) the backtraces were adjusted to headers
>>   and other messages for each situation - so there won't be a situation
>>   when the backtrace is printed, but the headers are missing because
>>   they have lesser log level (or the reverse).
>> o As the result in (2) plays with console_loglevel for kdb are removed.
> 
> I really don't understand that word salad. Why are you doing this?
> 

Sorry, I should have tried to describe better.

I'm trying to remove external users of console_loglevel by following
reasons:
- changing console_loglevel on SMP means that unwanted messages from
other CPUs will appear (that have lower log level)
- on UMP unwanted messages may appear if the code is preempted while it
hasn't set the console_loglevel back to old
- rising console_loglevel to print wanted message(s) may not work at all
if printk() has being delayed and the console_loglevel is already set
back to old value

Sysrq driver changes console_loglevel because it needs to print message
with a specific log level (the code said userspace relies on this).
Kdb changes console_loglevel to print backtrace as the log level depends
on architecture realisation.

I also have patches in wip those needs to print backtrace with specific
loglevel (higher when it's critical, lower when it's notice and
shouldn't go to serial console).

Besides on local tests I see hits those have headers (messages like
"Backtrace: ") without an actual backtrace and the reverse - a backtrace
without a reason for it. It's quite annoying and worth addressing by
syncing headers log levels to backtraces.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 05/50] arm: Add loglvl to unwind_backtrace()
  2019-11-06  9:12     ` Russell King - ARM Linux admin
@ 2019-11-06 16:32       ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:32 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Will Deacon, linux-arm-kernel,
	clang-built-linux

On 11/6/19 9:12 AM, Russell King - ARM Linux admin wrote:
> On Wed, Nov 06, 2019 at 03:04:56AM +0000, Dmitry Safonov wrote:
>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>> index 7c3f32b26585..69e35462c9e9 100644
>> --- a/arch/arm/kernel/traps.c
>> +++ b/arch/arm/kernel/traps.c
>> @@ -202,7 +202,7 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
>>  #ifdef CONFIG_ARM_UNWIND
>>  static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>>  {
>> -	unwind_backtrace(regs, tsk);
>> +	unwind_backtrace(regs, tsk, KERN_DEBUG);
> 
> Why demote this to debug level?  This is used as part of the kernel
> panic message, surely we don't want this at debug level?  What about
> the non-unwind version?

Right, I wanted to keep the old loglevel in this patch - KERN_DEFAULT.
But got confused with log level in unwind_backtrace().
Will fix.

[..]
>> diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
>> index 0a65005e10f0..caaae1b6f721 100644
>> --- a/arch/arm/kernel/unwind.c
>> +++ b/arch/arm/kernel/unwind.c
>> @@ -455,11 +455,12 @@ int unwind_frame(struct stackframe *frame)
>>  	return URC_OK;
>>  }
>>  
>> -void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>> +void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
>> +		      const char *loglvl)
>>  {
>>  	struct stackframe frame;
>>  
>> -	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
>> +	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);
> 
> Clearly, this isn't supposed to be part of the normal backtrace output...

Yes, sorry it's debug for a backtrace - will return pr_debug() for the
message.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 05/50] arm: Add loglvl to unwind_backtrace()
@ 2019-11-06 16:32       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:32 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Petr Mladek, clang-built-linux, Tetsuo Handa, Greg Kroah-Hartman,
	Dmitry Safonov, linux-kernel, Steven Rostedt, Sergey Senozhatsky,
	Jiri Slaby, Andrew Morton, Will Deacon, Ingo Molnar,
	linux-arm-kernel

On 11/6/19 9:12 AM, Russell King - ARM Linux admin wrote:
> On Wed, Nov 06, 2019 at 03:04:56AM +0000, Dmitry Safonov wrote:
>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>> index 7c3f32b26585..69e35462c9e9 100644
>> --- a/arch/arm/kernel/traps.c
>> +++ b/arch/arm/kernel/traps.c
>> @@ -202,7 +202,7 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
>>  #ifdef CONFIG_ARM_UNWIND
>>  static inline void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>>  {
>> -	unwind_backtrace(regs, tsk);
>> +	unwind_backtrace(regs, tsk, KERN_DEBUG);
> 
> Why demote this to debug level?  This is used as part of the kernel
> panic message, surely we don't want this at debug level?  What about
> the non-unwind version?

Right, I wanted to keep the old loglevel in this patch - KERN_DEFAULT.
But got confused with log level in unwind_backtrace().
Will fix.

[..]
>> diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
>> index 0a65005e10f0..caaae1b6f721 100644
>> --- a/arch/arm/kernel/unwind.c
>> +++ b/arch/arm/kernel/unwind.c
>> @@ -455,11 +455,12 @@ int unwind_frame(struct stackframe *frame)
>>  	return URC_OK;
>>  }
>>  
>> -void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>> +void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
>> +		      const char *loglvl)
>>  {
>>  	struct stackframe frame;
>>  
>> -	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
>> +	printk("%s%s(regs = %p tsk = %p)\n", loglvl, __func__, regs, tsk);
> 
> Clearly, this isn't supposed to be part of the normal backtrace output...

Yes, sorry it's debug for a backtrace - will return pr_debug() for the
message.

Thanks,
          Dmitry

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 01/50] kallsyms/printk: Add loglvl to print_ip_sym()
  2019-11-06  4:38     ` Sergey Senozhatsky
@ 2019-11-06 16:39       ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:39 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv

Hi Sergey,

On 11/6/19 4:38 AM, Sergey Senozhatsky wrote:
> On (19/11/06 03:04), Dmitry Safonov wrote:
> [..]
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index dd05a378631a..774ff0d8dfe9 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -3858,7 +3858,7 @@ static noinline void __schedule_bug(struct task_struct *prev)
>>  	if (IS_ENABLED(CONFIG_DEBUG_PREEMPT)
>>  	    && in_atomic_preempt_off()) {
>>  		pr_err("Preemption disabled at:");
>> -		print_ip_sym(preempt_disable_ip);
>> +		print_ip_sym(KERN_ERR, preempt_disable_ip);
>>  		pr_cont("\n");
> 
> Is this working with pr_cont()?

print_ip_sym() will cause log_store()..
And pr_cont("\n") will go here:
:	/* Skip empty continuation lines that couldn't be added - they just
flush */
:	if (!text_len && (lflags & LOG_CONT))
:		return 0;

So it doesn't do anything. I didn't want to change any behavior in the
patch, but seems that I can remove this pr_cont() while at here.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 01/50] kallsyms/printk: Add loglvl to print_ip_sym()
@ 2019-11-06 16:39       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-06 16:39 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, Tetsuo Handa, James Hogan, Dmitry Safonov,
	linux-mips, Ben Segall, linux-riscv, Vincent Chen, Will Deacon,
	Ingo Molnar, Vincent Guittot, Paul Burton, Peter Zijlstra,
	Ingo Molnar, Mel Gorman, Jiri Slaby, Petr Mladek, Albert Ou,
	Steven Rostedt, Greentime Hu, Paul Walmsley, Thomas Gleixner,
	Dietmar Eggemann, Michal Simek, Greg Kroah-Hartman, linux-kernel,
	Ralf Baechle, Sergey Senozhatsky, Palmer Dabbelt, Andrew Morton

Hi Sergey,

On 11/6/19 4:38 AM, Sergey Senozhatsky wrote:
> On (19/11/06 03:04), Dmitry Safonov wrote:
> [..]
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index dd05a378631a..774ff0d8dfe9 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -3858,7 +3858,7 @@ static noinline void __schedule_bug(struct task_struct *prev)
>>  	if (IS_ENABLED(CONFIG_DEBUG_PREEMPT)
>>  	    && in_atomic_preempt_off()) {
>>  		pr_err("Preemption disabled at:");
>> -		print_ip_sym(preempt_disable_ip);
>> +		print_ip_sym(KERN_ERR, preempt_disable_ip);
>>  		pr_cont("\n");
> 
> Is this working with pr_cont()?

print_ip_sym() will cause log_store()..
And pr_cont("\n") will go here:
:	/* Skip empty continuation lines that couldn't be added - they just
flush */
:	if (!text_len && (lflags & LOG_CONT))
:		return 0;

So it doesn't do anything. I didn't want to change any behavior in the
patch, but seems that I can remove this pr_cont() while at here.

Thanks,
          Dmitry

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 43/50] xtensa: Add show_stack_loglvl()
  2019-11-06  8:15     ` Petr Mladek
  2019-11-06 16:06       ` Dmitry Safonov
@ 2019-11-06 16:44       ` Max Filippov
  1 sibling, 0 replies; 323+ messages in thread
From: Max Filippov @ 2019-11-06 16:44 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Dmitry Safonov, LKML, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Chris Zankel,
	open list:TENSILICA XTENSA PORT (xtensa)

On Wed, Nov 6, 2019 at 12:15 AM Petr Mladek <pmladek@suse.com> wrote:
> > >         for (i = 0; i < kstack_depth_to_print; i++) {
> > >                 if (kstack_end(sp))
> > >                         break;
> > > -               pr_cont(" %08lx", *sp++);
> > > +               printk("%s %08lx", loglvl, *sp++);
>
> KERN_CONT can be combined with any other loglevel.
> So you could keep using pr_cont() together with explicit loglevel:
>
>                         pr_cont("%s %08lx", loglvl, *sp++);
>
> It should fix the problems reported below.
>
> Well, the preferred solution would be to snprintf() the continuous
> line into a temporary buffer. And printk() it when it is complete.
> pr_cont() is not reliable when more CPUs print at the same time.

Good point. Let me do this cleanup.

-- 
Thanks.
-- Max

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06 16:27     ` Dmitry Safonov
                         ` (3 preceding siblings ...)
  (?)
@ 2019-11-06 20:34       ` Peter Zijlstra
  -1 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06 20:34 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> Hi Peter,
> 
> On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> >> Add log level argument to show_stack().
> >> Done in three stages:
> >> 1. Introducing show_stack_loglvl() for every architecture
> >> 2. Migrating old users with an explicit log level
> >> 3. Renaming show_stack_loglvl() into show_stack()
> >>
> >> Justification:
> >> o It's a design mistake to move a business-logic decision
> >>   into platform realization detail.
> >> o I have currently two patches sets that would benefit from this work:
> >>   Removing console_loglevel jumps in sysrq driver [1]
> >>   Hung task warning before panic [2] - suggested by Tetsuo (but he
> >>   probably didn't realise what it would involve).
> >> o While doing (1), (2) the backtraces were adjusted to headers
> >>   and other messages for each situation - so there won't be a situation
> >>   when the backtrace is printed, but the headers are missing because
> >>   they have lesser log level (or the reverse).
> >> o As the result in (2) plays with console_loglevel for kdb are removed.
> > 
> > I really don't understand that word salad. Why are you doing this?
> > 
> 
> Sorry, I should have tried to describe better.
> 
> I'm trying to remove external users of console_loglevel by following
> reasons:

I suppose since all my machines have 'debug ignore_loglevel
earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
experience.

> - changing console_loglevel on SMP means that unwanted messages from
> other CPUs will appear (that have lower log level)
> - on UMP unwanted messages may appear if the code is preempted while it
> hasn't set the console_loglevel back to old
> - rising console_loglevel to print wanted message(s) may not work at all
> if printk() has being delayed and the console_loglevel is already set
> back to old value

Sure, frobbing the global console_loglevel is bad.

> I also have patches in wip those needs to print backtrace with specific
> loglevel (higher when it's critical, lower when it's notice and
> shouldn't go to serial console).

(everything always should go to serial, serial is awesome :-)

> Besides on local tests I see hits those have headers (messages like
> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> without a reason for it. It's quite annoying and worth addressing by
> syncing headers log levels to backtraces.

I suppose I'm surprised there are backtraces that are not important.
Either badness happened and it needs printing, or the user asked for it
and it needs printing.

Perhaps we should be removing backtraces if they're not important
instead of allowing to print them as lower loglevels?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 20:34       ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06 20:34 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> Hi Peter,
> 
> On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> >> Add log level argument to show_stack().
> >> Done in three stages:
> >> 1. Introducing show_stack_loglvl() for every architecture
> >> 2. Migrating old users with an explicit log level
> >> 3. Renaming show_stack_loglvl() into show_stack()
> >>
> >> Justification:
> >> o It's a design mistake to move a business-logic decision
> >>   into platform realization detail.
> >> o I have currently two patches sets that would benefit from this work:
> >>   Removing console_loglevel jumps in sysrq driver [1]
> >>   Hung task warning before panic [2] - suggested by Tetsuo (but he
> >>   probably didn't realise what it would involve).
> >> o While doing (1), (2) the backtraces were adjusted to headers
> >>   and other messages for each situation - so there won't be a situation
> >>   when the backtrace is printed, but the headers are missing because
> >>   they have lesser log level (or the reverse).
> >> o As the result in (2) plays with console_loglevel for kdb are removed.
> > 
> > I really don't understand that word salad. Why are you doing this?
> > 
> 
> Sorry, I should have tried to describe better.
> 
> I'm trying to remove external users of console_loglevel by following
> reasons:

I suppose since all my machines have 'debug ignore_loglevel
earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
experience.

> - changing console_loglevel on SMP means that unwanted messages from
> other CPUs will appear (that have lower log level)
> - on UMP unwanted messages may appear if the code is preempted while it
> hasn't set the console_loglevel back to old
> - rising console_loglevel to print wanted message(s) may not work at all
> if printk() has being delayed and the console_loglevel is already set
> back to old value

Sure, frobbing the global console_loglevel is bad.

> I also have patches in wip those needs to print backtrace with specific
> loglevel (higher when it's critical, lower when it's notice and
> shouldn't go to serial console).

(everything always should go to serial, serial is awesome :-)

> Besides on local tests I see hits those have headers (messages like
> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> without a reason for it. It's quite annoying and worth addressing by
> syncing headers log levels to backtraces.

I suppose I'm surprised there are backtraces that are not important.
Either badness happened and it needs printing, or the user asked for it
and it needs printing.

Perhaps we should be removing backtraces if they're not important
instead of allowing to print them as lower loglevels?

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 20:34       ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06 20:34 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> Hi Peter,
> 
> On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> >> Add log level argument to show_stack().
> >> Done in three stages:
> >> 1. Introducing show_stack_loglvl() for every architecture
> >> 2. Migrating old users with an explicit log level
> >> 3. Renaming show_stack_loglvl() into show_stack()
> >>
> >> Justification:
> >> o It's a design mistake to move a business-logic decision
> >>   into platform realization detail.
> >> o I have currently two patches sets that would benefit from this work:
> >>   Removing console_loglevel jumps in sysrq driver [1]
> >>   Hung task warning before panic [2] - suggested by Tetsuo (but he
> >>   probably didn't realise what it would involve).
> >> o While doing (1), (2) the backtraces were adjusted to headers
> >>   and other messages for each situation - so there won't be a situation
> >>   when the backtrace is printed, but the headers are missing because
> >>   they have lesser log level (or the reverse).
> >> o As the result in (2) plays with console_loglevel for kdb are removed.
> > 
> > I really don't understand that word salad. Why are you doing this?
> > 
> 
> Sorry, I should have tried to describe better.
> 
> I'm trying to remove external users of console_loglevel by following
> reasons:

I suppose since all my machines have 'debug ignore_loglevel
earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
experience.

> - changing console_loglevel on SMP means that unwanted messages from
> other CPUs will appear (that have lower log level)
> - on UMP unwanted messages may appear if the code is preempted while it
> hasn't set the console_loglevel back to old
> - rising console_loglevel to print wanted message(s) may not work at all
> if printk() has being delayed and the console_loglevel is already set
> back to old value

Sure, frobbing the global console_loglevel is bad.

> I also have patches in wip those needs to print backtrace with specific
> loglevel (higher when it's critical, lower when it's notice and
> shouldn't go to serial console).

(everything always should go to serial, serial is awesome :-)

> Besides on local tests I see hits those have headers (messages like
> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> without a reason for it. It's quite annoying and worth addressing by
> syncing headers log levels to backtraces.

I suppose I'm surprised there are backtraces that are not important.
Either badness happened and it needs printing, or the user asked for it
and it needs printing.

Perhaps we should be removing backtraces if they're not important
instead of allowing to print them as lower loglevels?

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 20:34       ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06 20:34 UTC (permalink / raw)
  To: openrisc

On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> Hi Peter,
> 
> On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> >> Add log level argument to show_stack().
> >> Done in three stages:
> >> 1. Introducing show_stack_loglvl() for every architecture
> >> 2. Migrating old users with an explicit log level
> >> 3. Renaming show_stack_loglvl() into show_stack()
> >>
> >> Justification:
> >> o It's a design mistake to move a business-logic decision
> >>   into platform realization detail.
> >> o I have currently two patches sets that would benefit from this work:
> >>   Removing console_loglevel jumps in sysrq driver [1]
> >>   Hung task warning before panic [2] - suggested by Tetsuo (but he
> >>   probably didn't realise what it would involve).
> >> o While doing (1), (2) the backtraces were adjusted to headers
> >>   and other messages for each situation - so there won't be a situation
> >>   when the backtrace is printed, but the headers are missing because
> >>   they have lesser log level (or the reverse).
> >> o As the result in (2) plays with console_loglevel for kdb are removed.
> > 
> > I really don't understand that word salad. Why are you doing this?
> > 
> 
> Sorry, I should have tried to describe better.
> 
> I'm trying to remove external users of console_loglevel by following
> reasons:

I suppose since all my machines have 'debug ignore_loglevel
earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
experience.

> - changing console_loglevel on SMP means that unwanted messages from
> other CPUs will appear (that have lower log level)
> - on UMP unwanted messages may appear if the code is preempted while it
> hasn't set the console_loglevel back to old
> - rising console_loglevel to print wanted message(s) may not work at all
> if printk() has being delayed and the console_loglevel is already set
> back to old value

Sure, frobbing the global console_loglevel is bad.

> I also have patches in wip those needs to print backtrace with specific
> loglevel (higher when it's critical, lower when it's notice and
> shouldn't go to serial console).

(everything always should go to serial, serial is awesome :-)

> Besides on local tests I see hits those have headers (messages like
> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> without a reason for it. It's quite annoying and worth addressing by
> syncing headers log levels to backtraces.

I suppose I'm surprised there are backtraces that are not important.
Either badness happened and it needs printing, or the user asked for it
and it needs printing.

Perhaps we should be removing backtraces if they're not important
instead of allowing to print them as lower loglevels?

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 20:34       ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06 20:34 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> Hi Peter,
> 
> On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> >> Add log level argument to show_stack().
> >> Done in three stages:
> >> 1. Introducing show_stack_loglvl() for every architecture
> >> 2. Migrating old users with an explicit log level
> >> 3. Renaming show_stack_loglvl() into show_stack()
> >>
> >> Justification:
> >> o It's a design mistake to move a business-logic decision
> >>   into platform realization detail.
> >> o I have currently two patches sets that would benefit from this work:
> >>   Removing console_loglevel jumps in sysrq driver [1]
> >>   Hung task warning before panic [2] - suggested by Tetsuo (but he
> >>   probably didn't realise what it would involve).
> >> o While doing (1), (2) the backtraces were adjusted to headers
> >>   and other messages for each situation - so there won't be a situation
> >>   when the backtrace is printed, but the headers are missing because
> >>   they have lesser log level (or the reverse).
> >> o As the result in (2) plays with console_loglevel for kdb are removed.
> > 
> > I really don't understand that word salad. Why are you doing this?
> > 
> 
> Sorry, I should have tried to describe better.
> 
> I'm trying to remove external users of console_loglevel by following
> reasons:

I suppose since all my machines have 'debug ignore_loglevel
earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
experience.

> - changing console_loglevel on SMP means that unwanted messages from
> other CPUs will appear (that have lower log level)
> - on UMP unwanted messages may appear if the code is preempted while it
> hasn't set the console_loglevel back to old
> - rising console_loglevel to print wanted message(s) may not work at all
> if printk() has being delayed and the console_loglevel is already set
> back to old value

Sure, frobbing the global console_loglevel is bad.

> I also have patches in wip those needs to print backtrace with specific
> loglevel (higher when it's critical, lower when it's notice and
> shouldn't go to serial console).

(everything always should go to serial, serial is awesome :-)

> Besides on local tests I see hits those have headers (messages like
> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> without a reason for it. It's quite annoying and worth addressing by
> syncing headers log levels to backtraces.

I suppose I'm surprised there are backtraces that are not important.
Either badness happened and it needs printing, or the user asked for it
and it needs printing.

Perhaps we should be removing backtraces if they're not important
instead of allowing to print them as lower loglevels?

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 20:34       ` Peter Zijlstra
  0 siblings, 0 replies; 323+ messages in thread
From: Peter Zijlstra @ 2019-11-06 20:34 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> Hi Peter,
> 
> On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
> >> Add log level argument to show_stack().
> >> Done in three stages:
> >> 1. Introducing show_stack_loglvl() for every architecture
> >> 2. Migrating old users with an explicit log level
> >> 3. Renaming show_stack_loglvl() into show_stack()
> >>
> >> Justification:
> >> o It's a design mistake to move a business-logic decision
> >>   into platform realization detail.
> >> o I have currently two patches sets that would benefit from this work:
> >>   Removing console_loglevel jumps in sysrq driver [1]
> >>   Hung task warning before panic [2] - suggested by Tetsuo (but he
> >>   probably didn't realise what it would involve).
> >> o While doing (1), (2) the backtraces were adjusted to headers
> >>   and other messages for each situation - so there won't be a situation
> >>   when the backtrace is printed, but the headers are missing because
> >>   they have lesser log level (or the reverse).
> >> o As the result in (2) plays with console_loglevel for kdb are removed.
> > 
> > I really don't understand that word salad. Why are you doing this?
> > 
> 
> Sorry, I should have tried to describe better.
> 
> I'm trying to remove external users of console_loglevel by following
> reasons:

I suppose since all my machines have 'debug ignore_loglevel
earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
experience.

> - changing console_loglevel on SMP means that unwanted messages from
> other CPUs will appear (that have lower log level)
> - on UMP unwanted messages may appear if the code is preempted while it
> hasn't set the console_loglevel back to old
> - rising console_loglevel to print wanted message(s) may not work at all
> if printk() has being delayed and the console_loglevel is already set
> back to old value

Sure, frobbing the global console_loglevel is bad.

> I also have patches in wip those needs to print backtrace with specific
> loglevel (higher when it's critical, lower when it's notice and
> shouldn't go to serial console).

(everything always should go to serial, serial is awesome :-)

> Besides on local tests I see hits those have headers (messages like
> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> without a reason for it. It's quite annoying and worth addressing by
> syncing headers log levels to backtraces.

I suppose I'm surprised there are backtraces that are not important.
Either badness happened and it needs printing, or the user asked for it
and it needs printing.

Perhaps we should be removing backtraces if they're not important
instead of allowing to print them as lower loglevels?

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06 20:34       ` Peter Zijlstra
                           ` (3 preceding siblings ...)
  (?)
@ 2019-11-06 23:25         ` Russell King - ARM Linux admin
  -1 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-06 23:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, clang-built-linux, Ingo Molnar,
	Mark Salter, Albert Ou, Stefan Kristiansson, openrisc,
	Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Or utterly meaningless.

> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Definitely!  WARN_ON() is well overused - and as is typical, used
without much thought.  Bound to happen after Linus got shirty about
BUG_ON() being over used.  Everyone just grabbed the next nearest thing
to assert().

As a kind of example, I've recently come across one WARN_ON() in a
driver subsystem (that shall remain nameless at the moment) which very
likely has multiple different devices on a platform.  The WARN_ON()
triggers as a result of a problem with the hardware, but because it's a
WARN_ON(), you've no idea which device has a problem.  The backtrace is
mostly meaningless.  So you know that a problem has occurred, but the
kernel prints *useless* backtrace to let you know, and totally omits
the *useful* information.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 23:25         ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-06 23:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Petr Mladek, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Or utterly meaningless.

> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Definitely!  WARN_ON() is well overused - and as is typical, used
without much thought.  Bound to happen after Linus got shirty about
BUG_ON() being over used.  Everyone just grabbed the next nearest thing
to assert().

As a kind of example, I've recently come across one WARN_ON() in a
driver subsystem (that shall remain nameless at the moment) which very
likely has multiple different devices on a platform.  The WARN_ON()
triggers as a result of a problem with the hardware, but because it's a
WARN_ON(), you've no idea which device has a problem.  The backtrace is
mostly meaningless.  So you know that a problem has occurred, but the
kernel prints *useless* backtrace to let you know, and totally omits
the *useful* information.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 23:25         ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-06 23:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, clang-built-linux, Ingo Molnar,
	Mark Salter, Albert Ou, Stefan Kristiansson, openrisc,
	Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Or utterly meaningless.

> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Definitely!  WARN_ON() is well overused - and as is typical, used
without much thought.  Bound to happen after Linus got shirty about
BUG_ON() being over used.  Everyone just grabbed the next nearest thing
to assert().

As a kind of example, I've recently come across one WARN_ON() in a
driver subsystem (that shall remain nameless at the moment) which very
likely has multiple different devices on a platform.  The WARN_ON()
triggers as a result of a problem with the hardware, but because it's a
WARN_ON(), you've no idea which device has a problem.  The backtrace is
mostly meaningless.  So you know that a problem has occurred, but the
kernel prints *useless* backtrace to let you know, and totally omits
the *useful* information.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 23:25         ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-06 23:25 UTC (permalink / raw)
  To: openrisc

On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Or utterly meaningless.

> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Definitely!  WARN_ON() is well overused - and as is typical, used
without much thought.  Bound to happen after Linus got shirty about
BUG_ON() being over used.  Everyone just grabbed the next nearest thing
to assert().

As a kind of example, I've recently come across one WARN_ON() in a
driver subsystem (that shall remain nameless at the moment) which very
likely has multiple different devices on a platform.  The WARN_ON()
triggers as a result of a problem with the hardware, but because it's a
WARN_ON(), you've no idea which device has a problem.  The backtrace is
mostly meaningless.  So you know that a problem has occurred, but the
kernel prints *useless* backtrace to let you know, and totally omits
the *useful* information.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 23:25         ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-06 23:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, clang-built-linux, Ingo Molnar,
	Mark Salter, Albert Ou, Stefan Kristiansson, openrisc,
	Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Or utterly meaningless.

> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Definitely!  WARN_ON() is well overused - and as is typical, used
without much thought.  Bound to happen after Linus got shirty about
BUG_ON() being over used.  Everyone just grabbed the next nearest thing
to assert().

As a kind of example, I've recently come across one WARN_ON() in a
driver subsystem (that shall remain nameless at the moment) which very
likely has multiple different devices on a platform.  The WARN_ON()
triggers as a result of a problem with the hardware, but because it's a
WARN_ON(), you've no idea which device has a problem.  The backtrace is
mostly meaningless.  So you know that a problem has occurred, but the
kernel prints *useless* backtrace to let you know, and totally omits
the *useful* information.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-06 23:25         ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-06 23:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Or utterly meaningless.

> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Definitely!  WARN_ON() is well overused - and as is typical, used
without much thought.  Bound to happen after Linus got shirty about
BUG_ON() being over used.  Everyone just grabbed the next nearest thing
to assert().

As a kind of example, I've recently come across one WARN_ON() in a
driver subsystem (that shall remain nameless at the moment) which very
likely has multiple different devices on a platform.  The WARN_ON()
triggers as a result of a problem with the hardware, but because it's a
WARN_ON(), you've no idea which device has a problem.  The backtrace is
mostly meaningless.  So you know that a problem has occurred, but the
kernel prints *useless* backtrace to let you know, and totally omits
the *useful* information.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06 23:25         ` Russell King - ARM Linux admin
                           ` (4 preceding siblings ...)
  (?)
@ 2019-11-07  7:27         ` Geert Uytterhoeven
  -1 siblings, 0 replies; 323+ messages in thread
From: Geert Uytterhoeven @ 2019-11-07  7:27 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Linux Kernel Mailing List, Andy Whitcroft, Joe Perches,
	Dmitry Safonov, Petr Mladek, Peter Zijlstra

Hi Russell,

(reduced CC list)

On Thu, Nov 7, 2019 at 12:28 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.
>
> Or utterly meaningless.
>
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?
>
> Definitely!  WARN_ON() is well overused - and as is typical, used
> without much thought.  Bound to happen after Linus got shirty about
> BUG_ON() being over used.  Everyone just grabbed the next nearest thing
> to assert().

Which is what checkpatch.pl suggests...

> As a kind of example, I've recently come across one WARN_ON() in a
> driver subsystem (that shall remain nameless at the moment) which very
> likely has multiple different devices on a platform.  The WARN_ON()
> triggers as a result of a problem with the hardware, but because it's a
> WARN_ON(), you've no idea which device has a problem.  The backtrace is
> mostly meaningless.  So you know that a problem has occurred, but the
> kernel prints *useless* backtrace to let you know, and totally omits
> the *useful* information.

So that callsite should be converted to use dev_WARN(), with a suitable
message.

Perhaps checkpatch should be updated, to suggest {,dev_}WARN()
instead of WARN_ON(), and add a check for the latter, too?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 18/50] microblaze: Add loglvl to microblaze_unwind_inner()
  2019-11-06  3:05 ` [PATCH 18/50] microblaze: Add loglvl to microblaze_unwind_inner() Dmitry Safonov
@ 2019-11-07  8:59   ` Michal Simek
  2019-11-08  7:52     ` kbuild test robot
  1 sibling, 0 replies; 323+ messages in thread
From: Michal Simek @ 2019-11-07  8:59 UTC (permalink / raw)
  To: Dmitry Safonov, linux-kernel
  Cc: Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman, Ingo Molnar,
	Jiri Slaby, Petr Mladek, Sergey Senozhatsky, Steven Rostedt,
	Tetsuo Handa


[-- Attachment #1.1: Type: text/plain, Size: 6844 bytes --]

On 06. 11. 19 4:05, Dmitry Safonov wrote:
> Currently, the log-level of show_stack() depends on a platform
> realization. It creates situations where the headers are printed with
> lower log level or higher than the stacktrace (depending on
> a platform or user).
> 
> Furthermore, it forces the logic decision from user to an architecture
> side. In result, some users as sysrq/kdb/etc are doing tricks with
> temporary rising console_loglevel while printing their messages.
> And in result it not only may print unwanted messages from other CPUs,
> but also omit printing at all in the unlucky case where the printk()
> was deferred.
> 
> Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems
> an easier approach than introducing more printk buffers.
> Also, it will consolidate printings with headers.
> 
> Add log level argument to microblaze_unwind_inner() as a preparation for
> introducing show_stack_loglvl().
> 
> Cc: Michal Simek <monstr@monstr.eu>
> [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> ---
>  arch/microblaze/kernel/unwind.c | 35 ++++++++++++++++++++-------------
>  1 file changed, 21 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/microblaze/kernel/unwind.c b/arch/microblaze/kernel/unwind.c
> index 4241cdd28ee7..9a7343feadf5 100644
> --- a/arch/microblaze/kernel/unwind.c
> +++ b/arch/microblaze/kernel/unwind.c
> @@ -162,16 +162,18 @@ static void microblaze_unwind_inner(struct task_struct *task,
>   */
>  #ifdef CONFIG_MMU
>  static inline void unwind_trap(struct task_struct *task, unsigned long pc,
> -				unsigned long fp, struct stack_trace *trace)
> +				unsigned long fp, struct stack_trace *trace,
> +				const char *loglvl)
>  {
>  	/* To be implemented */
>  }
>  #else
>  static inline void unwind_trap(struct task_struct *task, unsigned long pc,
> -				unsigned long fp, struct stack_trace *trace)
> +				unsigned long fp, struct stack_trace *trace,
> +				const char *loglvl)
>  {
>  	const struct pt_regs *regs = (const struct pt_regs *) fp;
> -	microblaze_unwind_inner(task, regs->pc, regs->r1, regs->r15, trace);
> +	microblaze_unwind_inner(task, regs->pc, regs->r1, regs->r15, trace, loglvl);
>  }
>  #endif
>  
> @@ -184,11 +186,13 @@ static inline void unwind_trap(struct task_struct *task, unsigned long pc,
>   *				  the caller's return address.
>   * @trace : Where to store stack backtrace (PC values).
>   *	    NULL == print backtrace to kernel log
> + * @loglvl : Used for printk log level if (trace == NULL).
>   */
>  static void microblaze_unwind_inner(struct task_struct *task,
>  			     unsigned long pc, unsigned long fp,
>  			     unsigned long leaf_return,
> -			     struct stack_trace *trace)
> +			     struct stack_trace *trace,
> +			     const char *loglvl)
>  {
>  	int ofs = 0;
>  
> @@ -214,11 +218,11 @@ static void microblaze_unwind_inner(struct task_struct *task,
>  			const struct pt_regs *regs =
>  				(const struct pt_regs *) fp;
>  #endif
> -			pr_info("HW EXCEPTION\n");
> +			printk("%sHW EXCEPTION\n", loglvl);
>  #ifndef CONFIG_MMU
>  			microblaze_unwind_inner(task, regs->r17 - 4,
>  						fp + EX_HANDLER_STACK_SIZ,
> -						regs->r15, trace);
> +						regs->r15, trace, loglvl);
>  #endif
>  			return;
>  		}
> @@ -228,8 +232,8 @@ static void microblaze_unwind_inner(struct task_struct *task,
>  			if ((return_to >= handler->start_addr)
>  			    && (return_to <= handler->end_addr)) {
>  				if (!trace)
> -					pr_info("%s\n", handler->trap_name);
> -				unwind_trap(task, pc, fp, trace);
> +					printk("%s%s\n", loglvl, handler->trap_name);
> +				unwind_trap(task, pc, fp, trace, loglvl);
>  				return;
>  			}
>  		}
> @@ -248,13 +252,13 @@ static void microblaze_unwind_inner(struct task_struct *task,
>  		} else {
>  			/* Have we reached userland? */
>  			if (unlikely(pc == task_pt_regs(task)->pc)) {
> -				pr_info("[<%p>] PID %lu [%s]\n",
> -					(void *) pc,
> +				printk("%s[<%p>] PID %lu [%s]\n",
> +					loglvl, (void *) pc,
>  					(unsigned long) task->pid,
>  					task->comm);
>  				break;
>  			} else
> -				print_ip_sym(KERN_INFO, pc);
> +				print_ip_sym(loglvl, pc);
>  		}
>  
>  		/* Stop when we reach anything not part of the kernel */
> @@ -285,11 +289,13 @@ static void microblaze_unwind_inner(struct task_struct *task,
>   */
>  void microblaze_unwind(struct task_struct *task, struct stack_trace *trace)
>  {
> +	const char *loglvl = KERN_INFO;
> +
>  	if (task) {
>  		if (task == current) {
>  			const struct pt_regs *regs = task_pt_regs(task);
>  			microblaze_unwind_inner(task, regs->pc, regs->r1,
> -						regs->r15, trace);
> +						regs->r15, trace, loglvl);
>  		} else {
>  			struct thread_info *thread_info =
>  				(struct thread_info *)(task->stack);
> @@ -299,7 +305,8 @@ void microblaze_unwind(struct task_struct *task, struct stack_trace *trace)
>  			microblaze_unwind_inner(task,
>  						(unsigned long) &_switch_to,
>  						cpu_context->r1,
> -						cpu_context->r15, trace);
> +						cpu_context->r15,
> +						trace, loglvl);
>  		}
>  	} else {
>  		unsigned long pc, fp;
> @@ -314,7 +321,7 @@ void microblaze_unwind(struct task_struct *task, struct stack_trace *trace)
>  		);
>  
>  		/* Since we are not a leaf function, use leaf_return = 0 */
> -		microblaze_unwind_inner(current, pc, fp, 0, trace);
> +		microblaze_unwind_inner(current, pc, fp, 0, trace, loglvl);
>  	}
>  }
>  
> 

I can't see any reaction from bots but you forget to update function
declaration there which is causing build issue.

here is c&p patch.
Other then this it looks good to me.

diff --git a/arch/microblaze/kernel/unwind.c
b/arch/microblaze/kernel/unwind.c
index 74dded96c10a..778a761af0a7 100644
--- a/arch/microblaze/kernel/unwind.c
+++ b/arch/microblaze/kernel/unwind.c
@@ -154,7 +154,8 @@ static int lookup_prev_stack_frame(unsigned long fp,
unsigned long pc,
 static void microblaze_unwind_inner(struct task_struct *task,
                                    unsigned long pc, unsigned long fp,
                                    unsigned long leaf_return,
-                                   struct stack_trace *trace);
+                                   struct stack_trace *trace,
+                                   const char *loglvl);

 /**
  * unwind_trap - Unwind through a system trap, that stored previous state

Thanks,
Michal




-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply related	[flat|nested] 323+ messages in thread

* Re: [PATCH 34/50] sparc: Add show_stack_loglvl()
  2019-11-06  3:05   ` Dmitry Safonov
  (?)
@ 2019-11-08  7:08     ` kbuild test robot
  -1 siblings, 0 replies; 323+ messages in thread
From: kbuild test robot @ 2019-11-08  7:08 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: kbuild-all, linux-kernel, Dmitry Safonov, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Petr Mladek, Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	David S. Miller, sparclinux

[-- Attachment #1: Type: text/plain, Size: 5835 bytes --]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.4-rc6 next-20191107]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kallsyms-printk-Add-loglvl-to-print_ip_sym/20191108-124037
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 847120f859cc45e074204f4cf33c8df069306eb2
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=sparc 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arch/sparc/kernel/process_32.c: In function 'show_stack_loglvl':
>> arch/sparc/kernel/process_32.c:160:7: error: 'tsk' undeclared (first use in this function); did you mean 'task'?
     if (!tsk)
          ^~~
          task
   arch/sparc/kernel/process_32.c:160:7: note: each undeclared identifier is reported only once for each function it appears in
>> arch/sparc/kernel/process_32.c:163:25: error: '_ksp' undeclared (first use in this function); did you mean 'sp'?
     if (tsk == current && !_ksp)
                            ^~~~
                            sp

vim +160 arch/sparc/kernel/process_32.c

^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  146  
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  147  /*
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  148   * The show_stack(), show_stack_loglvl() are external APIs which
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  149   * we do not use ourselves.
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  150   * The oops is printed in die_if_kernel.
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  151   */
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  152  void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  153  		       const char *loglvl)
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  154  {
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  155  	unsigned long pc, fp;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  156  	unsigned long task_base;
4d7b92ad572b4b arch/sparc/kernel/process_32.c Sam Ravnborg   2009-01-02  157  	struct reg_window32 *rw;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  158  	int count = 0;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  159  
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30 @160  	if (!tsk)
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  161  		tsk = current;
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  162  
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30 @163  	if (tsk == current && !_ksp)
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  164  		__asm__ __volatile__("mov	%%fp, %0" : "=r" (_ksp));
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  165  
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  166  	task_base = (unsigned long) task_stack_page(tsk);
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  167  	fp = (unsigned long) _ksp;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  168  	do {
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  169  		/* Bogus frame pointer? */
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  170  		if (fp < (task_base + sizeof(struct thread_info)) ||
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  171  		    fp >= (task_base + (PAGE_SIZE << 1)))
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  172  			break;
4d7b92ad572b4b arch/sparc/kernel/process_32.c Sam Ravnborg   2009-01-02  173  		rw = (struct reg_window32 *) fp;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  174  		pc = rw->ins[7];
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  175  		printk("%s[%08lx : ", loglvl, pc);
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  176  		printk("%s%pS ] ", loglvl, (void *) pc);
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  177  		fp = rw->ins[6];
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  178  	} while (++count < 16);
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  179  	printk("%s\n", loglvl);
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  180  }
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  181  

:::::: The code at line 160 was first introduced by commit
:::::: 89e3f23da9c827bfa9806c3d4da83a12c1c8543a sparc32: make show_stack() acquire %fp if @_ksp is not specified

:::::: TO: Tejun Heo <tj@kernel.org>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 12823 bytes --]

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 34/50] sparc: Add show_stack_loglvl()
@ 2019-11-08  7:08     ` kbuild test robot
  0 siblings, 0 replies; 323+ messages in thread
From: kbuild test robot @ 2019-11-08  7:08 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: kbuild-all, linux-kernel, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	David S. Miller, sparclinux

[-- Attachment #1: Type: text/plain, Size: 5835 bytes --]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.4-rc6 next-20191107]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kallsyms-printk-Add-loglvl-to-print_ip_sym/20191108-124037
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 847120f859cc45e074204f4cf33c8df069306eb2
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=sparc 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arch/sparc/kernel/process_32.c: In function 'show_stack_loglvl':
>> arch/sparc/kernel/process_32.c:160:7: error: 'tsk' undeclared (first use in this function); did you mean 'task'?
     if (!tsk)
          ^~~
          task
   arch/sparc/kernel/process_32.c:160:7: note: each undeclared identifier is reported only once for each function it appears in
>> arch/sparc/kernel/process_32.c:163:25: error: '_ksp' undeclared (first use in this function); did you mean 'sp'?
     if (tsk == current && !_ksp)
                            ^~~~
                            sp

vim +160 arch/sparc/kernel/process_32.c

^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  146  
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  147  /*
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  148   * The show_stack(), show_stack_loglvl() are external APIs which
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  149   * we do not use ourselves.
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  150   * The oops is printed in die_if_kernel.
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  151   */
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  152  void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  153  		       const char *loglvl)
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  154  {
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  155  	unsigned long pc, fp;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  156  	unsigned long task_base;
4d7b92ad572b4b arch/sparc/kernel/process_32.c Sam Ravnborg   2009-01-02  157  	struct reg_window32 *rw;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  158  	int count = 0;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  159  
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30 @160  	if (!tsk)
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  161  		tsk = current;
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  162  
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30 @163  	if (tsk == current && !_ksp)
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  164  		__asm__ __volatile__("mov	%%fp, %0" : "=r" (_ksp));
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  165  
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  166  	task_base = (unsigned long) task_stack_page(tsk);
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  167  	fp = (unsigned long) _ksp;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  168  	do {
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  169  		/* Bogus frame pointer? */
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  170  		if (fp < (task_base + sizeof(struct thread_info)) ||
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  171  		    fp >= (task_base + (PAGE_SIZE << 1)))
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  172  			break;
4d7b92ad572b4b arch/sparc/kernel/process_32.c Sam Ravnborg   2009-01-02  173  		rw = (struct reg_window32 *) fp;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  174  		pc = rw->ins[7];
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  175  		printk("%s[%08lx : ", loglvl, pc);
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  176  		printk("%s%pS ] ", loglvl, (void *) pc);
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  177  		fp = rw->ins[6];
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  178  	} while (++count < 16);
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  179  	printk("%s\n", loglvl);
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  180  }
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  181  

:::::: The code at line 160 was first introduced by commit
:::::: 89e3f23da9c827bfa9806c3d4da83a12c1c8543a sparc32: make show_stack() acquire %fp if @_ksp is not specified

:::::: TO: Tejun Heo <tj@kernel.org>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 12823 bytes --]

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 34/50] sparc: Add show_stack_loglvl()
@ 2019-11-08  7:08     ` kbuild test robot
  0 siblings, 0 replies; 323+ messages in thread
From: kbuild test robot @ 2019-11-08  7:08 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 5918 bytes --]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.4-rc6 next-20191107]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kallsyms-printk-Add-loglvl-to-print_ip_sym/20191108-124037
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 847120f859cc45e074204f4cf33c8df069306eb2
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=sparc 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arch/sparc/kernel/process_32.c: In function 'show_stack_loglvl':
>> arch/sparc/kernel/process_32.c:160:7: error: 'tsk' undeclared (first use in this function); did you mean 'task'?
     if (!tsk)
          ^~~
          task
   arch/sparc/kernel/process_32.c:160:7: note: each undeclared identifier is reported only once for each function it appears in
>> arch/sparc/kernel/process_32.c:163:25: error: '_ksp' undeclared (first use in this function); did you mean 'sp'?
     if (tsk == current && !_ksp)
                            ^~~~
                            sp

vim +160 arch/sparc/kernel/process_32.c

^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  146  
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  147  /*
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  148   * The show_stack(), show_stack_loglvl() are external APIs which
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  149   * we do not use ourselves.
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  150   * The oops is printed in die_if_kernel.
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  151   */
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  152  void show_stack_loglvl(struct task_struct *task, unsigned long *sp,
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  153  		       const char *loglvl)
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  154  {
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  155  	unsigned long pc, fp;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  156  	unsigned long task_base;
4d7b92ad572b4b arch/sparc/kernel/process_32.c Sam Ravnborg   2009-01-02  157  	struct reg_window32 *rw;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  158  	int count = 0;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  159  
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30 @160  	if (!tsk)
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  161  		tsk = current;
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  162  
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30 @163  	if (tsk == current && !_ksp)
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  164  		__asm__ __volatile__("mov	%%fp, %0" : "=r" (_ksp));
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  165  
89e3f23da9c827 arch/sparc/kernel/process_32.c Tejun Heo      2013-04-30  166  	task_base = (unsigned long) task_stack_page(tsk);
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  167  	fp = (unsigned long) _ksp;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  168  	do {
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  169  		/* Bogus frame pointer? */
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  170  		if (fp < (task_base + sizeof(struct thread_info)) ||
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  171  		    fp >= (task_base + (PAGE_SIZE << 1)))
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  172  			break;
4d7b92ad572b4b arch/sparc/kernel/process_32.c Sam Ravnborg   2009-01-02  173  		rw = (struct reg_window32 *) fp;
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  174  		pc = rw->ins[7];
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  175  		printk("%s[%08lx : ", loglvl, pc);
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  176  		printk("%s%pS ] ", loglvl, (void *) pc);
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  177  		fp = rw->ins[6];
^1da177e4c3f41 arch/sparc/kernel/process.c    Linus Torvalds 2005-04-16  178  	} while (++count < 16);
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  179  	printk("%s\n", loglvl);
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  180  }
17ea0216681912 arch/sparc/kernel/process_32.c Dmitry Safonov 2019-11-06  181  

:::::: The code@line 160 was first introduced by commit
:::::: 89e3f23da9c827bfa9806c3d4da83a12c1c8543a sparc32: make show_stack() acquire %fp if @_ksp is not specified

:::::: TO: Tejun Heo <tj@kernel.org>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 12823 bytes --]

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 18/50] microblaze: Add loglvl to microblaze_unwind_inner()
  2019-11-06  3:05 ` [PATCH 18/50] microblaze: Add loglvl to microblaze_unwind_inner() Dmitry Safonov
@ 2019-11-08  7:52     ` kbuild test robot
  2019-11-08  7:52     ` kbuild test robot
  1 sibling, 0 replies; 323+ messages in thread
From: kbuild test robot @ 2019-11-08  7:52 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: kbuild-all, linux-kernel, Dmitry Safonov, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Petr Mladek, Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa,
	Michal Simek

[-- Attachment #1: Type: text/plain, Size: 7041 bytes --]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.4-rc6 next-20191107]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kallsyms-printk-Add-loglvl-to-print_ip_sym/20191108-124037
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 847120f859cc45e074204f4cf33c8df069306eb2
config: microblaze-nommu_defconfig (attached as .config)
compiler: microblaze-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=microblaze 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   arch/microblaze/kernel/unwind.c: In function 'unwind_trap':
>> arch/microblaze/kernel/unwind.c:176:2: error: too many arguments to function 'microblaze_unwind_inner'
     microblaze_unwind_inner(task, regs->pc, regs->r1, regs->r15, trace, loglvl);
     ^~~~~~~~~~~~~~~~~~~~~~~
   arch/microblaze/kernel/unwind.c:154:13: note: declared here
    static void microblaze_unwind_inner(struct task_struct *task,
                ^~~~~~~~~~~~~~~~~~~~~~~
   arch/microblaze/kernel/unwind.c: At top level:
>> arch/microblaze/kernel/unwind.c:191:13: error: conflicting types for 'microblaze_unwind_inner'
    static void microblaze_unwind_inner(struct task_struct *task,
                ^~~~~~~~~~~~~~~~~~~~~~~
   arch/microblaze/kernel/unwind.c:154:13: note: previous declaration of 'microblaze_unwind_inner' was here
    static void microblaze_unwind_inner(struct task_struct *task,
                ^~~~~~~~~~~~~~~~~~~~~~~
>> arch/microblaze/kernel/unwind.c:154:13: warning: 'microblaze_unwind_inner' used but never defined

vim +/microblaze_unwind_inner +176 arch/microblaze/kernel/unwind.c

   153	
 > 154	static void microblaze_unwind_inner(struct task_struct *task,
   155					    unsigned long pc, unsigned long fp,
   156					    unsigned long leaf_return,
   157					    struct stack_trace *trace);
   158	
   159	/**
   160	 * unwind_trap - Unwind through a system trap, that stored previous state
   161	 *		 on the stack.
   162	 */
   163	#ifdef CONFIG_MMU
   164	static inline void unwind_trap(struct task_struct *task, unsigned long pc,
   165					unsigned long fp, struct stack_trace *trace,
   166					const char *loglvl)
   167	{
   168		/* To be implemented */
   169	}
   170	#else
   171	static inline void unwind_trap(struct task_struct *task, unsigned long pc,
   172					unsigned long fp, struct stack_trace *trace,
   173					const char *loglvl)
   174	{
   175		const struct pt_regs *regs = (const struct pt_regs *) fp;
 > 176		microblaze_unwind_inner(task, regs->pc, regs->r1, regs->r15, trace, loglvl);
   177	}
   178	#endif
   179	
   180	/**
   181	 * microblaze_unwind_inner - Unwind the stack from the specified point
   182	 * @task  : Task whose stack we are to unwind (may be NULL)
   183	 * @pc    : Program counter from which we start unwinding
   184	 * @fp    : Frame (stack) pointer from which we start unwinding
   185	 * @leaf_return : Value of r15 at pc. If the function is a leaf, this is
   186	 *				  the caller's return address.
   187	 * @trace : Where to store stack backtrace (PC values).
   188	 *	    NULL == print backtrace to kernel log
   189	 * @loglvl : Used for printk log level if (trace == NULL).
   190	 */
 > 191	static void microblaze_unwind_inner(struct task_struct *task,
   192				     unsigned long pc, unsigned long fp,
   193				     unsigned long leaf_return,
   194				     struct stack_trace *trace,
   195				     const char *loglvl)
   196	{
   197		int ofs = 0;
   198	
   199		pr_debug("    Unwinding with PC=%p, FP=%p\n", (void *)pc, (void *)fp);
   200		if (!pc || !fp || (pc & 3) || (fp & 3)) {
   201			pr_debug("    Invalid state for unwind, aborting\n");
   202			return;
   203		}
   204		for (; pc != 0;) {
   205			unsigned long next_fp, next_pc = 0;
   206			unsigned long return_to = pc +  2 * sizeof(unsigned long);
   207			const struct trap_handler_info *handler =
   208				&microblaze_trap_handlers;
   209	
   210			/* Is previous function the HW exception handler? */
   211			if ((return_to >= (unsigned long)&_hw_exception_handler)
   212			    &&(return_to < (unsigned long)&ex_handler_unhandled)) {
   213				/*
   214				 * HW exception handler doesn't save all registers,
   215				 * so we open-code a special case of unwind_trap()
   216				 */
   217	#ifndef CONFIG_MMU
   218				const struct pt_regs *regs =
   219					(const struct pt_regs *) fp;
   220	#endif
   221				printk("%sHW EXCEPTION\n", loglvl);
   222	#ifndef CONFIG_MMU
   223				microblaze_unwind_inner(task, regs->r17 - 4,
   224							fp + EX_HANDLER_STACK_SIZ,
   225							regs->r15, trace, loglvl);
   226	#endif
   227				return;
   228			}
   229	
   230			/* Is previous function a trap handler? */
   231			for (; handler->start_addr; ++handler) {
   232				if ((return_to >= handler->start_addr)
   233				    && (return_to <= handler->end_addr)) {
   234					if (!trace)
   235						printk("%s%s\n", loglvl, handler->trap_name);
   236					unwind_trap(task, pc, fp, trace, loglvl);
   237					return;
   238				}
   239			}
   240			pc -= ofs;
   241	
   242			if (trace) {
   243	#ifdef CONFIG_STACKTRACE
   244				if (trace->skip > 0)
   245					trace->skip--;
   246				else
   247					trace->entries[trace->nr_entries++] = pc;
   248	
   249				if (trace->nr_entries >= trace->max_entries)
   250					break;
   251	#endif
   252			} else {
   253				/* Have we reached userland? */
   254				if (unlikely(pc == task_pt_regs(task)->pc)) {
   255					printk("%s[<%p>] PID %lu [%s]\n",
   256						loglvl, (void *) pc,
   257						(unsigned long) task->pid,
   258						task->comm);
   259					break;
   260				} else
   261					print_ip_sym(loglvl, pc);
   262			}
   263	
   264			/* Stop when we reach anything not part of the kernel */
   265			if (!kernel_text_address(pc))
   266				break;
   267	
   268			if (lookup_prev_stack_frame(fp, pc, leaf_return, &next_fp,
   269						    &next_pc) == 0) {
   270				ofs = sizeof(unsigned long);
   271				pc = next_pc & ~3;
   272				fp = next_fp;
   273				leaf_return = 0;
   274			} else {
   275				pr_debug("    Failed to find previous stack frame\n");
   276				break;
   277			}
   278	
   279			pr_debug("    Next PC=%p, next FP=%p\n",
   280				 (void *)next_pc, (void *)next_fp);
   281		}
   282	}
   283	

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 13604 bytes --]

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 18/50] microblaze: Add loglvl to microblaze_unwind_inner()
@ 2019-11-08  7:52     ` kbuild test robot
  0 siblings, 0 replies; 323+ messages in thread
From: kbuild test robot @ 2019-11-08  7:52 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 7221 bytes --]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.4-rc6 next-20191107]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kallsyms-printk-Add-loglvl-to-print_ip_sym/20191108-124037
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 847120f859cc45e074204f4cf33c8df069306eb2
config: microblaze-nommu_defconfig (attached as .config)
compiler: microblaze-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=microblaze 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   arch/microblaze/kernel/unwind.c: In function 'unwind_trap':
>> arch/microblaze/kernel/unwind.c:176:2: error: too many arguments to function 'microblaze_unwind_inner'
     microblaze_unwind_inner(task, regs->pc, regs->r1, regs->r15, trace, loglvl);
     ^~~~~~~~~~~~~~~~~~~~~~~
   arch/microblaze/kernel/unwind.c:154:13: note: declared here
    static void microblaze_unwind_inner(struct task_struct *task,
                ^~~~~~~~~~~~~~~~~~~~~~~
   arch/microblaze/kernel/unwind.c: At top level:
>> arch/microblaze/kernel/unwind.c:191:13: error: conflicting types for 'microblaze_unwind_inner'
    static void microblaze_unwind_inner(struct task_struct *task,
                ^~~~~~~~~~~~~~~~~~~~~~~
   arch/microblaze/kernel/unwind.c:154:13: note: previous declaration of 'microblaze_unwind_inner' was here
    static void microblaze_unwind_inner(struct task_struct *task,
                ^~~~~~~~~~~~~~~~~~~~~~~
>> arch/microblaze/kernel/unwind.c:154:13: warning: 'microblaze_unwind_inner' used but never defined

vim +/microblaze_unwind_inner +176 arch/microblaze/kernel/unwind.c

   153	
 > 154	static void microblaze_unwind_inner(struct task_struct *task,
   155					    unsigned long pc, unsigned long fp,
   156					    unsigned long leaf_return,
   157					    struct stack_trace *trace);
   158	
   159	/**
   160	 * unwind_trap - Unwind through a system trap, that stored previous state
   161	 *		 on the stack.
   162	 */
   163	#ifdef CONFIG_MMU
   164	static inline void unwind_trap(struct task_struct *task, unsigned long pc,
   165					unsigned long fp, struct stack_trace *trace,
   166					const char *loglvl)
   167	{
   168		/* To be implemented */
   169	}
   170	#else
   171	static inline void unwind_trap(struct task_struct *task, unsigned long pc,
   172					unsigned long fp, struct stack_trace *trace,
   173					const char *loglvl)
   174	{
   175		const struct pt_regs *regs = (const struct pt_regs *) fp;
 > 176		microblaze_unwind_inner(task, regs->pc, regs->r1, regs->r15, trace, loglvl);
   177	}
   178	#endif
   179	
   180	/**
   181	 * microblaze_unwind_inner - Unwind the stack from the specified point
   182	 * @task  : Task whose stack we are to unwind (may be NULL)
   183	 * @pc    : Program counter from which we start unwinding
   184	 * @fp    : Frame (stack) pointer from which we start unwinding
   185	 * @leaf_return : Value of r15 at pc. If the function is a leaf, this is
   186	 *				  the caller's return address.
   187	 * @trace : Where to store stack backtrace (PC values).
   188	 *	    NULL == print backtrace to kernel log
   189	 * @loglvl : Used for printk log level if (trace == NULL).
   190	 */
 > 191	static void microblaze_unwind_inner(struct task_struct *task,
   192				     unsigned long pc, unsigned long fp,
   193				     unsigned long leaf_return,
   194				     struct stack_trace *trace,
   195				     const char *loglvl)
   196	{
   197		int ofs = 0;
   198	
   199		pr_debug("    Unwinding with PC=%p, FP=%p\n", (void *)pc, (void *)fp);
   200		if (!pc || !fp || (pc & 3) || (fp & 3)) {
   201			pr_debug("    Invalid state for unwind, aborting\n");
   202			return;
   203		}
   204		for (; pc != 0;) {
   205			unsigned long next_fp, next_pc = 0;
   206			unsigned long return_to = pc +  2 * sizeof(unsigned long);
   207			const struct trap_handler_info *handler =
   208				&microblaze_trap_handlers;
   209	
   210			/* Is previous function the HW exception handler? */
   211			if ((return_to >= (unsigned long)&_hw_exception_handler)
   212			    &&(return_to < (unsigned long)&ex_handler_unhandled)) {
   213				/*
   214				 * HW exception handler doesn't save all registers,
   215				 * so we open-code a special case of unwind_trap()
   216				 */
   217	#ifndef CONFIG_MMU
   218				const struct pt_regs *regs =
   219					(const struct pt_regs *) fp;
   220	#endif
   221				printk("%sHW EXCEPTION\n", loglvl);
   222	#ifndef CONFIG_MMU
   223				microblaze_unwind_inner(task, regs->r17 - 4,
   224							fp + EX_HANDLER_STACK_SIZ,
   225							regs->r15, trace, loglvl);
   226	#endif
   227				return;
   228			}
   229	
   230			/* Is previous function a trap handler? */
   231			for (; handler->start_addr; ++handler) {
   232				if ((return_to >= handler->start_addr)
   233				    && (return_to <= handler->end_addr)) {
   234					if (!trace)
   235						printk("%s%s\n", loglvl, handler->trap_name);
   236					unwind_trap(task, pc, fp, trace, loglvl);
   237					return;
   238				}
   239			}
   240			pc -= ofs;
   241	
   242			if (trace) {
   243	#ifdef CONFIG_STACKTRACE
   244				if (trace->skip > 0)
   245					trace->skip--;
   246				else
   247					trace->entries[trace->nr_entries++] = pc;
   248	
   249				if (trace->nr_entries >= trace->max_entries)
   250					break;
   251	#endif
   252			} else {
   253				/* Have we reached userland? */
   254				if (unlikely(pc == task_pt_regs(task)->pc)) {
   255					printk("%s[<%p>] PID %lu [%s]\n",
   256						loglvl, (void *) pc,
   257						(unsigned long) task->pid,
   258						task->comm);
   259					break;
   260				} else
   261					print_ip_sym(loglvl, pc);
   262			}
   263	
   264			/* Stop when we reach anything not part of the kernel */
   265			if (!kernel_text_address(pc))
   266				break;
   267	
   268			if (lookup_prev_stack_frame(fp, pc, leaf_return, &next_fp,
   269						    &next_pc) == 0) {
   270				ofs = sizeof(unsigned long);
   271				pc = next_pc & ~3;
   272				fp = next_fp;
   273				leaf_return = 0;
   274			} else {
   275				pr_debug("    Failed to find previous stack frame\n");
   276				break;
   277			}
   278	
   279			pr_debug("    Next PC=%p, next FP=%p\n",
   280				 (void *)next_pc, (void *)next_fp);
   281		}
   282	}
   283	

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 13604 bytes --]

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 50/50] kernel: Rename show_stack_loglvl() => show_stack()
  2019-11-06  3:05 ` [PATCH 50/50] kernel: Rename show_stack_loglvl() => show_stack() Dmitry Safonov
@ 2019-11-08 10:08     ` kbuild test robot
  0 siblings, 0 replies; 323+ messages in thread
From: kbuild test robot @ 2019-11-08 10:08 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: kbuild-all, linux-kernel, Dmitry Safonov, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Petr Mladek, Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa

[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.4-rc6]
[cannot apply to next-20191108]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kallsyms-printk-Add-loglvl-to-print_ip_sym/20191108-124037
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 847120f859cc45e074204f4cf33c8df069306eb2
config: s390-allnoconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=s390 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arch/s390/kernel/dumpstack.c: In function 'show_regs':
>> arch/s390/kernel/dumpstack.c:178:3: error: too few arguments to function 'show_stack'
      show_stack(NULL, (unsigned long *) regs->gprs[15]);
      ^~~~~~~~~~
   arch/s390/kernel/dumpstack.c:126:6: note: declared here
    void show_stack(struct task_struct *task, unsigned long *stack,
         ^~~~~~~~~~

vim +/show_stack +178 arch/s390/kernel/dumpstack.c

1bca09f7144450 Heiko Carstens 2013-03-14  171  
1bca09f7144450 Heiko Carstens 2013-03-14  172  void show_regs(struct pt_regs *regs)
1bca09f7144450 Heiko Carstens 2013-03-14  173  {
a43cb95d547a06 Tejun Heo      2013-04-30  174  	show_regs_print_info(KERN_DEFAULT);
1bca09f7144450 Heiko Carstens 2013-03-14  175  	show_registers(regs);
1bca09f7144450 Heiko Carstens 2013-03-14  176  	/* Show stack backtrace if pt_regs is from kernel mode */
1bca09f7144450 Heiko Carstens 2013-03-14  177  	if (!user_mode(regs))
2b7b9817c2dbfc Heiko Carstens 2017-06-06 @178  		show_stack(NULL, (unsigned long *) regs->gprs[15]);
1bca09f7144450 Heiko Carstens 2013-03-14  179  	show_last_breaking_event(regs);
1bca09f7144450 Heiko Carstens 2013-03-14  180  }
1bca09f7144450 Heiko Carstens 2013-03-14  181  

:::::: The code at line 178 was first introduced by commit
:::::: 2b7b9817c2dbfce0501a313db817718fc5ef6524 s390/dumpstack: remove raw stack dump

:::::: TO: Heiko Carstens <heiko.carstens@de.ibm.com>
:::::: CC: Martin Schwidefsky <schwidefsky@de.ibm.com>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 5837 bytes --]

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 50/50] kernel: Rename show_stack_loglvl() => show_stack()
@ 2019-11-08 10:08     ` kbuild test robot
  0 siblings, 0 replies; 323+ messages in thread
From: kbuild test robot @ 2019-11-08 10:08 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.4-rc6]
[cannot apply to next-20191108]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Dmitry-Safonov/kallsyms-printk-Add-loglvl-to-print_ip_sym/20191108-124037
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 847120f859cc45e074204f4cf33c8df069306eb2
config: s390-allnoconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 7.4.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.4.0 make.cross ARCH=s390 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   arch/s390/kernel/dumpstack.c: In function 'show_regs':
>> arch/s390/kernel/dumpstack.c:178:3: error: too few arguments to function 'show_stack'
      show_stack(NULL, (unsigned long *) regs->gprs[15]);
      ^~~~~~~~~~
   arch/s390/kernel/dumpstack.c:126:6: note: declared here
    void show_stack(struct task_struct *task, unsigned long *stack,
         ^~~~~~~~~~

vim +/show_stack +178 arch/s390/kernel/dumpstack.c

1bca09f7144450 Heiko Carstens 2013-03-14  171  
1bca09f7144450 Heiko Carstens 2013-03-14  172  void show_regs(struct pt_regs *regs)
1bca09f7144450 Heiko Carstens 2013-03-14  173  {
a43cb95d547a06 Tejun Heo      2013-04-30  174  	show_regs_print_info(KERN_DEFAULT);
1bca09f7144450 Heiko Carstens 2013-03-14  175  	show_registers(regs);
1bca09f7144450 Heiko Carstens 2013-03-14  176  	/* Show stack backtrace if pt_regs is from kernel mode */
1bca09f7144450 Heiko Carstens 2013-03-14  177  	if (!user_mode(regs))
2b7b9817c2dbfc Heiko Carstens 2017-06-06 @178  		show_stack(NULL, (unsigned long *) regs->gprs[15]);
1bca09f7144450 Heiko Carstens 2013-03-14  179  	show_last_breaking_event(regs);
1bca09f7144450 Heiko Carstens 2013-03-14  180  }
1bca09f7144450 Heiko Carstens 2013-03-14  181  

:::::: The code at line 178 was first introduced by commit
:::::: 2b7b9817c2dbfce0501a313db817718fc5ef6524 s390/dumpstack: remove raw stack dump

:::::: TO: Heiko Carstens <heiko.carstens@de.ibm.com>
:::::: CC: Martin Schwidefsky <schwidefsky@de.ibm.com>

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org Intel Corporation

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 5837 bytes --]

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06  8:35   ` Petr Mladek
                       ` (3 preceding siblings ...)
  (?)
@ 2019-11-08 10:37     ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-08 10:37 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/06 09:35), Petr Mladek wrote:
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.

Hmm, I don't know.
Do we really need debug/info level backtraces? May be all backtraces
can be converted to something more severe (so we can stop playing games
with loglvl) and then we can clean up "(ab)users"?

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 10:37     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-08 10:37 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/06 09:35), Petr Mladek wrote:
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.

Hmm, I don't know.
Do we really need debug/info level backtraces? May be all backtraces
can be converted to something more severe (so we can stop playing games
with loglvl) and then we can clean up "(ab)users"?

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 10:37     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-08 10:37 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/06 09:35), Petr Mladek wrote:
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.

Hmm, I don't know.
Do we really need debug/info level backtraces? May be all backtraces
can be converted to something more severe (so we can stop playing games
with loglvl) and then we can clean up "(ab)users"?

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 10:37     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-08 10:37 UTC (permalink / raw)
  To: openrisc

On (19/11/06 09:35), Petr Mladek wrote:
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.

Hmm, I don't know.
Do we really need debug/info level backtraces? May be all backtraces
can be converted to something more severe (so we can stop playing games
with loglvl) and then we can clean up "(ab)users"?

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 10:37     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-08 10:37 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Dmitry Safonov, linux-kernel, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J. Bottomley, linux-parisc,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev, Christian Borntraeger, Heiko Carstens,
	Vasily Gorbik, linux-s390, Rich Felker, linux-sh,
	David S. Miller, sparclinux, Anton Ivanov, Jeff Dike,
	Richard Weinberger, linux-um, Guan Xuetao, Borislav Petkov,
	H. Peter Anvin, x86, Chris Zankel, Max Filippov, linux-xtensa,
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

On (19/11/06 09:35), Petr Mladek wrote:
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.

Hmm, I don't know.
Do we really need debug/info level backtraces? May be all backtraces
can be converted to something more severe (so we can stop playing games
with loglvl) and then we can clean up "(ab)users"?

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 10:37     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-08 10:37 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On (19/11/06 09:35), Petr Mladek wrote:
> I agree with all the other justification.
> 
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.

Hmm, I don't know.
Do we really need debug/info level backtraces? May be all backtraces
can be converted to something more severe (so we can stop playing games
with loglvl) and then we can clean up "(ab)users"?

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-08 10:37     ` Sergey Senozhatsky
                         ` (3 preceding siblings ...)
  (?)
@ 2019-11-08 13:04       ` Petr Mladek
  -1 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-08 13:04 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Fri 2019-11-08 19:37:19, Sergey Senozhatsky wrote:
> On (19/11/06 09:35), Petr Mladek wrote:
> > I agree with all the other justification.
> > 
> > I would add. The backtrace is really useful for debugging. It should
> > be possible to print it even in less critical situations.
> 
> Hmm, I don't know.
> Do we really need debug/info level backtraces?

debug is exactly the loglevel where registry content and backtrace
might be very useful. It is not always important to reach the console.


> May be all backtraces can be converted to something more severe
> (so we can stop playing games with loglvl) and then we can
> clean up "(ab)users"?

IMHO, we should distinguish warning, error, crit, alert, emerg
situations. Backtraces and any related messages should be
filtered the same way. Any information might be useless without
the context.

I agree that it is complicated to pass the loglevel as
a parameter. It would be better define the default
log level for a given code section. It might be stored
in task_struct for the normal context and in per-CPU
variables for interrupt contexts.

Best Regards,
Petr

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 13:04       ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-08 13:04 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Fri 2019-11-08 19:37:19, Sergey Senozhatsky wrote:
> On (19/11/06 09:35), Petr Mladek wrote:
> > I agree with all the other justification.
> > 
> > I would add. The backtrace is really useful for debugging. It should
> > be possible to print it even in less critical situations.
> 
> Hmm, I don't know.
> Do we really need debug/info level backtraces?

debug is exactly the loglevel where registry content and backtrace
might be very useful. It is not always important to reach the console.


> May be all backtraces can be converted to something more severe
> (so we can stop playing games with loglvl) and then we can
> clean up "(ab)users"?

IMHO, we should distinguish warning, error, crit, alert, emerg
situations. Backtraces and any related messages should be
filtered the same way. Any information might be useless without
the context.

I agree that it is complicated to pass the loglevel as
a parameter. It would be better define the default
log level for a given code section. It might be stored
in task_struct for the normal context and in per-CPU
variables for interrupt contexts.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 13:04       ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-08 13:04 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Fri 2019-11-08 19:37:19, Sergey Senozhatsky wrote:
> On (19/11/06 09:35), Petr Mladek wrote:
> > I agree with all the other justification.
> > 
> > I would add. The backtrace is really useful for debugging. It should
> > be possible to print it even in less critical situations.
> 
> Hmm, I don't know.
> Do we really need debug/info level backtraces?

debug is exactly the loglevel where registry content and backtrace
might be very useful. It is not always important to reach the console.


> May be all backtraces can be converted to something more severe
> (so we can stop playing games with loglvl) and then we can
> clean up "(ab)users"?

IMHO, we should distinguish warning, error, crit, alert, emerg
situations. Backtraces and any related messages should be
filtered the same way. Any information might be useless without
the context.

I agree that it is complicated to pass the loglevel as
a parameter. It would be better define the default
log level for a given code section. It might be stored
in task_struct for the normal context and in per-CPU
variables for interrupt contexts.

Best Regards,
Petr

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 13:04       ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-08 13:04 UTC (permalink / raw)
  To: openrisc

On Fri 2019-11-08 19:37:19, Sergey Senozhatsky wrote:
> On (19/11/06 09:35), Petr Mladek wrote:
> > I agree with all the other justification.
> > 
> > I would add. The backtrace is really useful for debugging. It should
> > be possible to print it even in less critical situations.
> 
> Hmm, I don't know.
> Do we really need debug/info level backtraces?

debug is exactly the loglevel where registry content and backtrace
might be very useful. It is not always important to reach the console.


> May be all backtraces can be converted to something more severe
> (so we can stop playing games with loglvl) and then we can
> clean up "(ab)users"?

IMHO, we should distinguish warning, error, crit, alert, emerg
situations. Backtraces and any related messages should be
filtered the same way. Any information might be useless without
the context.

I agree that it is complicated to pass the loglevel as
a parameter. It would be better define the default
log level for a given code section. It might be stored
in task_struct for the normal context and in per-CPU
variables for interrupt contexts.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 13:04       ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-08 13:04 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Dmitry Safonov, linux-kernel, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J. Bottomley, linux-parisc,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev, Christian Borntraeger, Heiko Carstens,
	Vasily Gorbik, linux-s390, Rich Felker, linux-sh,
	David S. Miller, sparclinux, Anton Ivanov, Jeff Dike,
	Richard Weinberger, linux-um, Guan Xuetao, Borislav Petkov,
	H. Peter Anvin, x86, Chris Zankel, Max Filippov, linux-xtensa,
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

On Fri 2019-11-08 19:37:19, Sergey Senozhatsky wrote:
> On (19/11/06 09:35), Petr Mladek wrote:
> > I agree with all the other justification.
> > 
> > I would add. The backtrace is really useful for debugging. It should
> > be possible to print it even in less critical situations.
> 
> Hmm, I don't know.
> Do we really need debug/info level backtraces?

debug is exactly the loglevel where registry content and backtrace
might be very useful. It is not always important to reach the console.


> May be all backtraces can be converted to something more severe
> (so we can stop playing games with loglvl) and then we can
> clean up "(ab)users"?

IMHO, we should distinguish warning, error, crit, alert, emerg
situations. Backtraces and any related messages should be
filtered the same way. Any information might be useless without
the context.

I agree that it is complicated to pass the loglevel as
a parameter. It would be better define the default
log level for a given code section. It might be stored
in task_struct for the normal context and in per-CPU
variables for interrupt contexts.

Best Regards,
Petr


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 13:04       ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-08 13:04 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On Fri 2019-11-08 19:37:19, Sergey Senozhatsky wrote:
> On (19/11/06 09:35), Petr Mladek wrote:
> > I agree with all the other justification.
> > 
> > I would add. The backtrace is really useful for debugging. It should
> > be possible to print it even in less critical situations.
> 
> Hmm, I don't know.
> Do we really need debug/info level backtraces?

debug is exactly the loglevel where registry content and backtrace
might be very useful. It is not always important to reach the console.


> May be all backtraces can be converted to something more severe
> (so we can stop playing games with loglvl) and then we can
> clean up "(ab)users"?

IMHO, we should distinguish warning, error, crit, alert, emerg
situations. Backtraces and any related messages should be
filtered the same way. Any information might be useless without
the context.

I agree that it is complicated to pass the loglevel as
a parameter. It would be better define the default
log level for a given code section. It might be stored
in task_struct for the normal context and in per-CPU
variables for interrupt contexts.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06 20:34       ` Peter Zijlstra
                           ` (3 preceding siblings ...)
  (?)
@ 2019-11-08 16:28         ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 16:28 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, LKML, Ralf Baechle,
	Paul Mackerras, Andrew Morton, linux-ia64, Tetsuo Handa,
	James Hogan, James E.J. Bottomley, Max Filippov, Vincent Chen,
	Ingo Molnar, linux-s390, linux-c6x-dev, Yoshinori Sato,
	linux-hexagon, Helge Deller,
	open list:TENSILICA XTENSA PORT (xtensa),
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, X86 ML, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
[..]
>> Sorry, I should have tried to describe better.
>>
>> I'm trying to remove external users of console_loglevel by following
>> reasons:
>
> I suppose since all my machines have 'debug ignore_loglevel
> earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> experience.

Yeah, I remember you avoid all those functionalities of printk(), fair
enough. On the other side, regular users and I'm betting most of
the non-tuned distributions use /proc/sys/kernel/printk by default.
(Checking on my Arch & Fedora - loglevel 4 from the box)

>> - changing console_loglevel on SMP means that unwanted messages from
>> other CPUs will appear (that have lower log level)
>> - on UMP unwanted messages may appear if the code is preempted while it
>> hasn't set the console_loglevel back to old
>> - rising console_loglevel to print wanted message(s) may not work at all
>> if printk() has being delayed and the console_loglevel is already set
>> back to old value
>
> Sure, frobbing the global console_loglevel is bad.
>
>> I also have patches in wip those needs to print backtrace with specific
>> loglevel (higher when it's critical, lower when it's notice and
>> shouldn't go to serial console).
>
> (everything always should go to serial, serial is awesome :-)

Personally I agree. Unfortunately, here @Arista there are switches (I'm
speaking about the order of thousands at least) those have baud-rate 9600.
It's a bit expensive being elaborate with such setup.

>> Besides on local tests I see hits those have headers (messages like
>> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
>> without a reason for it. It's quite annoying and worth addressing by
>> syncing headers log levels to backtraces.
>
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
>
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Well, the use-case for lower log-level is that everything goes into logs
(/var/log/dmesg or /var/log/messages whatever rsyslog has settting).

That has it's value:
- after a failure (i.e. panic) messages, those were only signs that
something goes wrong can be seen in logs which can give ideas what has
happened.
- before the failure, those messages go to telemetry and can be
auto-magically processed remotely to take a decision (e.g. balance the
traffic away).

I wish all the information could be gathered in the userspace, but many
existing kernel/driver messages are valuable. A more detailed example is
hung task detector: we want to have the backtrace for a task that is
in uninterruptible state too long, but only in logs as printing on
serial console may lead to holding console lock and watchdog.
Besides customer notifications and investigations, I see the value of such
"bottleneck" warnings during long-running integration tests.

Thanks,
          Dmitry

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 16:28         ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 16:28 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, LKML, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, open list:TENSILICA XTENSA PORT (xtensa),
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Petr Mladek, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, X86 ML,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
[..]
>> Sorry, I should have tried to describe better.
>>
>> I'm trying to remove external users of console_loglevel by following
>> reasons:
>
> I suppose since all my machines have 'debug ignore_loglevel
> earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> experience.

Yeah, I remember you avoid all those functionalities of printk(), fair
enough. On the other side, regular users and I'm betting most of
the non-tuned distributions use /proc/sys/kernel/printk by default.
(Checking on my Arch & Fedora - loglevel 4 from the box)

>> - changing console_loglevel on SMP means that unwanted messages from
>> other CPUs will appear (that have lower log level)
>> - on UMP unwanted messages may appear if the code is preempted while it
>> hasn't set the console_loglevel back to old
>> - rising console_loglevel to print wanted message(s) may not work at all
>> if printk() has being delayed and the console_loglevel is already set
>> back to old value
>
> Sure, frobbing the global console_loglevel is bad.
>
>> I also have patches in wip those needs to print backtrace with specific
>> loglevel (higher when it's critical, lower when it's notice and
>> shouldn't go to serial console).
>
> (everything always should go to serial, serial is awesome :-)

Personally I agree. Unfortunately, here @Arista there are switches (I'm
speaking about the order of thousands at least) those have baud-rate 9600.
It's a bit expensive being elaborate with such setup.

>> Besides on local tests I see hits those have headers (messages like
>> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
>> without a reason for it. It's quite annoying and worth addressing by
>> syncing headers log levels to backtraces.
>
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
>
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Well, the use-case for lower log-level is that everything goes into logs
(/var/log/dmesg or /var/log/messages whatever rsyslog has settting).

That has it's value:
- after a failure (i.e. panic) messages, those were only signs that
something goes wrong can be seen in logs which can give ideas what has
happened.
- before the failure, those messages go to telemetry and can be
auto-magically processed remotely to take a decision (e.g. balance the
traffic away).

I wish all the information could be gathered in the userspace, but many
existing kernel/driver messages are valuable. A more detailed example is
hung task detector: we want to have the backtrace for a task that is
in uninterruptible state too long, but only in logs as printing on
serial console may lead to holding console lock and watchdog.
Besides customer notifications and investigations, I see the value of such
"bottleneck" warnings during long-running integration tests.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 16:28         ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 16:28 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, LKML, Ralf Baechle,
	Paul Mackerras, Andrew Morton, linux-ia64, Tetsuo Handa,
	James Hogan, James E.J. Bottomley, Max Filippov, Vincent Chen,
	Ingo Molnar, linux-s390, linux-c6x-dev, Yoshinori Sato,
	linux-hexagon, Helge Deller,
	open list:TENSILICA XTENSA PORT (xtensa),
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, X86 ML, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
[..]
>> Sorry, I should have tried to describe better.
>>
>> I'm trying to remove external users of console_loglevel by following
>> reasons:
>
> I suppose since all my machines have 'debug ignore_loglevel
> earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> experience.

Yeah, I remember you avoid all those functionalities of printk(), fair
enough. On the other side, regular users and I'm betting most of
the non-tuned distributions use /proc/sys/kernel/printk by default.
(Checking on my Arch & Fedora - loglevel 4 from the box)

>> - changing console_loglevel on SMP means that unwanted messages from
>> other CPUs will appear (that have lower log level)
>> - on UMP unwanted messages may appear if the code is preempted while it
>> hasn't set the console_loglevel back to old
>> - rising console_loglevel to print wanted message(s) may not work at all
>> if printk() has being delayed and the console_loglevel is already set
>> back to old value
>
> Sure, frobbing the global console_loglevel is bad.
>
>> I also have patches in wip those needs to print backtrace with specific
>> loglevel (higher when it's critical, lower when it's notice and
>> shouldn't go to serial console).
>
> (everything always should go to serial, serial is awesome :-)

Personally I agree. Unfortunately, here @Arista there are switches (I'm
speaking about the order of thousands at least) those have baud-rate 9600.
It's a bit expensive being elaborate with such setup.

>> Besides on local tests I see hits those have headers (messages like
>> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
>> without a reason for it. It's quite annoying and worth addressing by
>> syncing headers log levels to backtraces.
>
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
>
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Well, the use-case for lower log-level is that everything goes into logs
(/var/log/dmesg or /var/log/messages whatever rsyslog has settting).

That has it's value:
- after a failure (i.e. panic) messages, those were only signs that
something goes wrong can be seen in logs which can give ideas what has
happened.
- before the failure, those messages go to telemetry and can be
auto-magically processed remotely to take a decision (e.g. balance the
traffic away).

I wish all the information could be gathered in the userspace, but many
existing kernel/driver messages are valuable. A more detailed example is
hung task detector: we want to have the backtrace for a task that is
in uninterruptible state too long, but only in logs as printing on
serial console may lead to holding console lock and watchdog.
Besides customer notifications and investigations, I see the value of such
"bottleneck" warnings during long-running integration tests.

Thanks,
          Dmitry

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 16:28         ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 16:28 UTC (permalink / raw)
  To: openrisc

On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
[..]
>> Sorry, I should have tried to describe better.
>>
>> I'm trying to remove external users of console_loglevel by following
>> reasons:
>
> I suppose since all my machines have 'debug ignore_loglevel
> earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> experience.

Yeah, I remember you avoid all those functionalities of printk(), fair
enough. On the other side, regular users and I'm betting most of
the non-tuned distributions use /proc/sys/kernel/printk by default.
(Checking on my Arch & Fedora - loglevel 4 from the box)

>> - changing console_loglevel on SMP means that unwanted messages from
>> other CPUs will appear (that have lower log level)
>> - on UMP unwanted messages may appear if the code is preempted while it
>> hasn't set the console_loglevel back to old
>> - rising console_loglevel to print wanted message(s) may not work at all
>> if printk() has being delayed and the console_loglevel is already set
>> back to old value
>
> Sure, frobbing the global console_loglevel is bad.
>
>> I also have patches in wip those needs to print backtrace with specific
>> loglevel (higher when it's critical, lower when it's notice and
>> shouldn't go to serial console).
>
> (everything always should go to serial, serial is awesome :-)

Personally I agree. Unfortunately, here @Arista there are switches (I'm
speaking about the order of thousands at least) those have baud-rate 9600.
It's a bit expensive being elaborate with such setup.

>> Besides on local tests I see hits those have headers (messages like
>> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
>> without a reason for it. It's quite annoying and worth addressing by
>> syncing headers log levels to backtraces.
>
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
>
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Well, the use-case for lower log-level is that everything goes into logs
(/var/log/dmesg or /var/log/messages whatever rsyslog has settting).

That has it's value:
- after a failure (i.e. panic) messages, those were only signs that
something goes wrong can be seen in logs which can give ideas what has
happened.
- before the failure, those messages go to telemetry and can be
auto-magically processed remotely to take a decision (e.g. balance the
traffic away).

I wish all the information could be gathered in the userspace, but many
existing kernel/driver messages are valuable. A more detailed example is
hung task detector: we want to have the backtrace for a task that is
in uninterruptible state too long, but only in logs as printing on
serial console may lead to holding console lock and watchdog.
Besides customer notifications and investigations, I see the value of such
"bottleneck" warnings during long-running integration tests.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 16:28         ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 16:28 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: LKML, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Ralf Baechle, Thomas Gleixner,
	Vincent Chen, Vincent Guittot, Will Deacon, linux-mips,
	linux-riscv, Ivan Kokshaysky, Matt Turner, Richard Henderson,
	linux-alpha, Vineet Gupta, linux-snps-arc, Russell King,
	linux-arm-kernel, clang-built-linux, Catalin Marinas,
	Aurelien Jacquiot, Mark Salter, linux-c6x-dev, Guo Ren,
	Yoshinori Sato, uclinux-h8-devel, Brian Cain, linux-hexagon,
	Fenghua Yu, Tony Luck, linux-ia64, Geert Uytterhoeven,
	linux-m68k, Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, X86 ML, Chris Zankel,
	Max Filippov, open list:TENSILICA XTENSA PORT (xtensa),
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
[..]
>> Sorry, I should have tried to describe better.
>>
>> I'm trying to remove external users of console_loglevel by following
>> reasons:
>
> I suppose since all my machines have 'debug ignore_loglevel
> earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> experience.

Yeah, I remember you avoid all those functionalities of printk(), fair
enough. On the other side, regular users and I'm betting most of
the non-tuned distributions use /proc/sys/kernel/printk by default.
(Checking on my Arch & Fedora - loglevel 4 from the box)

>> - changing console_loglevel on SMP means that unwanted messages from
>> other CPUs will appear (that have lower log level)
>> - on UMP unwanted messages may appear if the code is preempted while it
>> hasn't set the console_loglevel back to old
>> - rising console_loglevel to print wanted message(s) may not work at all
>> if printk() has being delayed and the console_loglevel is already set
>> back to old value
>
> Sure, frobbing the global console_loglevel is bad.
>
>> I also have patches in wip those needs to print backtrace with specific
>> loglevel (higher when it's critical, lower when it's notice and
>> shouldn't go to serial console).
>
> (everything always should go to serial, serial is awesome :-)

Personally I agree. Unfortunately, here @Arista there are switches (I'm
speaking about the order of thousands at least) those have baud-rate 9600.
It's a bit expensive being elaborate with such setup.

>> Besides on local tests I see hits those have headers (messages like
>> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
>> without a reason for it. It's quite annoying and worth addressing by
>> syncing headers log levels to backtraces.
>
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
>
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Well, the use-case for lower log-level is that everything goes into logs
(/var/log/dmesg or /var/log/messages whatever rsyslog has settting).

That has it's value:
- after a failure (i.e. panic) messages, those were only signs that
something goes wrong can be seen in logs which can give ideas what has
happened.
- before the failure, those messages go to telemetry and can be
auto-magically processed remotely to take a decision (e.g. balance the
traffic away).

I wish all the information could be gathered in the userspace, but many
existing kernel/driver messages are valuable. A more detailed example is
hung task detector: we want to have the backtrace for a task that is
in uninterruptible state too long, but only in logs as printing on
serial console may lead to holding console lock and watchdog.
Besides customer notifications and investigations, I see the value of such
"bottleneck" warnings during long-running integration tests.

Thanks,
          Dmitry


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 16:28         ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 16:28 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, LKML, Ralf

On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
[..]
>> Sorry, I should have tried to describe better.
>>
>> I'm trying to remove external users of console_loglevel by following
>> reasons:
>
> I suppose since all my machines have 'debug ignore_loglevel
> earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> experience.

Yeah, I remember you avoid all those functionalities of printk(), fair
enough. On the other side, regular users and I'm betting most of
the non-tuned distributions use /proc/sys/kernel/printk by default.
(Checking on my Arch & Fedora - loglevel 4 from the box)

>> - changing console_loglevel on SMP means that unwanted messages from
>> other CPUs will appear (that have lower log level)
>> - on UMP unwanted messages may appear if the code is preempted while it
>> hasn't set the console_loglevel back to old
>> - rising console_loglevel to print wanted message(s) may not work at all
>> if printk() has being delayed and the console_loglevel is already set
>> back to old value
>
> Sure, frobbing the global console_loglevel is bad.
>
>> I also have patches in wip those needs to print backtrace with specific
>> loglevel (higher when it's critical, lower when it's notice and
>> shouldn't go to serial console).
>
> (everything always should go to serial, serial is awesome :-)

Personally I agree. Unfortunately, here @Arista there are switches (I'm
speaking about the order of thousands at least) those have baud-rate 9600.
It's a bit expensive being elaborate with such setup.

>> Besides on local tests I see hits those have headers (messages like
>> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
>> without a reason for it. It's quite annoying and worth addressing by
>> syncing headers log levels to backtraces.
>
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
>
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

Well, the use-case for lower log-level is that everything goes into logs
(/var/log/dmesg or /var/log/messages whatever rsyslog has settting).

That has it's value:
- after a failure (i.e. panic) messages, those were only signs that
something goes wrong can be seen in logs which can give ideas what has
happened.
- before the failure, those messages go to telemetry and can be
auto-magically processed remotely to take a decision (e.g. balance the
traffic away).

I wish all the information could be gathered in the userspace, but many
existing kernel/driver messages are valuable. A more detailed example is
hung task detector: we want to have the backtrace for a task that is
in uninterruptible state too long, but only in logs as printing on
serial console may lead to holding console lock and watchdog.
Besides customer notifications and investigations, I see the value of such
"bottleneck" warnings during long-running integration tests.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-08 16:28         ` Dmitry Safonov
                             ` (3 preceding siblings ...)
  (?)
@ 2019-11-08 17:30           ` Russell King - ARM Linux admin
  -1 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-08 17:30 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, LKML, Ralf Baechle,
	Paul Mackerras, Andrew Morton, linux-ia64, Tetsuo Handa,
	James Hogan, James E.J. Bottomley, Max Filippov, Vincent Chen,
	Ingo Molnar, linux-s390, linux-c6x-dev, Yoshinori Sato,
	linux-hexagon, Helge Deller,
	open list:TENSILICA XTENSA PORT (xtensa),
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, X86 ML, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
> On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> [..]
> >> Sorry, I should have tried to describe better.
> >>
> >> I'm trying to remove external users of console_loglevel by following
> >> reasons:
> >
> > I suppose since all my machines have 'debug ignore_loglevel
> > earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> > experience.
> 
> Yeah, I remember you avoid all those functionalities of printk(), fair
> enough. On the other side, regular users and I'm betting most of
> the non-tuned distributions use /proc/sys/kernel/printk by default.
> (Checking on my Arch & Fedora - loglevel 4 from the box)
> 
> >> - changing console_loglevel on SMP means that unwanted messages from
> >> other CPUs will appear (that have lower log level)
> >> - on UMP unwanted messages may appear if the code is preempted while it
> >> hasn't set the console_loglevel back to old
> >> - rising console_loglevel to print wanted message(s) may not work at all
> >> if printk() has being delayed and the console_loglevel is already set
> >> back to old value
> >
> > Sure, frobbing the global console_loglevel is bad.
> >
> >> I also have patches in wip those needs to print backtrace with specific
> >> loglevel (higher when it's critical, lower when it's notice and
> >> shouldn't go to serial console).
> >
> > (everything always should go to serial, serial is awesome :-)
> 
> Personally I agree. Unfortunately, here @Arista there are switches (I'm
> speaking about the order of thousands at least) those have baud-rate 9600.
> It's a bit expensive being elaborate with such setup.
> 
> >> Besides on local tests I see hits those have headers (messages like
> >> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> >> without a reason for it. It's quite annoying and worth addressing by
> >> syncing headers log levels to backtraces.
> >
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.
> >
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?
> 
> Well, the use-case for lower log-level is that everything goes into logs
> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
> 
> That has it's value:
> - after a failure (i.e. panic) messages, those were only signs that
> something goes wrong can be seen in logs which can give ideas what has
> happened.

No they don't.  When the kernel panics, userspace generally stops
running, so rsyslog won't be able to write them to /var/log/messages.

How, by "kernel panics" I mean a real kernel panic, which probably
isn't what you're talking about there.  You are probably talking
about the whole shebang of non-fatal kernel oops, kernel warnings
and the like.  If so, I'd ask you to stop confuzzilating terminology.

If you really want to capture such events, then you need to have the
kernel write the panic to (e.g.) flash - see the mtdoops driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 17:30           ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-08 17:30 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, LKML, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, open list:TENSILICA XTENSA PORT (xtensa),
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Petr Mladek, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger,
	X86 ML, clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
> On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> [..]
> >> Sorry, I should have tried to describe better.
> >>
> >> I'm trying to remove external users of console_loglevel by following
> >> reasons:
> >
> > I suppose since all my machines have 'debug ignore_loglevel
> > earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> > experience.
> 
> Yeah, I remember you avoid all those functionalities of printk(), fair
> enough. On the other side, regular users and I'm betting most of
> the non-tuned distributions use /proc/sys/kernel/printk by default.
> (Checking on my Arch & Fedora - loglevel 4 from the box)
> 
> >> - changing console_loglevel on SMP means that unwanted messages from
> >> other CPUs will appear (that have lower log level)
> >> - on UMP unwanted messages may appear if the code is preempted while it
> >> hasn't set the console_loglevel back to old
> >> - rising console_loglevel to print wanted message(s) may not work at all
> >> if printk() has being delayed and the console_loglevel is already set
> >> back to old value
> >
> > Sure, frobbing the global console_loglevel is bad.
> >
> >> I also have patches in wip those needs to print backtrace with specific
> >> loglevel (higher when it's critical, lower when it's notice and
> >> shouldn't go to serial console).
> >
> > (everything always should go to serial, serial is awesome :-)
> 
> Personally I agree. Unfortunately, here @Arista there are switches (I'm
> speaking about the order of thousands at least) those have baud-rate 9600.
> It's a bit expensive being elaborate with such setup.
> 
> >> Besides on local tests I see hits those have headers (messages like
> >> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> >> without a reason for it. It's quite annoying and worth addressing by
> >> syncing headers log levels to backtraces.
> >
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.
> >
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?
> 
> Well, the use-case for lower log-level is that everything goes into logs
> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
> 
> That has it's value:
> - after a failure (i.e. panic) messages, those were only signs that
> something goes wrong can be seen in logs which can give ideas what has
> happened.

No they don't.  When the kernel panics, userspace generally stops
running, so rsyslog won't be able to write them to /var/log/messages.

How, by "kernel panics" I mean a real kernel panic, which probably
isn't what you're talking about there.  You are probably talking
about the whole shebang of non-fatal kernel oops, kernel warnings
and the like.  If so, I'd ask you to stop confuzzilating terminology.

If you really want to capture such events, then you need to have the
kernel write the panic to (e.g.) flash - see the mtdoops driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 17:30           ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-08 17:30 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, LKML, Ralf Baechle,
	Paul Mackerras, Andrew Morton, linux-ia64, Tetsuo Handa,
	James Hogan, James E.J. Bottomley, Max Filippov, Vincent Chen,
	Ingo Molnar, linux-s390, linux-c6x-dev, Yoshinori Sato,
	linux-hexagon, Helge Deller,
	open list:TENSILICA XTENSA PORT (xtensa),
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, X86 ML, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
> On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> [..]
> >> Sorry, I should have tried to describe better.
> >>
> >> I'm trying to remove external users of console_loglevel by following
> >> reasons:
> >
> > I suppose since all my machines have 'debug ignore_loglevel
> > earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> > experience.
> 
> Yeah, I remember you avoid all those functionalities of printk(), fair
> enough. On the other side, regular users and I'm betting most of
> the non-tuned distributions use /proc/sys/kernel/printk by default.
> (Checking on my Arch & Fedora - loglevel 4 from the box)
> 
> >> - changing console_loglevel on SMP means that unwanted messages from
> >> other CPUs will appear (that have lower log level)
> >> - on UMP unwanted messages may appear if the code is preempted while it
> >> hasn't set the console_loglevel back to old
> >> - rising console_loglevel to print wanted message(s) may not work at all
> >> if printk() has being delayed and the console_loglevel is already set
> >> back to old value
> >
> > Sure, frobbing the global console_loglevel is bad.
> >
> >> I also have patches in wip those needs to print backtrace with specific
> >> loglevel (higher when it's critical, lower when it's notice and
> >> shouldn't go to serial console).
> >
> > (everything always should go to serial, serial is awesome :-)
> 
> Personally I agree. Unfortunately, here @Arista there are switches (I'm
> speaking about the order of thousands at least) those have baud-rate 9600.
> It's a bit expensive being elaborate with such setup.
> 
> >> Besides on local tests I see hits those have headers (messages like
> >> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> >> without a reason for it. It's quite annoying and worth addressing by
> >> syncing headers log levels to backtraces.
> >
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.
> >
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?
> 
> Well, the use-case for lower log-level is that everything goes into logs
> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
> 
> That has it's value:
> - after a failure (i.e. panic) messages, those were only signs that
> something goes wrong can be seen in logs which can give ideas what has
> happened.

No they don't.  When the kernel panics, userspace generally stops
running, so rsyslog won't be able to write them to /var/log/messages.

How, by "kernel panics" I mean a real kernel panic, which probably
isn't what you're talking about there.  You are probably talking
about the whole shebang of non-fatal kernel oops, kernel warnings
and the like.  If so, I'd ask you to stop confuzzilating terminology.

If you really want to capture such events, then you need to have the
kernel write the panic to (e.g.) flash - see the mtdoops driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 17:30           ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-08 17:30 UTC (permalink / raw)
  To: openrisc

On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
> On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> [..]
> >> Sorry, I should have tried to describe better.
> >>
> >> I'm trying to remove external users of console_loglevel by following
> >> reasons:
> >
> > I suppose since all my machines have 'debug ignore_loglevel
> > earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> > experience.
> 
> Yeah, I remember you avoid all those functionalities of printk(), fair
> enough. On the other side, regular users and I'm betting most of
> the non-tuned distributions use /proc/sys/kernel/printk by default.
> (Checking on my Arch & Fedora - loglevel 4 from the box)
> 
> >> - changing console_loglevel on SMP means that unwanted messages from
> >> other CPUs will appear (that have lower log level)
> >> - on UMP unwanted messages may appear if the code is preempted while it
> >> hasn't set the console_loglevel back to old
> >> - rising console_loglevel to print wanted message(s) may not work at all
> >> if printk() has being delayed and the console_loglevel is already set
> >> back to old value
> >
> > Sure, frobbing the global console_loglevel is bad.
> >
> >> I also have patches in wip those needs to print backtrace with specific
> >> loglevel (higher when it's critical, lower when it's notice and
> >> shouldn't go to serial console).
> >
> > (everything always should go to serial, serial is awesome :-)
> 
> Personally I agree. Unfortunately, here @Arista there are switches (I'm
> speaking about the order of thousands at least) those have baud-rate 9600.
> It's a bit expensive being elaborate with such setup.
> 
> >> Besides on local tests I see hits those have headers (messages like
> >> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> >> without a reason for it. It's quite annoying and worth addressing by
> >> syncing headers log levels to backtraces.
> >
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.
> >
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?
> 
> Well, the use-case for lower log-level is that everything goes into logs
> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
> 
> That has it's value:
> - after a failure (i.e. panic) messages, those were only signs that
> something goes wrong can be seen in logs which can give ideas what has
> happened.

No they don't.  When the kernel panics, userspace generally stops
running, so rsyslog won't be able to write them to /var/log/messages.

How, by "kernel panics" I mean a real kernel panic, which probably
isn't what you're talking about there.  You are probably talking
about the whole shebang of non-fatal kernel oops, kernel warnings
and the like.  If so, I'd ask you to stop confuzzilating terminology.

If you really want to capture such events, then you need to have the
kernel write the panic to (e.g.) flash - see the mtdoops driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 17:30           ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-08 17:30 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Peter Zijlstra, LKML, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	linux-arm-kernel, clang-built-linux, Catalin Marinas,
	Aurelien Jacquiot, Mark Salter, linux-c6x-dev, Guo Ren,
	Yoshinori Sato, uclinux-h8-devel, Brian Cain, linux-hexagon,
	Fenghua Yu, Tony Luck, linux-ia64, Geert Uytterhoeven,
	linux-m68k, Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, X86 ML, Chris Zankel,
	Max Filippov, open list:TENSILICA XTENSA PORT (xtensa),
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
> On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> [..]
> >> Sorry, I should have tried to describe better.
> >>
> >> I'm trying to remove external users of console_loglevel by following
> >> reasons:
> >
> > I suppose since all my machines have 'debug ignore_loglevel
> > earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> > experience.
> 
> Yeah, I remember you avoid all those functionalities of printk(), fair
> enough. On the other side, regular users and I'm betting most of
> the non-tuned distributions use /proc/sys/kernel/printk by default.
> (Checking on my Arch & Fedora - loglevel 4 from the box)
> 
> >> - changing console_loglevel on SMP means that unwanted messages from
> >> other CPUs will appear (that have lower log level)
> >> - on UMP unwanted messages may appear if the code is preempted while it
> >> hasn't set the console_loglevel back to old
> >> - rising console_loglevel to print wanted message(s) may not work at all
> >> if printk() has being delayed and the console_loglevel is already set
> >> back to old value
> >
> > Sure, frobbing the global console_loglevel is bad.
> >
> >> I also have patches in wip those needs to print backtrace with specific
> >> loglevel (higher when it's critical, lower when it's notice and
> >> shouldn't go to serial console).
> >
> > (everything always should go to serial, serial is awesome :-)
> 
> Personally I agree. Unfortunately, here @Arista there are switches (I'm
> speaking about the order of thousands at least) those have baud-rate 9600.
> It's a bit expensive being elaborate with such setup.
> 
> >> Besides on local tests I see hits those have headers (messages like
> >> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> >> without a reason for it. It's quite annoying and worth addressing by
> >> syncing headers log levels to backtraces.
> >
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.
> >
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?
> 
> Well, the use-case for lower log-level is that everything goes into logs
> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
> 
> That has it's value:
> - after a failure (i.e. panic) messages, those were only signs that
> something goes wrong can be seen in logs which can give ideas what has
> happened.

No they don't.  When the kernel panics, userspace generally stops
running, so rsyslog won't be able to write them to /var/log/messages.

How, by "kernel panics" I mean a real kernel panic, which probably
isn't what you're talking about there.  You are probably talking
about the whole shebang of non-fatal kernel oops, kernel warnings
and the like.  If so, I'd ask you to stop confuzzilating terminology.

If you really want to capture such events, then you need to have the
kernel write the panic to (e.g.) flash - see the mtdoops driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 17:30           ` Russell King - ARM Linux admin
  0 siblings, 0 replies; 323+ messages in thread
From: Russell King - ARM Linux admin @ 2019-11-08 17:30 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, LKML, Ralf

On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
> On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
> [..]
> >> Sorry, I should have tried to describe better.
> >>
> >> I'm trying to remove external users of console_loglevel by following
> >> reasons:
> >
> > I suppose since all my machines have 'debug ignore_loglevel
> > earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this
> > experience.
> 
> Yeah, I remember you avoid all those functionalities of printk(), fair
> enough. On the other side, regular users and I'm betting most of
> the non-tuned distributions use /proc/sys/kernel/printk by default.
> (Checking on my Arch & Fedora - loglevel 4 from the box)
> 
> >> - changing console_loglevel on SMP means that unwanted messages from
> >> other CPUs will appear (that have lower log level)
> >> - on UMP unwanted messages may appear if the code is preempted while it
> >> hasn't set the console_loglevel back to old
> >> - rising console_loglevel to print wanted message(s) may not work at all
> >> if printk() has being delayed and the console_loglevel is already set
> >> back to old value
> >
> > Sure, frobbing the global console_loglevel is bad.
> >
> >> I also have patches in wip those needs to print backtrace with specific
> >> loglevel (higher when it's critical, lower when it's notice and
> >> shouldn't go to serial console).
> >
> > (everything always should go to serial, serial is awesome :-)
> 
> Personally I agree. Unfortunately, here @Arista there are switches (I'm
> speaking about the order of thousands at least) those have baud-rate 9600.
> It's a bit expensive being elaborate with such setup.
> 
> >> Besides on local tests I see hits those have headers (messages like
> >> "Backtrace: ") without an actual backtrace and the reverse - a backtrace
> >> without a reason for it. It's quite annoying and worth addressing by
> >> syncing headers log levels to backtraces.
> >
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.
> >
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?
> 
> Well, the use-case for lower log-level is that everything goes into logs
> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
> 
> That has it's value:
> - after a failure (i.e. panic) messages, those were only signs that
> something goes wrong can be seen in logs which can give ideas what has
> happened.

No they don't.  When the kernel panics, userspace generally stops
running, so rsyslog won't be able to write them to /var/log/messages.

How, by "kernel panics" I mean a real kernel panic, which probably
isn't what you're talking about there.  You are probably talking
about the whole shebang of non-fatal kernel oops, kernel warnings
and the like.  If so, I'd ask you to stop confuzzilating terminology.

If you really want to capture such events, then you need to have the
kernel write the panic to (e.g.) flash - see the mtdoops driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-08 17:30           ` Russell King - ARM Linux admin
                               ` (3 preceding siblings ...)
  (?)
@ 2019-11-08 21:08             ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 21:08 UTC (permalink / raw)
  To: Russell King - ARM Linux admin, Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, LKML, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, open list:TENSILICA XTENSA PORT (xtensa),
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Heiko Carstens, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, X86 ML, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev


On 11/8/19 5:30 PM, Russell King - ARM Linux admin wrote:
> On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
[..]
>>
>> Well, the use-case for lower log-level is that everything goes into logs
>> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
>>
>> That has it's value:
>> - after a failure (i.e. panic) messages, those were only signs that
>> something goes wrong can be seen in logs which can give ideas what has
>> happened.
> 
> No they don't.  When the kernel panics, userspace generally stops
> running, so rsyslog won't be able to write them to /var/log/messages.
> 
> How, by "kernel panics" I mean a real kernel panic, which probably
> isn't what you're talking about there.  You are probably talking
> about the whole shebang of non-fatal kernel oops, kernel warnings
> and the like.  If so, I'd ask you to stop confuzzilating terminology.
> 
> If you really want to capture such events, then you need to have the
> kernel write the panic to (e.g.) flash - see the mtdoops driver.

I was talking about things prior the panic: OOMs, MMC write/read
warnings, hung tasks, we also have local patches to produce a warning if
the mutex is being held for too long or a task is starving on CPU time
by hard/soft irqs (I hope I will design something like that for
upstream). I've found those warnings useful to:
(a) have an early message when the things are starting going bad.
(b) analyze contentions or too large scale for a box or faulty hardware
for non-reproducible issues just from logs.

We use kexec to save the dmesg ringbuffer content after the panic.

Thanks,
          Dmitry

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 21:08             ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 21:08 UTC (permalink / raw)
  To: Russell King - ARM Linux admin, Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki, LKML,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller,
	open list:TENSILICA XTENSA PORT (xtensa),
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Heiko Carstens, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Petr Mladek, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger,
	X86 ML, clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev


On 11/8/19 5:30 PM, Russell King - ARM Linux admin wrote:
> On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
[..]
>>
>> Well, the use-case for lower log-level is that everything goes into logs
>> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
>>
>> That has it's value:
>> - after a failure (i.e. panic) messages, those were only signs that
>> something goes wrong can be seen in logs which can give ideas what has
>> happened.
> 
> No they don't.  When the kernel panics, userspace generally stops
> running, so rsyslog won't be able to write them to /var/log/messages.
> 
> How, by "kernel panics" I mean a real kernel panic, which probably
> isn't what you're talking about there.  You are probably talking
> about the whole shebang of non-fatal kernel oops, kernel warnings
> and the like.  If so, I'd ask you to stop confuzzilating terminology.
> 
> If you really want to capture such events, then you need to have the
> kernel write the panic to (e.g.) flash - see the mtdoops driver.

I was talking about things prior the panic: OOMs, MMC write/read
warnings, hung tasks, we also have local patches to produce a warning if
the mutex is being held for too long or a task is starving on CPU time
by hard/soft irqs (I hope I will design something like that for
upstream). I've found those warnings useful to:
(a) have an early message when the things are starting going bad.
(b) analyze contentions or too large scale for a box or faulty hardware
for non-reproducible issues just from logs.

We use kexec to save the dmesg ringbuffer content after the panic.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 21:08             ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 21:08 UTC (permalink / raw)
  To: Russell King - ARM Linux admin, Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, LKML, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, open list:TENSILICA XTENSA PORT (xtensa),
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Heiko Carstens, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, X86 ML, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev


On 11/8/19 5:30 PM, Russell King - ARM Linux admin wrote:
> On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
[..]
>>
>> Well, the use-case for lower log-level is that everything goes into logs
>> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
>>
>> That has it's value:
>> - after a failure (i.e. panic) messages, those were only signs that
>> something goes wrong can be seen in logs which can give ideas what has
>> happened.
> 
> No they don't.  When the kernel panics, userspace generally stops
> running, so rsyslog won't be able to write them to /var/log/messages.
> 
> How, by "kernel panics" I mean a real kernel panic, which probably
> isn't what you're talking about there.  You are probably talking
> about the whole shebang of non-fatal kernel oops, kernel warnings
> and the like.  If so, I'd ask you to stop confuzzilating terminology.
> 
> If you really want to capture such events, then you need to have the
> kernel write the panic to (e.g.) flash - see the mtdoops driver.

I was talking about things prior the panic: OOMs, MMC write/read
warnings, hung tasks, we also have local patches to produce a warning if
the mutex is being held for too long or a task is starving on CPU time
by hard/soft irqs (I hope I will design something like that for
upstream). I've found those warnings useful to:
(a) have an early message when the things are starting going bad.
(b) analyze contentions or too large scale for a box or faulty hardware
for non-reproducible issues just from logs.

We use kexec to save the dmesg ringbuffer content after the panic.

Thanks,
          Dmitry

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 21:08             ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 21:08 UTC (permalink / raw)
  To: openrisc


On 11/8/19 5:30 PM, Russell King - ARM Linux admin wrote:
> On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
[..]
>>
>> Well, the use-case for lower log-level is that everything goes into logs
>> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
>>
>> That has it's value:
>> - after a failure (i.e. panic) messages, those were only signs that
>> something goes wrong can be seen in logs which can give ideas what has
>> happened.
> 
> No they don't.  When the kernel panics, userspace generally stops
> running, so rsyslog won't be able to write them to /var/log/messages.
> 
> How, by "kernel panics" I mean a real kernel panic, which probably
> isn't what you're talking about there.  You are probably talking
> about the whole shebang of non-fatal kernel oops, kernel warnings
> and the like.  If so, I'd ask you to stop confuzzilating terminology.
> 
> If you really want to capture such events, then you need to have the
> kernel write the panic to (e.g.) flash - see the mtdoops driver.

I was talking about things prior the panic: OOMs, MMC write/read
warnings, hung tasks, we also have local patches to produce a warning if
the mutex is being held for too long or a task is starving on CPU time
by hard/soft irqs (I hope I will design something like that for
upstream). I've found those warnings useful to:
(a) have an early message when the things are starting going bad.
(b) analyze contentions or too large scale for a box or faulty hardware
for non-reproducible issues just from logs.

We use kexec to save the dmesg ringbuffer content after the panic.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 21:08             ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 21:08 UTC (permalink / raw)
  To: Russell King - ARM Linux admin, Dmitry Safonov
  Cc: Peter Zijlstra, LKML, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Ralf Baechle, Thomas Gleixner,
	Vincent Chen, Vincent Guittot, Will Deacon, linux-mips,
	linux-riscv, Ivan Kokshaysky, Matt Turner, Richard Henderson,
	linux-alpha, Vineet Gupta, linux-snps-arc, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, X86 ML, Chris Zankel,
	Max Filippov, open list:TENSILICA XTENSA PORT (xtensa),
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport


On 11/8/19 5:30 PM, Russell King - ARM Linux admin wrote:
> On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
[..]
>>
>> Well, the use-case for lower log-level is that everything goes into logs
>> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
>>
>> That has it's value:
>> - after a failure (i.e. panic) messages, those were only signs that
>> something goes wrong can be seen in logs which can give ideas what has
>> happened.
> 
> No they don't.  When the kernel panics, userspace generally stops
> running, so rsyslog won't be able to write them to /var/log/messages.
> 
> How, by "kernel panics" I mean a real kernel panic, which probably
> isn't what you're talking about there.  You are probably talking
> about the whole shebang of non-fatal kernel oops, kernel warnings
> and the like.  If so, I'd ask you to stop confuzzilating terminology.
> 
> If you really want to capture such events, then you need to have the
> kernel write the panic to (e.g.) flash - see the mtdoops driver.

I was talking about things prior the panic: OOMs, MMC write/read
warnings, hung tasks, we also have local patches to produce a warning if
the mutex is being held for too long or a task is starving on CPU time
by hard/soft irqs (I hope I will design something like that for
upstream). I've found those warnings useful to:
(a) have an early message when the things are starting going bad.
(b) analyze contentions or too large scale for a box or faulty hardware
for non-reproducible issues just from logs.

We use kexec to save the dmesg ringbuffer content after the panic.

Thanks,
          Dmitry


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-08 21:08             ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-08 21:08 UTC (permalink / raw)
  To: Russell King - ARM Linux admin, Dmitry Safonov
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, LKML, Ralf Baechle, Paul Mackerras


On 11/8/19 5:30 PM, Russell King - ARM Linux admin wrote:
> On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
[..]
>>
>> Well, the use-case for lower log-level is that everything goes into logs
>> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
>>
>> That has it's value:
>> - after a failure (i.e. panic) messages, those were only signs that
>> something goes wrong can be seen in logs which can give ideas what has
>> happened.
> 
> No they don't.  When the kernel panics, userspace generally stops
> running, so rsyslog won't be able to write them to /var/log/messages.
> 
> How, by "kernel panics" I mean a real kernel panic, which probably
> isn't what you're talking about there.  You are probably talking
> about the whole shebang of non-fatal kernel oops, kernel warnings
> and the like.  If so, I'd ask you to stop confuzzilating terminology.
> 
> If you really want to capture such events, then you need to have the
> kernel write the panic to (e.g.) flash - see the mtdoops driver.

I was talking about things prior the panic: OOMs, MMC write/read
warnings, hung tasks, we also have local patches to produce a warning if
the mutex is being held for too long or a task is starving on CPU time
by hard/soft irqs (I hope I will design something like that for
upstream). I've found those warnings useful to:
(a) have an early message when the things are starting going bad.
(b) analyze contentions or too large scale for a box or faulty hardware
for non-reproducible issues just from logs.

We use kexec to save the dmesg ringbuffer content after the panic.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-08 13:04       ` Petr Mladek
                           ` (3 preceding siblings ...)
  (?)
@ 2019-11-11  1:23         ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-11  1:23 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/08 14:04), Petr Mladek wrote:
[..]
> I agree that it is complicated to pass the loglevel as
> a parameter. It would be better define the default
> log level for a given code section. It might be stored
> in task_struct for the normal context and in per-CPU
> variables for interrupt contexts.

I do recall that we talked about per-CPU printk state bit which would
start/end "just print it" section. We probably can extend it to "just
log_store" type of functionality. Doesn't look like a very bad idea.
"This task/context is in trouble, whatever it printk()-s is important".

Per-console loglevel also might help sometimes. Slower consoles would
->write() only critical messages, faster consoles everything.

Passing log_level as part of message payload, which printk machinery
magically hides is not entirely exciting. What we have in the code
now - printk("%s blah\n", lvl) - is not what we see in the logs.
Because the leading '%s' becomes special. And printk()/sprintf()
documentation should reflect that: '%s' prints a string, but sometimes
it doesn't.

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  1:23         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-11  1:23 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Dmitry Safonov, Will Deacon, Daniel Thompson,
	Brian Cain, Christian Borntraeger, kgdb-bugreport,
	linux-snps-arc, Fenghua Yu, Borislav Petkov, Jeff Dike,
	Steven Rostedt, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/08 14:04), Petr Mladek wrote:
[..]
> I agree that it is complicated to pass the loglevel as
> a parameter. It would be better define the default
> log level for a given code section. It might be stored
> in task_struct for the normal context and in per-CPU
> variables for interrupt contexts.

I do recall that we talked about per-CPU printk state bit which would
start/end "just print it" section. We probably can extend it to "just
log_store" type of functionality. Doesn't look like a very bad idea.
"This task/context is in trouble, whatever it printk()-s is important".

Per-console loglevel also might help sometimes. Slower consoles would
->write() only critical messages, faster consoles everything.

Passing log_level as part of message payload, which printk machinery
magically hides is not entirely exciting. What we have in the code
now - printk("%s blah\n", lvl) - is not what we see in the logs.
Because the leading '%s' becomes special. And printk()/sprintf()
documentation should reflect that: '%s' prints a string, but sometimes
it doesn't.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  1:23         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-11  1:23 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/08 14:04), Petr Mladek wrote:
[..]
> I agree that it is complicated to pass the loglevel as
> a parameter. It would be better define the default
> log level for a given code section. It might be stored
> in task_struct for the normal context and in per-CPU
> variables for interrupt contexts.

I do recall that we talked about per-CPU printk state bit which would
start/end "just print it" section. We probably can extend it to "just
log_store" type of functionality. Doesn't look like a very bad idea.
"This task/context is in trouble, whatever it printk()-s is important".

Per-console loglevel also might help sometimes. Slower consoles would
->write() only critical messages, faster consoles everything.

Passing log_level as part of message payload, which printk machinery
magically hides is not entirely exciting. What we have in the code
now - printk("%s blah\n", lvl) - is not what we see in the logs.
Because the leading '%s' becomes special. And printk()/sprintf()
documentation should reflect that: '%s' prints a string, but sometimes
it doesn't.

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  1:23         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-11  1:23 UTC (permalink / raw)
  To: openrisc

On (19/11/08 14:04), Petr Mladek wrote:
[..]
> I agree that it is complicated to pass the loglevel as
> a parameter. It would be better define the default
> log level for a given code section. It might be stored
> in task_struct for the normal context and in per-CPU
> variables for interrupt contexts.

I do recall that we talked about per-CPU printk state bit which would
start/end "just print it" section. We probably can extend it to "just
log_store" type of functionality. Doesn't look like a very bad idea.
"This task/context is in trouble, whatever it printk()-s is important".

Per-console loglevel also might help sometimes. Slower consoles would
->write() only critical messages, faster consoles everything.

Passing log_level as part of message payload, which printk machinery
magically hides is not entirely exciting. What we have in the code
now - printk("%s blah\n", lvl) - is not what we see in the logs.
Because the leading '%s' becomes special. And printk()/sprintf()
documentation should reflect that: '%s' prints a string, but sometimes
it doesn't.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  1:23         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-11  1:23 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sergey Senozhatsky, Dmitry Safonov, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On (19/11/08 14:04), Petr Mladek wrote:
[..]
> I agree that it is complicated to pass the loglevel as
> a parameter. It would be better define the default
> log level for a given code section. It might be stored
> in task_struct for the normal context and in per-CPU
> variables for interrupt contexts.

I do recall that we talked about per-CPU printk state bit which would
start/end "just print it" section. We probably can extend it to "just
log_store" type of functionality. Doesn't look like a very bad idea.
"This task/context is in trouble, whatever it printk()-s is important".

Per-console loglevel also might help sometimes. Slower consoles would
->write() only critical messages, faster consoles everything.

Passing log_level as part of message payload, which printk machinery
magically hides is not entirely exciting. What we have in the code
now - printk("%s blah\n", lvl) - is not what we see in the logs.
Because the leading '%s' becomes special. And printk()/sprintf()
documentation should reflect that: '%s' prints a string, but sometimes
it doesn't.

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  1:23         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-11  1:23 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman

On (19/11/08 14:04), Petr Mladek wrote:
[..]
> I agree that it is complicated to pass the loglevel as
> a parameter. It would be better define the default
> log level for a given code section. It might be stored
> in task_struct for the normal context and in per-CPU
> variables for interrupt contexts.

I do recall that we talked about per-CPU printk state bit which would
start/end "just print it" section. We probably can extend it to "just
log_store" type of functionality. Doesn't look like a very bad idea.
"This task/context is in trouble, whatever it printk()-s is important".

Per-console loglevel also might help sometimes. Slower consoles would
->write() only critical messages, faster consoles everything.

Passing log_level as part of message payload, which printk machinery
magically hides is not entirely exciting. What we have in the code
now - printk("%s blah\n", lvl) - is not what we see in the logs.
Because the leading '%s' becomes special. And printk()/sprintf()
documentation should reflect that: '%s' prints a string, but sometimes
it doesn't.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-11  1:23         ` Sergey Senozhatsky
                             ` (3 preceding siblings ...)
  (?)
@ 2019-11-11  9:12           ` Petr Mladek
  -1 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-11  9:12 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Mon 2019-11-11 10:23:36, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
> > I agree that it is complicated to pass the loglevel as
> > a parameter. It would be better define the default
> > log level for a given code section. It might be stored
> > in task_struct for the normal context and in per-CPU
> > variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.

The problem with per-CPU printk is that we would need to disable
interrupts. It is not always wanted. Also people might not expect
this from a printk() API.


> "This task/context is in trouble, whatever it printk()-s is important".

It might be a minimal loglevel. More important messages would still
be printed() with the higher loglevel.

But yes, this per-code-section loglevel is problematic. The feedback
against the patchset shows that people want it also the other way.
I mean to keep pr_debug() as pr_debug().

A solution might be to use the per-code-section loglevel only instead
of some special loglevel.


> Per-console loglevel also might help sometimes. Slower consoles would
> ->write() only critical messages, faster consoles everything.

This looks like another problem to me. Anyway, this filtering will
work better when the loglevel will be consistent across the related
lines.

> Passing log_level as part of message payload, which printk machinery
> magically hides is not entirely exciting. What we have in the code
> now - printk("%s blah\n", lvl) - is not what we see in the logs.
> Because the leading '%s' becomes special. And printk()/sprintf()
> documentation should reflect that: '%s' prints a string, but sometimes
> it doesn't.

I personally do not see this as a big problem.

The explicitly passed loglevel makes me feel more confident that
all needed printk() calls were updated. But it might be a false
feeling. I do not really have any strong preference.

Best Regards,
Petr

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  9:12           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-11  9:12 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Mon 2019-11-11 10:23:36, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
> > I agree that it is complicated to pass the loglevel as
> > a parameter. It would be better define the default
> > log level for a given code section. It might be stored
> > in task_struct for the normal context and in per-CPU
> > variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.

The problem with per-CPU printk is that we would need to disable
interrupts. It is not always wanted. Also people might not expect
this from a printk() API.


> "This task/context is in trouble, whatever it printk()-s is important".

It might be a minimal loglevel. More important messages would still
be printed() with the higher loglevel.

But yes, this per-code-section loglevel is problematic. The feedback
against the patchset shows that people want it also the other way.
I mean to keep pr_debug() as pr_debug().

A solution might be to use the per-code-section loglevel only instead
of some special loglevel.


> Per-console loglevel also might help sometimes. Slower consoles would
> ->write() only critical messages, faster consoles everything.

This looks like another problem to me. Anyway, this filtering will
work better when the loglevel will be consistent across the related
lines.

> Passing log_level as part of message payload, which printk machinery
> magically hides is not entirely exciting. What we have in the code
> now - printk("%s blah\n", lvl) - is not what we see in the logs.
> Because the leading '%s' becomes special. And printk()/sprintf()
> documentation should reflect that: '%s' prints a string, but sometimes
> it doesn't.

I personally do not see this as a big problem.

The explicitly passed loglevel makes me feel more confident that
all needed printk() calls were updated. But it might be a false
feeling. I do not really have any strong preference.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  9:12           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-11  9:12 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Mon 2019-11-11 10:23:36, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
> > I agree that it is complicated to pass the loglevel as
> > a parameter. It would be better define the default
> > log level for a given code section. It might be stored
> > in task_struct for the normal context and in per-CPU
> > variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.

The problem with per-CPU printk is that we would need to disable
interrupts. It is not always wanted. Also people might not expect
this from a printk() API.


> "This task/context is in trouble, whatever it printk()-s is important".

It might be a minimal loglevel. More important messages would still
be printed() with the higher loglevel.

But yes, this per-code-section loglevel is problematic. The feedback
against the patchset shows that people want it also the other way.
I mean to keep pr_debug() as pr_debug().

A solution might be to use the per-code-section loglevel only instead
of some special loglevel.


> Per-console loglevel also might help sometimes. Slower consoles would
> ->write() only critical messages, faster consoles everything.

This looks like another problem to me. Anyway, this filtering will
work better when the loglevel will be consistent across the related
lines.

> Passing log_level as part of message payload, which printk machinery
> magically hides is not entirely exciting. What we have in the code
> now - printk("%s blah\n", lvl) - is not what we see in the logs.
> Because the leading '%s' becomes special. And printk()/sprintf()
> documentation should reflect that: '%s' prints a string, but sometimes
> it doesn't.

I personally do not see this as a big problem.

The explicitly passed loglevel makes me feel more confident that
all needed printk() calls were updated. But it might be a false
feeling. I do not really have any strong preference.

Best Regards,
Petr

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  9:12           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-11  9:12 UTC (permalink / raw)
  To: openrisc

On Mon 2019-11-11 10:23:36, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
> > I agree that it is complicated to pass the loglevel as
> > a parameter. It would be better define the default
> > log level for a given code section. It might be stored
> > in task_struct for the normal context and in per-CPU
> > variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.

The problem with per-CPU printk is that we would need to disable
interrupts. It is not always wanted. Also people might not expect
this from a printk() API.


> "This task/context is in trouble, whatever it printk()-s is important".

It might be a minimal loglevel. More important messages would still
be printed() with the higher loglevel.

But yes, this per-code-section loglevel is problematic. The feedback
against the patchset shows that people want it also the other way.
I mean to keep pr_debug() as pr_debug().

A solution might be to use the per-code-section loglevel only instead
of some special loglevel.


> Per-console loglevel also might help sometimes. Slower consoles would
> ->write() only critical messages, faster consoles everything.

This looks like another problem to me. Anyway, this filtering will
work better when the loglevel will be consistent across the related
lines.

> Passing log_level as part of message payload, which printk machinery
> magically hides is not entirely exciting. What we have in the code
> now - printk("%s blah\n", lvl) - is not what we see in the logs.
> Because the leading '%s' becomes special. And printk()/sprintf()
> documentation should reflect that: '%s' prints a string, but sometimes
> it doesn't.

I personally do not see this as a big problem.

The explicitly passed loglevel makes me feel more confident that
all needed printk() calls were updated. But it might be a false
feeling. I do not really have any strong preference.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  9:12           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-11  9:12 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Dmitry Safonov, linux-kernel, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J. Bottomley, linux-parisc,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev, Christian Borntraeger, Heiko Carstens,
	Vasily Gorbik, linux-s390, Rich Felker, linux-sh,
	David S. Miller, sparclinux, Anton Ivanov, Jeff Dike,
	Richard Weinberger, linux-um, Guan Xuetao, Borislav Petkov,
	H. Peter Anvin, x86, Chris Zankel, Max Filippov, linux-xtensa,
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

On Mon 2019-11-11 10:23:36, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
> > I agree that it is complicated to pass the loglevel as
> > a parameter. It would be better define the default
> > log level for a given code section. It might be stored
> > in task_struct for the normal context and in per-CPU
> > variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.

The problem with per-CPU printk is that we would need to disable
interrupts. It is not always wanted. Also people might not expect
this from a printk() API.


> "This task/context is in trouble, whatever it printk()-s is important".

It might be a minimal loglevel. More important messages would still
be printed() with the higher loglevel.

But yes, this per-code-section loglevel is problematic. The feedback
against the patchset shows that people want it also the other way.
I mean to keep pr_debug() as pr_debug().

A solution might be to use the per-code-section loglevel only instead
of some special loglevel.


> Per-console loglevel also might help sometimes. Slower consoles would
> ->write() only critical messages, faster consoles everything.

This looks like another problem to me. Anyway, this filtering will
work better when the loglevel will be consistent across the related
lines.

> Passing log_level as part of message payload, which printk machinery
> magically hides is not entirely exciting. What we have in the code
> now - printk("%s blah\n", lvl) - is not what we see in the logs.
> Because the leading '%s' becomes special. And printk()/sprintf()
> documentation should reflect that: '%s' prints a string, but sometimes
> it doesn't.

I personally do not see this as a big problem.

The explicitly passed loglevel makes me feel more confident that
all needed printk() calls were updated. But it might be a false
feeling. I do not really have any strong preference.

Best Regards,
Petr


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11  9:12           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-11  9:12 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On Mon 2019-11-11 10:23:36, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
> > I agree that it is complicated to pass the loglevel as
> > a parameter. It would be better define the default
> > log level for a given code section. It might be stored
> > in task_struct for the normal context and in per-CPU
> > variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.

The problem with per-CPU printk is that we would need to disable
interrupts. It is not always wanted. Also people might not expect
this from a printk() API.


> "This task/context is in trouble, whatever it printk()-s is important".

It might be a minimal loglevel. More important messages would still
be printed() with the higher loglevel.

But yes, this per-code-section loglevel is problematic. The feedback
against the patchset shows that people want it also the other way.
I mean to keep pr_debug() as pr_debug().

A solution might be to use the per-code-section loglevel only instead
of some special loglevel.


> Per-console loglevel also might help sometimes. Slower consoles would
> ->write() only critical messages, faster consoles everything.

This looks like another problem to me. Anyway, this filtering will
work better when the loglevel will be consistent across the related
lines.

> Passing log_level as part of message payload, which printk machinery
> magically hides is not entirely exciting. What we have in the code
> now - printk("%s blah\n", lvl) - is not what we see in the logs.
> Because the leading '%s' becomes special. And printk()/sprintf()
> documentation should reflect that: '%s' prints a string, but sometimes
> it doesn't.

I personally do not see this as a big problem.

The explicitly passed loglevel makes me feel more confident that
all needed printk() calls were updated. But it might be a false
feeling. I do not really have any strong preference.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-11  1:23         ` Sergey Senozhatsky
                             ` (3 preceding siblings ...)
  (?)
@ 2019-11-11 19:47           ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-11 19:47 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

Hi Sergey, Petr,

On 11/11/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
>> I agree that it is complicated to pass the loglevel as
>> a parameter. It would be better define the default
>> log level for a given code section. It might be stored
>> in task_struct for the normal context and in per-CPU
>> variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.
> "This task/context is in trouble, whatever it printk()-s is important".

I don't see how bits on task_struct or in per-cpu are easier than
supplying a log level parameter down the stack.
How would it work if sysrq_handle_crash() called by key-press?
How would that interact with deferred printing?
How would it make visible prints from current context, but not from
something that preempted it?

Furthermore, what problems are you trying to solve with this design?
Only sysrq driver? Kdb?
In my perspective it sounds too complicated and over-engineered for
something that has two-three users.
Also I've tried to point that I need to print backtrace sometimes with
KERN_DEBUG loglevel to use it in production for early notices those
needs to go only to log files and currently each architecture decides
which log level it prefers.

And what's so complicated about this patches set? I see only side of the
testing, but the build-testing is covered with 0day bot and cost nothing
and any visible regression may be found during -next period.
While introducing those printk-sections may subtly break things.

I mean, I definitely know less about printk() and its internals than you
- so my points may be a no-sense.

What I'm going to do - is to fix all build and reported issues, I'll
send v2 this week and feel free to NAK it, I will forget about those
patches and won't be offended.
I don't see many people those are "hey, we'll benefit from this".
And doing this patches set was neither quite fun (dirty business), nor
something I can be later proud of (hey, I've introduced the log level
parameter to printing functions!).

Thanks,
          Dima

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11 19:47           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-11 19:47 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

Hi Sergey, Petr,

On 11/11/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
>> I agree that it is complicated to pass the loglevel as
>> a parameter. It would be better define the default
>> log level for a given code section. It might be stored
>> in task_struct for the normal context and in per-CPU
>> variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.
> "This task/context is in trouble, whatever it printk()-s is important".

I don't see how bits on task_struct or in per-cpu are easier than
supplying a log level parameter down the stack.
How would it work if sysrq_handle_crash() called by key-press?
How would that interact with deferred printing?
How would it make visible prints from current context, but not from
something that preempted it?

Furthermore, what problems are you trying to solve with this design?
Only sysrq driver? Kdb?
In my perspective it sounds too complicated and over-engineered for
something that has two-three users.
Also I've tried to point that I need to print backtrace sometimes with
KERN_DEBUG loglevel to use it in production for early notices those
needs to go only to log files and currently each architecture decides
which log level it prefers.

And what's so complicated about this patches set? I see only side of the
testing, but the build-testing is covered with 0day bot and cost nothing
and any visible regression may be found during -next period.
While introducing those printk-sections may subtly break things.

I mean, I definitely know less about printk() and its internals than you
- so my points may be a no-sense.

What I'm going to do - is to fix all build and reported issues, I'll
send v2 this week and feel free to NAK it, I will forget about those
patches and won't be offended.
I don't see many people those are "hey, we'll benefit from this".
And doing this patches set was neither quite fun (dirty business), nor
something I can be later proud of (hey, I've introduced the log level
parameter to printing functions!).

Thanks,
          Dima

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11 19:47           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-11 19:47 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

Hi Sergey, Petr,

On 11/11/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
>> I agree that it is complicated to pass the loglevel as
>> a parameter. It would be better define the default
>> log level for a given code section. It might be stored
>> in task_struct for the normal context and in per-CPU
>> variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.
> "This task/context is in trouble, whatever it printk()-s is important".

I don't see how bits on task_struct or in per-cpu are easier than
supplying a log level parameter down the stack.
How would it work if sysrq_handle_crash() called by key-press?
How would that interact with deferred printing?
How would it make visible prints from current context, but not from
something that preempted it?

Furthermore, what problems are you trying to solve with this design?
Only sysrq driver? Kdb?
In my perspective it sounds too complicated and over-engineered for
something that has two-three users.
Also I've tried to point that I need to print backtrace sometimes with
KERN_DEBUG loglevel to use it in production for early notices those
needs to go only to log files and currently each architecture decides
which log level it prefers.

And what's so complicated about this patches set? I see only side of the
testing, but the build-testing is covered with 0day bot and cost nothing
and any visible regression may be found during -next period.
While introducing those printk-sections may subtly break things.

I mean, I definitely know less about printk() and its internals than you
- so my points may be a no-sense.

What I'm going to do - is to fix all build and reported issues, I'll
send v2 this week and feel free to NAK it, I will forget about those
patches and won't be offended.
I don't see many people those are "hey, we'll benefit from this".
And doing this patches set was neither quite fun (dirty business), nor
something I can be later proud of (hey, I've introduced the log level
parameter to printing functions!).

Thanks,
          Dima

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11 19:47           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-11 19:47 UTC (permalink / raw)
  To: openrisc

Hi Sergey, Petr,

On 11/11/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
>> I agree that it is complicated to pass the loglevel as
>> a parameter. It would be better define the default
>> log level for a given code section. It might be stored
>> in task_struct for the normal context and in per-CPU
>> variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.
> "This task/context is in trouble, whatever it printk()-s is important".

I don't see how bits on task_struct or in per-cpu are easier than
supplying a log level parameter down the stack.
How would it work if sysrq_handle_crash() called by key-press?
How would that interact with deferred printing?
How would it make visible prints from current context, but not from
something that preempted it?

Furthermore, what problems are you trying to solve with this design?
Only sysrq driver? Kdb?
In my perspective it sounds too complicated and over-engineered for
something that has two-three users.
Also I've tried to point that I need to print backtrace sometimes with
KERN_DEBUG loglevel to use it in production for early notices those
needs to go only to log files and currently each architecture decides
which log level it prefers.

And what's so complicated about this patches set? I see only side of the
testing, but the build-testing is covered with 0day bot and cost nothing
and any visible regression may be found during -next period.
While introducing those printk-sections may subtly break things.

I mean, I definitely know less about printk() and its internals than you
- so my points may be a no-sense.

What I'm going to do - is to fix all build and reported issues, I'll
send v2 this week and feel free to NAK it, I will forget about those
patches and won't be offended.
I don't see many people those are "hey, we'll benefit from this".
And doing this patches set was neither quite fun (dirty business), nor
something I can be later proud of (hey, I've introduced the log level
parameter to printing functions!).

Thanks,
          Dima

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11 19:47           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-11 19:47 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Sergey Senozhatsky, Steven Rostedt,
	Tetsuo Handa, Albert Ou, Ben Segall, Dietmar Eggemann,
	Greentime Hu, Ingo Molnar, James Hogan, Juri Lelli, Mel Gorman,
	Michal Simek, Palmer Dabbelt, Paul Burton, Paul Walmsley,
	Peter Zijlstra, Ralf Baechle, Thomas Gleixner, Vincent Chen,
	Vincent Guittot, Will Deacon, linux-mips, linux-riscv,
	Ivan Kokshaysky, Matt Turner, Richard Henderson, linux-alpha,
	Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

Hi Sergey, Petr,

On 11/11/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
>> I agree that it is complicated to pass the loglevel as
>> a parameter. It would be better define the default
>> log level for a given code section. It might be stored
>> in task_struct for the normal context and in per-CPU
>> variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.
> "This task/context is in trouble, whatever it printk()-s is important".

I don't see how bits on task_struct or in per-cpu are easier than
supplying a log level parameter down the stack.
How would it work if sysrq_handle_crash() called by key-press?
How would that interact with deferred printing?
How would it make visible prints from current context, but not from
something that preempted it?

Furthermore, what problems are you trying to solve with this design?
Only sysrq driver? Kdb?
In my perspective it sounds too complicated and over-engineered for
something that has two-three users.
Also I've tried to point that I need to print backtrace sometimes with
KERN_DEBUG loglevel to use it in production for early notices those
needs to go only to log files and currently each architecture decides
which log level it prefers.

And what's so complicated about this patches set? I see only side of the
testing, but the build-testing is covered with 0day bot and cost nothing
and any visible regression may be found during -next period.
While introducing those printk-sections may subtly break things.

I mean, I definitely know less about printk() and its internals than you
- so my points may be a no-sense.

What I'm going to do - is to fix all build and reported issues, I'll
send v2 this week and feel free to NAK it, I will forget about those
patches and won't be offended.
I don't see many people those are "hey, we'll benefit from this".
And doing this patches set was neither quite fun (dirty business), nor
something I can be later proud of (hey, I've introduced the log level
parameter to printing functions!).

Thanks,
          Dima


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-11 19:47           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-11 19:47 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

Hi Sergey, Petr,

On 11/11/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
>> I agree that it is complicated to pass the loglevel as
>> a parameter. It would be better define the default
>> log level for a given code section. It might be stored
>> in task_struct for the normal context and in per-CPU
>> variables for interrupt contexts.
> 
> I do recall that we talked about per-CPU printk state bit which would
> start/end "just print it" section. We probably can extend it to "just
> log_store" type of functionality. Doesn't look like a very bad idea.
> "This task/context is in trouble, whatever it printk()-s is important".

I don't see how bits on task_struct or in per-cpu are easier than
supplying a log level parameter down the stack.
How would it work if sysrq_handle_crash() called by key-press?
How would that interact with deferred printing?
How would it make visible prints from current context, but not from
something that preempted it?

Furthermore, what problems are you trying to solve with this design?
Only sysrq driver? Kdb?
In my perspective it sounds too complicated and over-engineered for
something that has two-three users.
Also I've tried to point that I need to print backtrace sometimes with
KERN_DEBUG loglevel to use it in production for early notices those
needs to go only to log files and currently each architecture decides
which log level it prefers.

And what's so complicated about this patches set? I see only side of the
testing, but the build-testing is covered with 0day bot and cost nothing
and any visible regression may be found during -next period.
While introducing those printk-sections may subtly break things.

I mean, I definitely know less about printk() and its internals than you
- so my points may be a no-sense.

What I'm going to do - is to fix all build and reported issues, I'll
send v2 this week and feel free to NAK it, I will forget about those
patches and won't be offended.
I don't see many people those are "hey, we'll benefit from this".
And doing this patches set was neither quite fun (dirty business), nor
something I can be later proud of (hey, I've introduced the log level
parameter to printing functions!).

Thanks,
          Dima

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-11 19:47           ` Dmitry Safonov
                               ` (3 preceding siblings ...)
  (?)
@ 2019-11-12  2:17             ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  2:17 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
> I don't see how bits on task_struct or in per-cpu are easier than
> supplying a log level parameter down the stack.
> How would it work if sysrq_handle_crash() called by key-press?
> How would that interact with deferred printing?
> How would it make visible prints from current context, but not from
> something that preempted it?

[..]

per-context log_level works pretty much the same way as per-message
log_level.

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
static DEFINE_PER_CPU(int, cpu_loglevels[4]); // @INITME.. LOGLEVEL_DEBUG + 1?

static int __printing_context(void)
{
	unsigned int preempt = preempt_count();

	if (!(preempt & (NMI_MASK | HARDIRQ_MASK | SOFITRQ_OFFSET)))
		return 0;
	if (preempt & SOFITRQ_OFFSET)
		return 1;
	if (preempt & HARDIRQ_MASK)
		return 2;
	return 3;
}

static int adj_context_loglevel(int level)
{
	int ctx = __printing_context();
	int cpu_level = this_cpu_read(cpu_loglevels[ctx]);

	// this one is important
	if (level == LOGLEVEL_SCHED)
		return level;
	// we are not in emergency context
	if (cpu_level == LOGLEVEL_DEBUG + 1)
		return level;
	// we better not override these
	if (LOGLEVEL_EMERG <= level && level <= LOGLEVEL_ERR)
		return level;
	return cpu_level;
}

void printk_emergency_enter(int log_level)
{
	int ctx;

	preempt_disable();
	ctx = __printing_context();
	this_cpu_write(cpu_loglevels[ctx], log_level);
}

void printk_emergency_exit(void)
{
	int ctx = __printing_context();

	this_cpu_write(cpu_loglevels[ctx], LOGLEVEL_DEBUG + 1);
	preempt_enable();
}

void vprintk_emit(...)
{
	level = adj_context_loglevel(level);
}
//
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
//
static void __show_stack(struct task_struct *task, unsigned long *sp)
{
	printk();
	...
	printk();
}

void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
{
	printk_emergency_enter(log_level);
	__show_stack(task, sp);
	printk_emergency_exit();
}
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //

show_stack() never schedules, disabling preemption around it should
not change anything. Should it be interrupted, we will handle it via
preempt count.

printk_emergency_enter(log_level) handles every printk() that
__show_stack() and friends do. Not worse than printk("%s Stack", lvl);
all over the place.

> What I'm going to do - is to fix all build and reported issues, I'll
> send v2 this week and feel free to NAK it, I will forget about those
> patches and won't be offended.

Lovely.
And - no, I'm not going to NAK platform specific changes. Just so you know.

*All* I'm talking about is an alternative, less "go and touch a ton of
platform code" approach. The argument "I patched so many files that I'm
not even going to discuss anything now" is not productive, to say the
least. Hope this clarifies.

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:17             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  2:17 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Petr Mladek, linux-pm, Heiko Carstens,
	linux-um, Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Len Brown, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
> I don't see how bits on task_struct or in per-cpu are easier than
> supplying a log level parameter down the stack.
> How would it work if sysrq_handle_crash() called by key-press?
> How would that interact with deferred printing?
> How would it make visible prints from current context, but not from
> something that preempted it?

[..]

per-context log_level works pretty much the same way as per-message
log_level.

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
static DEFINE_PER_CPU(int, cpu_loglevels[4]); // @INITME.. LOGLEVEL_DEBUG + 1?

static int __printing_context(void)
{
	unsigned int preempt = preempt_count();

	if (!(preempt & (NMI_MASK | HARDIRQ_MASK | SOFITRQ_OFFSET)))
		return 0;
	if (preempt & SOFITRQ_OFFSET)
		return 1;
	if (preempt & HARDIRQ_MASK)
		return 2;
	return 3;
}

static int adj_context_loglevel(int level)
{
	int ctx = __printing_context();
	int cpu_level = this_cpu_read(cpu_loglevels[ctx]);

	// this one is important
	if (level == LOGLEVEL_SCHED)
		return level;
	// we are not in emergency context
	if (cpu_level == LOGLEVEL_DEBUG + 1)
		return level;
	// we better not override these
	if (LOGLEVEL_EMERG <= level && level <= LOGLEVEL_ERR)
		return level;
	return cpu_level;
}

void printk_emergency_enter(int log_level)
{
	int ctx;

	preempt_disable();
	ctx = __printing_context();
	this_cpu_write(cpu_loglevels[ctx], log_level);
}

void printk_emergency_exit(void)
{
	int ctx = __printing_context();

	this_cpu_write(cpu_loglevels[ctx], LOGLEVEL_DEBUG + 1);
	preempt_enable();
}

void vprintk_emit(...)
{
	level = adj_context_loglevel(level);
}
//
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
//
static void __show_stack(struct task_struct *task, unsigned long *sp)
{
	printk();
	...
	printk();
}

void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
{
	printk_emergency_enter(log_level);
	__show_stack(task, sp);
	printk_emergency_exit();
}
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //

show_stack() never schedules, disabling preemption around it should
not change anything. Should it be interrupted, we will handle it via
preempt count.

printk_emergency_enter(log_level) handles every printk() that
__show_stack() and friends do. Not worse than printk("%s Stack", lvl);
all over the place.

> What I'm going to do - is to fix all build and reported issues, I'll
> send v2 this week and feel free to NAK it, I will forget about those
> patches and won't be offended.

Lovely.
And - no, I'm not going to NAK platform specific changes. Just so you know.

*All* I'm talking about is an alternative, less "go and touch a ton of
platform code" approach. The argument "I patched so many files that I'm
not even going to discuss anything now" is not productive, to say the
least. Hope this clarifies.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:17             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  2:17 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
> I don't see how bits on task_struct or in per-cpu are easier than
> supplying a log level parameter down the stack.
> How would it work if sysrq_handle_crash() called by key-press?
> How would that interact with deferred printing?
> How would it make visible prints from current context, but not from
> something that preempted it?

[..]

per-context log_level works pretty much the same way as per-message
log_level.

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
static DEFINE_PER_CPU(int, cpu_loglevels[4]); // @INITME.. LOGLEVEL_DEBUG + 1?

static int __printing_context(void)
{
	unsigned int preempt = preempt_count();

	if (!(preempt & (NMI_MASK | HARDIRQ_MASK | SOFITRQ_OFFSET)))
		return 0;
	if (preempt & SOFITRQ_OFFSET)
		return 1;
	if (preempt & HARDIRQ_MASK)
		return 2;
	return 3;
}

static int adj_context_loglevel(int level)
{
	int ctx = __printing_context();
	int cpu_level = this_cpu_read(cpu_loglevels[ctx]);

	// this one is important
	if (level == LOGLEVEL_SCHED)
		return level;
	// we are not in emergency context
	if (cpu_level == LOGLEVEL_DEBUG + 1)
		return level;
	// we better not override these
	if (LOGLEVEL_EMERG <= level && level <= LOGLEVEL_ERR)
		return level;
	return cpu_level;
}

void printk_emergency_enter(int log_level)
{
	int ctx;

	preempt_disable();
	ctx = __printing_context();
	this_cpu_write(cpu_loglevels[ctx], log_level);
}

void printk_emergency_exit(void)
{
	int ctx = __printing_context();

	this_cpu_write(cpu_loglevels[ctx], LOGLEVEL_DEBUG + 1);
	preempt_enable();
}

void vprintk_emit(...)
{
	level = adj_context_loglevel(level);
}
//
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
//
static void __show_stack(struct task_struct *task, unsigned long *sp)
{
	printk();
	...
	printk();
}

void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
{
	printk_emergency_enter(log_level);
	__show_stack(task, sp);
	printk_emergency_exit();
}
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //

show_stack() never schedules, disabling preemption around it should
not change anything. Should it be interrupted, we will handle it via
preempt count.

printk_emergency_enter(log_level) handles every printk() that
__show_stack() and friends do. Not worse than printk("%s Stack", lvl);
all over the place.

> What I'm going to do - is to fix all build and reported issues, I'll
> send v2 this week and feel free to NAK it, I will forget about those
> patches and won't be offended.

Lovely.
And - no, I'm not going to NAK platform specific changes. Just so you know.

*All* I'm talking about is an alternative, less "go and touch a ton of
platform code" approach. The argument "I patched so many files that I'm
not even going to discuss anything now" is not productive, to say the
least. Hope this clarifies.

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:17             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  2:17 UTC (permalink / raw)
  To: openrisc

On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
> I don't see how bits on task_struct or in per-cpu are easier than
> supplying a log level parameter down the stack.
> How would it work if sysrq_handle_crash() called by key-press?
> How would that interact with deferred printing?
> How would it make visible prints from current context, but not from
> something that preempted it?

[..]

per-context log_level works pretty much the same way as per-message
log_level.

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
static DEFINE_PER_CPU(int, cpu_loglevels[4]); // @INITME.. LOGLEVEL_DEBUG + 1?

static int __printing_context(void)
{
	unsigned int preempt = preempt_count();

	if (!(preempt & (NMI_MASK | HARDIRQ_MASK | SOFITRQ_OFFSET)))
		return 0;
	if (preempt & SOFITRQ_OFFSET)
		return 1;
	if (preempt & HARDIRQ_MASK)
		return 2;
	return 3;
}

static int adj_context_loglevel(int level)
{
	int ctx = __printing_context();
	int cpu_level = this_cpu_read(cpu_loglevels[ctx]);

	// this one is important
	if (level == LOGLEVEL_SCHED)
		return level;
	// we are not in emergency context
	if (cpu_level == LOGLEVEL_DEBUG + 1)
		return level;
	// we better not override these
	if (LOGLEVEL_EMERG <= level && level <= LOGLEVEL_ERR)
		return level;
	return cpu_level;
}

void printk_emergency_enter(int log_level)
{
	int ctx;

	preempt_disable();
	ctx = __printing_context();
	this_cpu_write(cpu_loglevels[ctx], log_level);
}

void printk_emergency_exit(void)
{
	int ctx = __printing_context();

	this_cpu_write(cpu_loglevels[ctx], LOGLEVEL_DEBUG + 1);
	preempt_enable();
}

void vprintk_emit(...)
{
	level = adj_context_loglevel(level);
}
//
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
//
static void __show_stack(struct task_struct *task, unsigned long *sp)
{
	printk();
	...
	printk();
}

void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
{
	printk_emergency_enter(log_level);
	__show_stack(task, sp);
	printk_emergency_exit();
}
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //

show_stack() never schedules, disabling preemption around it should
not change anything. Should it be interrupted, we will handle it via
preempt count.

printk_emergency_enter(log_level) handles every printk() that
__show_stack() and friends do. Not worse than printk("%s Stack", lvl);
all over the place.

> What I'm going to do - is to fix all build and reported issues, I'll
> send v2 this week and feel free to NAK it, I will forget about those
> patches and won't be offended.

Lovely.
And - no, I'm not going to NAK platform specific changes. Just so you know.

*All* I'm talking about is an alternative, less "go and touch a ton of
platform code" approach. The argument "I patched so many files that I'm
not even going to discuss anything now" is not productive, to say the
least. Hope this clarifies.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:17             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  2:17 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Sergey Senozhatsky, Petr Mladek, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
> I don't see how bits on task_struct or in per-cpu are easier than
> supplying a log level parameter down the stack.
> How would it work if sysrq_handle_crash() called by key-press?
> How would that interact with deferred printing?
> How would it make visible prints from current context, but not from
> something that preempted it?

[..]

per-context log_level works pretty much the same way as per-message
log_level.

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
static DEFINE_PER_CPU(int, cpu_loglevels[4]); // @INITME.. LOGLEVEL_DEBUG + 1?

static int __printing_context(void)
{
	unsigned int preempt = preempt_count();

	if (!(preempt & (NMI_MASK | HARDIRQ_MASK | SOFITRQ_OFFSET)))
		return 0;
	if (preempt & SOFITRQ_OFFSET)
		return 1;
	if (preempt & HARDIRQ_MASK)
		return 2;
	return 3;
}

static int adj_context_loglevel(int level)
{
	int ctx = __printing_context();
	int cpu_level = this_cpu_read(cpu_loglevels[ctx]);

	// this one is important
	if (level == LOGLEVEL_SCHED)
		return level;
	// we are not in emergency context
	if (cpu_level == LOGLEVEL_DEBUG + 1)
		return level;
	// we better not override these
	if (LOGLEVEL_EMERG <= level && level <= LOGLEVEL_ERR)
		return level;
	return cpu_level;
}

void printk_emergency_enter(int log_level)
{
	int ctx;

	preempt_disable();
	ctx = __printing_context();
	this_cpu_write(cpu_loglevels[ctx], log_level);
}

void printk_emergency_exit(void)
{
	int ctx = __printing_context();

	this_cpu_write(cpu_loglevels[ctx], LOGLEVEL_DEBUG + 1);
	preempt_enable();
}

void vprintk_emit(...)
{
	level = adj_context_loglevel(level);
}
//
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
//
static void __show_stack(struct task_struct *task, unsigned long *sp)
{
	printk();
	...
	printk();
}

void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
{
	printk_emergency_enter(log_level);
	__show_stack(task, sp);
	printk_emergency_exit();
}
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //

show_stack() never schedules, disabling preemption around it should
not change anything. Should it be interrupted, we will handle it via
preempt count.

printk_emergency_enter(log_level) handles every printk() that
__show_stack() and friends do. Not worse than printk("%s Stack", lvl);
all over the place.

> What I'm going to do - is to fix all build and reported issues, I'll
> send v2 this week and feel free to NAK it, I will forget about those
> patches and won't be offended.

Lovely.
And - no, I'm not going to NAK platform specific changes. Just so you know.

*All* I'm talking about is an alternative, less "go and touch a ton of
platform code" approach. The argument "I patched so many files that I'm
not even going to discuss anything now" is not productive, to say the
least. Hope this clarifies.

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:17             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  2:17 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki

On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
> I don't see how bits on task_struct or in per-cpu are easier than
> supplying a log level parameter down the stack.
> How would it work if sysrq_handle_crash() called by key-press?
> How would that interact with deferred printing?
> How would it make visible prints from current context, but not from
> something that preempted it?

[..]

per-context log_level works pretty much the same way as per-message
log_level.

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
static DEFINE_PER_CPU(int, cpu_loglevels[4]); // @INITME.. LOGLEVEL_DEBUG + 1?

static int __printing_context(void)
{
	unsigned int preempt = preempt_count();

	if (!(preempt & (NMI_MASK | HARDIRQ_MASK | SOFITRQ_OFFSET)))
		return 0;
	if (preempt & SOFITRQ_OFFSET)
		return 1;
	if (preempt & HARDIRQ_MASK)
		return 2;
	return 3;
}

static int adj_context_loglevel(int level)
{
	int ctx = __printing_context();
	int cpu_level = this_cpu_read(cpu_loglevels[ctx]);

	// this one is important
	if (level == LOGLEVEL_SCHED)
		return level;
	// we are not in emergency context
	if (cpu_level == LOGLEVEL_DEBUG + 1)
		return level;
	// we better not override these
	if (LOGLEVEL_EMERG <= level && level <= LOGLEVEL_ERR)
		return level;
	return cpu_level;
}

void printk_emergency_enter(int log_level)
{
	int ctx;

	preempt_disable();
	ctx = __printing_context();
	this_cpu_write(cpu_loglevels[ctx], log_level);
}

void printk_emergency_exit(void)
{
	int ctx = __printing_context();

	this_cpu_write(cpu_loglevels[ctx], LOGLEVEL_DEBUG + 1);
	preempt_enable();
}

void vprintk_emit(...)
{
	level = adj_context_loglevel(level);
}
//
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
//
static void __show_stack(struct task_struct *task, unsigned long *sp)
{
	printk();
	...
	printk();
}

void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
{
	printk_emergency_enter(log_level);
	__show_stack(task, sp);
	printk_emergency_exit();
}
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //

show_stack() never schedules, disabling preemption around it should
not change anything. Should it be interrupted, we will handle it via
preempt count.

printk_emergency_enter(log_level) handles every printk() that
__show_stack() and friends do. Not worse than printk("%s Stack", lvl);
all over the place.

> What I'm going to do - is to fix all build and reported issues, I'll
> send v2 this week and feel free to NAK it, I will forget about those
> patches and won't be offended.

Lovely.
And - no, I'm not going to NAK platform specific changes. Just so you know.

*All* I'm talking about is an alternative, less "go and touch a ton of
platform code" approach. The argument "I patched so many files that I'm
not even going to discuss anything now" is not productive, to say the
least. Hope this clarifies.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-12  2:17             ` Sergey Senozhatsky
                                 ` (3 preceding siblings ...)
  (?)
@ 2019-11-12  2:40               ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-12  2:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

Hi Sergey,

On 11/12/19 2:17 AM, Sergey Senozhatsky wrote:
> On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
>> What I'm going to do - is to fix all build and reported issues, I'll
>> send v2 this week and feel free to NAK it, I will forget about those
>> patches and won't be offended.
> 
> Lovely.
> And - no, I'm not going to NAK platform specific changes. Just so you know.
> 
> *All* I'm talking about is an alternative, less "go and touch a ton of
> platform code" approach. The argument "I patched so many files that I'm
> not even going to discuss anything now" is not productive, to say the
> least. Hope this clarifies.

It probably was a wrong impression from the both sides.
My impression was "You touch every architecture - we won't even consider
that". Sorry for the the wrong impression from my side - I'm open for
discussion.

In my point of view the cost of one-time [mostly build] testing every
architecture is cheaper than introducing some new smart code that will
live forever. Though, again you and Petr understand more than me in
printk() code, so I'm not any insisting.

I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Thanks,
          Dmitry

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:40               ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-12  2:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

Hi Sergey,

On 11/12/19 2:17 AM, Sergey Senozhatsky wrote:
> On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
>> What I'm going to do - is to fix all build and reported issues, I'll
>> send v2 this week and feel free to NAK it, I will forget about those
>> patches and won't be offended.
> 
> Lovely.
> And - no, I'm not going to NAK platform specific changes. Just so you know.
> 
> *All* I'm talking about is an alternative, less "go and touch a ton of
> platform code" approach. The argument "I patched so many files that I'm
> not even going to discuss anything now" is not productive, to say the
> least. Hope this clarifies.

It probably was a wrong impression from the both sides.
My impression was "You touch every architecture - we won't even consider
that". Sorry for the the wrong impression from my side - I'm open for
discussion.

In my point of view the cost of one-time [mostly build] testing every
architecture is cheaper than introducing some new smart code that will
live forever. Though, again you and Petr understand more than me in
printk() code, so I'm not any insisting.

I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:40               ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-12  2:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

Hi Sergey,

On 11/12/19 2:17 AM, Sergey Senozhatsky wrote:
> On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
>> What I'm going to do - is to fix all build and reported issues, I'll
>> send v2 this week and feel free to NAK it, I will forget about those
>> patches and won't be offended.
> 
> Lovely.
> And - no, I'm not going to NAK platform specific changes. Just so you know.
> 
> *All* I'm talking about is an alternative, less "go and touch a ton of
> platform code" approach. The argument "I patched so many files that I'm
> not even going to discuss anything now" is not productive, to say the
> least. Hope this clarifies.

It probably was a wrong impression from the both sides.
My impression was "You touch every architecture - we won't even consider
that". Sorry for the the wrong impression from my side - I'm open for
discussion.

In my point of view the cost of one-time [mostly build] testing every
architecture is cheaper than introducing some new smart code that will
live forever. Though, again you and Petr understand more than me in
printk() code, so I'm not any insisting.

I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Thanks,
          Dmitry

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:40               ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-12  2:40 UTC (permalink / raw)
  To: openrisc

Hi Sergey,

On 11/12/19 2:17 AM, Sergey Senozhatsky wrote:
> On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
>> What I'm going to do - is to fix all build and reported issues, I'll
>> send v2 this week and feel free to NAK it, I will forget about those
>> patches and won't be offended.
> 
> Lovely.
> And - no, I'm not going to NAK platform specific changes. Just so you know.
> 
> *All* I'm talking about is an alternative, less "go and touch a ton of
> platform code" approach. The argument "I patched so many files that I'm
> not even going to discuss anything now" is not productive, to say the
> least. Hope this clarifies.

It probably was a wrong impression from the both sides.
My impression was "You touch every architecture - we won't even consider
that". Sorry for the the wrong impression from my side - I'm open for
discussion.

In my point of view the cost of one-time [mostly build] testing every
architecture is cheaper than introducing some new smart code that will
live forever. Though, again you and Petr understand more than me in
printk() code, so I'm not any insisting.

I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:40               ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-12  2:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Petr Mladek, linux-kernel, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J. Bottomley, linux-parisc,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev, Christian Borntraeger, Heiko Carstens,
	Vasily Gorbik, linux-s390, Rich Felker, linux-sh,
	David S. Miller, sparclinux, Anton Ivanov, Jeff Dike,
	Richard Weinberger, linux-um, Guan Xuetao, Borislav Petkov,
	H. Peter Anvin, x86, Chris Zankel, Max Filippov, linux-xtensa,
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

Hi Sergey,

On 11/12/19 2:17 AM, Sergey Senozhatsky wrote:
> On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
>> What I'm going to do - is to fix all build and reported issues, I'll
>> send v2 this week and feel free to NAK it, I will forget about those
>> patches and won't be offended.
> 
> Lovely.
> And - no, I'm not going to NAK platform specific changes. Just so you know.
> 
> *All* I'm talking about is an alternative, less "go and touch a ton of
> platform code" approach. The argument "I patched so many files that I'm
> not even going to discuss anything now" is not productive, to say the
> least. Hope this clarifies.

It probably was a wrong impression from the both sides.
My impression was "You touch every architecture - we won't even consider
that". Sorry for the the wrong impression from my side - I'm open for
discussion.

In my point of view the cost of one-time [mostly build] testing every
architecture is cheaper than introducing some new smart code that will
live forever. Though, again you and Petr understand more than me in
printk() code, so I'm not any insisting.

I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Thanks,
          Dmitry


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  2:40               ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-12  2:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

Hi Sergey,

On 11/12/19 2:17 AM, Sergey Senozhatsky wrote:
> On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
>> What I'm going to do - is to fix all build and reported issues, I'll
>> send v2 this week and feel free to NAK it, I will forget about those
>> patches and won't be offended.
> 
> Lovely.
> And - no, I'm not going to NAK platform specific changes. Just so you know.
> 
> *All* I'm talking about is an alternative, less "go and touch a ton of
> platform code" approach. The argument "I patched so many files that I'm
> not even going to discuss anything now" is not productive, to say the
> least. Hope this clarifies.

It probably was a wrong impression from the both sides.
My impression was "You touch every architecture - we won't even consider
that". Sorry for the the wrong impression from my side - I'm open for
discussion.

In my point of view the cost of one-time [mostly build] testing every
architecture is cheaper than introducing some new smart code that will
live forever. Though, again you and Petr understand more than me in
printk() code, so I'm not any insisting.

I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-12  2:40               ` Dmitry Safonov
                                   ` (3 preceding siblings ...)
  (?)
@ 2019-11-12  4:25                 ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:25 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/12 02:40), Dmitry Safonov wrote:
[..]
> In my point of view the cost of one-time [mostly build] testing every
> architecture is cheaper than introducing some new smart code that will
> live forever.

Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
on that arch invokes bar(), which invokes foo() and now foo() does printk(),
but we don't see it". The context which decided to backtaraces decided
to do so for a reason, probably, so I guess we can look at it as "a special
error reporting code block".

The proposed patch set passes loglevel via slightly unusual channel -
via sprintf(). We probably can do it, but I would prefer to minimize
the number of such printk-s in the kernel. The code snippet which I
posted also does pretty unusual thing w.r.t loglevel. Both approaches
are "non-standard" from that POV.

> I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Sure.

To anyone who will comment on that code snippet - this is not a
"look, here is what you need to do" type of proposal. Just an
alternative approach with its pros and cons.

We had several requests over the years to have something like "forcibly
allow all underlying printk-s from here to here" or "forcibly suppress
or postpone underlying printk-s from here to here", etc.

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:25                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:25 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Petr Mladek, linux-pm, Heiko Carstens,
	linux-um, Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Len Brown, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/12 02:40), Dmitry Safonov wrote:
[..]
> In my point of view the cost of one-time [mostly build] testing every
> architecture is cheaper than introducing some new smart code that will
> live forever.

Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
on that arch invokes bar(), which invokes foo() and now foo() does printk(),
but we don't see it". The context which decided to backtaraces decided
to do so for a reason, probably, so I guess we can look at it as "a special
error reporting code block".

The proposed patch set passes loglevel via slightly unusual channel -
via sprintf(). We probably can do it, but I would prefer to minimize
the number of such printk-s in the kernel. The code snippet which I
posted also does pretty unusual thing w.r.t loglevel. Both approaches
are "non-standard" from that POV.

> I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Sure.

To anyone who will comment on that code snippet - this is not a
"look, here is what you need to do" type of proposal. Just an
alternative approach with its pros and cons.

We had several requests over the years to have something like "forcibly
allow all underlying printk-s from here to here" or "forcibly suppress
or postpone underlying printk-s from here to here", etc.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:25                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:25 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/12 02:40), Dmitry Safonov wrote:
[..]
> In my point of view the cost of one-time [mostly build] testing every
> architecture is cheaper than introducing some new smart code that will
> live forever.

Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
on that arch invokes bar(), which invokes foo() and now foo() does printk(),
but we don't see it". The context which decided to backtaraces decided
to do so for a reason, probably, so I guess we can look at it as "a special
error reporting code block".

The proposed patch set passes loglevel via slightly unusual channel -
via sprintf(). We probably can do it, but I would prefer to minimize
the number of such printk-s in the kernel. The code snippet which I
posted also does pretty unusual thing w.r.t loglevel. Both approaches
are "non-standard" from that POV.

> I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Sure.

To anyone who will comment on that code snippet - this is not a
"look, here is what you need to do" type of proposal. Just an
alternative approach with its pros and cons.

We had several requests over the years to have something like "forcibly
allow all underlying printk-s from here to here" or "forcibly suppress
or postpone underlying printk-s from here to here", etc.

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:25                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:25 UTC (permalink / raw)
  To: openrisc

On (19/11/12 02:40), Dmitry Safonov wrote:
[..]
> In my point of view the cost of one-time [mostly build] testing every
> architecture is cheaper than introducing some new smart code that will
> live forever.

Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
on that arch invokes bar(), which invokes foo() and now foo() does printk(),
but we don't see it". The context which decided to backtaraces decided
to do so for a reason, probably, so I guess we can look at it as "a special
error reporting code block".

The proposed patch set passes loglevel via slightly unusual channel -
via sprintf(). We probably can do it, but I would prefer to minimize
the number of such printk-s in the kernel. The code snippet which I
posted also does pretty unusual thing w.r.t loglevel. Both approaches
are "non-standard" from that POV.

> I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Sure.

To anyone who will comment on that code snippet - this is not a
"look, here is what you need to do" type of proposal. Just an
alternative approach with its pros and cons.

We had several requests over the years to have something like "forcibly
allow all underlying printk-s from here to here" or "forcibly suppress
or postpone underlying printk-s from here to here", etc.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:25                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:25 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Sergey Senozhatsky, Petr Mladek, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On (19/11/12 02:40), Dmitry Safonov wrote:
[..]
> In my point of view the cost of one-time [mostly build] testing every
> architecture is cheaper than introducing some new smart code that will
> live forever.

Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
on that arch invokes bar(), which invokes foo() and now foo() does printk(),
but we don't see it". The context which decided to backtaraces decided
to do so for a reason, probably, so I guess we can look at it as "a special
error reporting code block".

The proposed patch set passes loglevel via slightly unusual channel -
via sprintf(). We probably can do it, but I would prefer to minimize
the number of such printk-s in the kernel. The code snippet which I
posted also does pretty unusual thing w.r.t loglevel. Both approaches
are "non-standard" from that POV.

> I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Sure.

To anyone who will comment on that code snippet - this is not a
"look, here is what you need to do" type of proposal. Just an
alternative approach with its pros and cons.

We had several requests over the years to have something like "forcibly
allow all underlying printk-s from here to here" or "forcibly suppress
or postpone underlying printk-s from here to here", etc.

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:25                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:25 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki

On (19/11/12 02:40), Dmitry Safonov wrote:
[..]
> In my point of view the cost of one-time [mostly build] testing every
> architecture is cheaper than introducing some new smart code that will
> live forever.

Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
on that arch invokes bar(), which invokes foo() and now foo() does printk(),
but we don't see it". The context which decided to backtaraces decided
to do so for a reason, probably, so I guess we can look at it as "a special
error reporting code block".

The proposed patch set passes loglevel via slightly unusual channel -
via sprintf(). We probably can do it, but I would prefer to minimize
the number of such printk-s in the kernel. The code snippet which I
posted also does pretty unusual thing w.r.t loglevel. Both approaches
are "non-standard" from that POV.

> I'll reply to your suggestion tomorrow, it's a bit late in my tz.

Sure.

To anyone who will comment on that code snippet - this is not a
"look, here is what you need to do" type of proposal. Just an
alternative approach with its pros and cons.

We had several requests over the years to have something like "forcibly
allow all underlying printk-s from here to here" or "forcibly suppress
or postpone underlying printk-s from here to here", etc.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-11  9:12           ` Petr Mladek
                               ` (3 preceding siblings ...)
  (?)
@ 2019-11-12  4:44             ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:44 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/11 10:12), Petr Mladek wrote:
[..]
> > I do recall that we talked about per-CPU printk state bit which would
> > start/end "just print it" section. We probably can extend it to "just
> > log_store" type of functionality. Doesn't look like a very bad idea.
> 
> The problem with per-CPU printk is that we would need to disable
> interrupts.

Or disable preemption and have loglevel per-CPU and per-context.
preempt_count can navigate us to the right context loglevel on
particular CPU. I'm talking here only about backtrace (error)
reporting contexts. Those can be atomic perfectly fine.

I posted a silly code snippet.

[..]
> But yes, this per-code-section loglevel is problematic. The feedback
> against the patchset shows that people want it also the other way.
> I mean to keep pr_debug() as pr_debug().

Hmm. Right.

> A solution might be to use the per-code-section loglevel only instead
> of some special loglevel.

So maybe we can "overwrite" only KERN_DEFAULT loglevels?
We certainly should not mess with SCHED or with anything in between
EMERG and ERR.

> The explicitly passed loglevel makes me feel more confident that
> all needed printk() calls were updated. But it might be a false
> feeling. I do not really have any strong preference.

I'm not like really objecting, just trying to explore some other
options.

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:44             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:44 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Dmitry Safonov, Will Deacon, Daniel Thompson,
	Brian Cain, Christian Borntraeger, kgdb-bugreport,
	linux-snps-arc, Fenghua Yu, Borislav Petkov, Jeff Dike,
	Steven Rostedt, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/11 10:12), Petr Mladek wrote:
[..]
> > I do recall that we talked about per-CPU printk state bit which would
> > start/end "just print it" section. We probably can extend it to "just
> > log_store" type of functionality. Doesn't look like a very bad idea.
> 
> The problem with per-CPU printk is that we would need to disable
> interrupts.

Or disable preemption and have loglevel per-CPU and per-context.
preempt_count can navigate us to the right context loglevel on
particular CPU. I'm talking here only about backtrace (error)
reporting contexts. Those can be atomic perfectly fine.

I posted a silly code snippet.

[..]
> But yes, this per-code-section loglevel is problematic. The feedback
> against the patchset shows that people want it also the other way.
> I mean to keep pr_debug() as pr_debug().

Hmm. Right.

> A solution might be to use the per-code-section loglevel only instead
> of some special loglevel.

So maybe we can "overwrite" only KERN_DEFAULT loglevels?
We certainly should not mess with SCHED or with anything in between
EMERG and ERR.

> The explicitly passed loglevel makes me feel more confident that
> all needed printk() calls were updated. But it might be a false
> feeling. I do not really have any strong preference.

I'm not like really objecting, just trying to explore some other
options.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:44             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:44 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/11 10:12), Petr Mladek wrote:
[..]
> > I do recall that we talked about per-CPU printk state bit which would
> > start/end "just print it" section. We probably can extend it to "just
> > log_store" type of functionality. Doesn't look like a very bad idea.
> 
> The problem with per-CPU printk is that we would need to disable
> interrupts.

Or disable preemption and have loglevel per-CPU and per-context.
preempt_count can navigate us to the right context loglevel on
particular CPU. I'm talking here only about backtrace (error)
reporting contexts. Those can be atomic perfectly fine.

I posted a silly code snippet.

[..]
> But yes, this per-code-section loglevel is problematic. The feedback
> against the patchset shows that people want it also the other way.
> I mean to keep pr_debug() as pr_debug().

Hmm. Right.

> A solution might be to use the per-code-section loglevel only instead
> of some special loglevel.

So maybe we can "overwrite" only KERN_DEFAULT loglevels?
We certainly should not mess with SCHED or with anything in between
EMERG and ERR.

> The explicitly passed loglevel makes me feel more confident that
> all needed printk() calls were updated. But it might be a false
> feeling. I do not really have any strong preference.

I'm not like really objecting, just trying to explore some other
options.

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:44             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:44 UTC (permalink / raw)
  To: openrisc

On (19/11/11 10:12), Petr Mladek wrote:
[..]
> > I do recall that we talked about per-CPU printk state bit which would
> > start/end "just print it" section. We probably can extend it to "just
> > log_store" type of functionality. Doesn't look like a very bad idea.
> 
> The problem with per-CPU printk is that we would need to disable
> interrupts.

Or disable preemption and have loglevel per-CPU and per-context.
preempt_count can navigate us to the right context loglevel on
particular CPU. I'm talking here only about backtrace (error)
reporting contexts. Those can be atomic perfectly fine.

I posted a silly code snippet.

[..]
> But yes, this per-code-section loglevel is problematic. The feedback
> against the patchset shows that people want it also the other way.
> I mean to keep pr_debug() as pr_debug().

Hmm. Right.

> A solution might be to use the per-code-section loglevel only instead
> of some special loglevel.

So maybe we can "overwrite" only KERN_DEFAULT loglevels?
We certainly should not mess with SCHED or with anything in between
EMERG and ERR.

> The explicitly passed loglevel makes me feel more confident that
> all needed printk() calls were updated. But it might be a false
> feeling. I do not really have any strong preference.

I'm not like really objecting, just trying to explore some other
options.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:44             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:44 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sergey Senozhatsky, Dmitry Safonov, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On (19/11/11 10:12), Petr Mladek wrote:
[..]
> > I do recall that we talked about per-CPU printk state bit which would
> > start/end "just print it" section. We probably can extend it to "just
> > log_store" type of functionality. Doesn't look like a very bad idea.
> 
> The problem with per-CPU printk is that we would need to disable
> interrupts.

Or disable preemption and have loglevel per-CPU and per-context.
preempt_count can navigate us to the right context loglevel on
particular CPU. I'm talking here only about backtrace (error)
reporting contexts. Those can be atomic perfectly fine.

I posted a silly code snippet.

[..]
> But yes, this per-code-section loglevel is problematic. The feedback
> against the patchset shows that people want it also the other way.
> I mean to keep pr_debug() as pr_debug().

Hmm. Right.

> A solution might be to use the per-code-section loglevel only instead
> of some special loglevel.

So maybe we can "overwrite" only KERN_DEFAULT loglevels?
We certainly should not mess with SCHED or with anything in between
EMERG and ERR.

> The explicitly passed loglevel makes me feel more confident that
> all needed printk() calls were updated. But it might be a false
> feeling. I do not really have any strong preference.

I'm not like really objecting, just trying to explore some other
options.

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:44             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:44 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman

On (19/11/11 10:12), Petr Mladek wrote:
[..]
> > I do recall that we talked about per-CPU printk state bit which would
> > start/end "just print it" section. We probably can extend it to "just
> > log_store" type of functionality. Doesn't look like a very bad idea.
> 
> The problem with per-CPU printk is that we would need to disable
> interrupts.

Or disable preemption and have loglevel per-CPU and per-context.
preempt_count can navigate us to the right context loglevel on
particular CPU. I'm talking here only about backtrace (error)
reporting contexts. Those can be atomic perfectly fine.

I posted a silly code snippet.

[..]
> But yes, this per-code-section loglevel is problematic. The feedback
> against the patchset shows that people want it also the other way.
> I mean to keep pr_debug() as pr_debug().

Hmm. Right.

> A solution might be to use the per-code-section loglevel only instead
> of some special loglevel.

So maybe we can "overwrite" only KERN_DEFAULT loglevels?
We certainly should not mess with SCHED or with anything in between
EMERG and ERR.

> The explicitly passed loglevel makes me feel more confident that
> all needed printk() calls were updated. But it might be a false
> feeling. I do not really have any strong preference.

I'm not like really objecting, just trying to explore some other
options.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-12  4:44             ` Sergey Senozhatsky
                                 ` (3 preceding siblings ...)
  (?)
@ 2019-11-12  4:57               ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:57 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/12 13:44), Sergey Senozhatsky wrote:
[..]
> > But yes, this per-code-section loglevel is problematic. The feedback
> > against the patchset shows that people want it also the other way.
> > I mean to keep pr_debug() as pr_debug().
> 
> Hmm. Right.
> 
> > A solution might be to use the per-code-section loglevel only instead
> > of some special loglevel.
> 
> So maybe we can "overwrite" only KERN_DEFAULT loglevels?

LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?

So we can downgrade some messages (log_store() only) or promote
some messages.

DEBUG perhaps should stay debug.

> We certainly should not mess with SCHED or with anything in between
> EMERG and ERR.

  [EMERG, WARN]

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:57               ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:57 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Dmitry Safonov, Will Deacon, Daniel Thompson,
	Brian Cain, Christian Borntraeger, kgdb-bugreport,
	linux-snps-arc, Fenghua Yu, Borislav Petkov, Jeff Dike,
	Steven Rostedt, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/12 13:44), Sergey Senozhatsky wrote:
[..]
> > But yes, this per-code-section loglevel is problematic. The feedback
> > against the patchset shows that people want it also the other way.
> > I mean to keep pr_debug() as pr_debug().
> 
> Hmm. Right.
> 
> > A solution might be to use the per-code-section loglevel only instead
> > of some special loglevel.
> 
> So maybe we can "overwrite" only KERN_DEFAULT loglevels?

LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?

So we can downgrade some messages (log_store() only) or promote
some messages.

DEBUG perhaps should stay debug.

> We certainly should not mess with SCHED or with anything in between
> EMERG and ERR.

  [EMERG, WARN]

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:57               ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:57 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/12 13:44), Sergey Senozhatsky wrote:
[..]
> > But yes, this per-code-section loglevel is problematic. The feedback
> > against the patchset shows that people want it also the other way.
> > I mean to keep pr_debug() as pr_debug().
> 
> Hmm. Right.
> 
> > A solution might be to use the per-code-section loglevel only instead
> > of some special loglevel.
> 
> So maybe we can "overwrite" only KERN_DEFAULT loglevels?

LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?

So we can downgrade some messages (log_store() only) or promote
some messages.

DEBUG perhaps should stay debug.

> We certainly should not mess with SCHED or with anything in between
> EMERG and ERR.

  [EMERG, WARN]

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:57               ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:57 UTC (permalink / raw)
  To: openrisc

On (19/11/12 13:44), Sergey Senozhatsky wrote:
[..]
> > But yes, this per-code-section loglevel is problematic. The feedback
> > against the patchset shows that people want it also the other way.
> > I mean to keep pr_debug() as pr_debug().
> 
> Hmm. Right.
> 
> > A solution might be to use the per-code-section loglevel only instead
> > of some special loglevel.
> 
> So maybe we can "overwrite" only KERN_DEFAULT loglevels?

LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?

So we can downgrade some messages (log_store() only) or promote
some messages.

DEBUG perhaps should stay debug.

> We certainly should not mess with SCHED or with anything in between
> EMERG and ERR.

  [EMERG, WARN]

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:57               ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:57 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Dmitry Safonov, linux-kernel, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J. Bottomley, linux-parisc,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev, Christian Borntraeger, Heiko Carstens,
	Vasily Gorbik, linux-s390, Rich Felker, linux-sh,
	David S. Miller, sparclinux, Anton Ivanov, Jeff Dike,
	Richard Weinberger, linux-um, Guan Xuetao, Borislav Petkov,
	H. Peter Anvin, x86, Chris Zankel, Max Filippov, linux-xtensa,
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport,
	Sergey Senozhatsky

On (19/11/12 13:44), Sergey Senozhatsky wrote:
[..]
> > But yes, this per-code-section loglevel is problematic. The feedback
> > against the patchset shows that people want it also the other way.
> > I mean to keep pr_debug() as pr_debug().
> 
> Hmm. Right.
> 
> > A solution might be to use the per-code-section loglevel only instead
> > of some special loglevel.
> 
> So maybe we can "overwrite" only KERN_DEFAULT loglevels?

LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?

So we can downgrade some messages (log_store() only) or promote
some messages.

DEBUG perhaps should stay debug.

> We certainly should not mess with SCHED or with anything in between
> EMERG and ERR.

  [EMERG, WARN]

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  4:57               ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12  4:57 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman

On (19/11/12 13:44), Sergey Senozhatsky wrote:
[..]
> > But yes, this per-code-section loglevel is problematic. The feedback
> > against the patchset shows that people want it also the other way.
> > I mean to keep pr_debug() as pr_debug().
> 
> Hmm. Right.
> 
> > A solution might be to use the per-code-section loglevel only instead
> > of some special loglevel.
> 
> So maybe we can "overwrite" only KERN_DEFAULT loglevels?

LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?

So we can downgrade some messages (log_store() only) or promote
some messages.

DEBUG perhaps should stay debug.

> We certainly should not mess with SCHED or with anything in between
> EMERG and ERR.

  [EMERG, WARN]

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-12  4:57               ` Sergey Senozhatsky
                                   ` (3 preceding siblings ...)
  (?)
@ 2019-11-12  8:35                 ` Petr Mladek
  -1 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-12  8:35 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Tue 2019-11-12 13:57:04, Sergey Senozhatsky wrote:
> On (19/11/12 13:44), Sergey Senozhatsky wrote:
> [..]
> > > But yes, this per-code-section loglevel is problematic. The feedback
> > > against the patchset shows that people want it also the other way.
> > > I mean to keep pr_debug() as pr_debug().
> > 
> > Hmm. Right.
> > 
> > > A solution might be to use the per-code-section loglevel only instead
> > > of some special loglevel.
> > 
> > So maybe we can "overwrite" only KERN_DEFAULT loglevels?
> 
> LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?
> 
> So we can downgrade some messages (log_store() only) or promote
> some messages.
> 
> DEBUG perhaps should stay debug.
> 
> > We certainly should not mess with SCHED or with anything in between
> > EMERG and ERR.
> 
>   [EMERG, WARN]

This is getting too complicated. It would introduce too many
hidden rules. While the explicitly passed loglevel parameter
is straightforward and clear.

I am getting more inclined to the solution introduced by this
patchset. It looks reasonable for the different use-cases.

Best Regards,
Petr

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  8:35                 ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-12  8:35 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Tue 2019-11-12 13:57:04, Sergey Senozhatsky wrote:
> On (19/11/12 13:44), Sergey Senozhatsky wrote:
> [..]
> > > But yes, this per-code-section loglevel is problematic. The feedback
> > > against the patchset shows that people want it also the other way.
> > > I mean to keep pr_debug() as pr_debug().
> > 
> > Hmm. Right.
> > 
> > > A solution might be to use the per-code-section loglevel only instead
> > > of some special loglevel.
> > 
> > So maybe we can "overwrite" only KERN_DEFAULT loglevels?
> 
> LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?
> 
> So we can downgrade some messages (log_store() only) or promote
> some messages.
> 
> DEBUG perhaps should stay debug.
> 
> > We certainly should not mess with SCHED or with anything in between
> > EMERG and ERR.
> 
>   [EMERG, WARN]

This is getting too complicated. It would introduce too many
hidden rules. While the explicitly passed loglevel parameter
is straightforward and clear.

I am getting more inclined to the solution introduced by this
patchset. It looks reasonable for the different use-cases.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  8:35                 ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-12  8:35 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Tue 2019-11-12 13:57:04, Sergey Senozhatsky wrote:
> On (19/11/12 13:44), Sergey Senozhatsky wrote:
> [..]
> > > But yes, this per-code-section loglevel is problematic. The feedback
> > > against the patchset shows that people want it also the other way.
> > > I mean to keep pr_debug() as pr_debug().
> > 
> > Hmm. Right.
> > 
> > > A solution might be to use the per-code-section loglevel only instead
> > > of some special loglevel.
> > 
> > So maybe we can "overwrite" only KERN_DEFAULT loglevels?
> 
> LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?
> 
> So we can downgrade some messages (log_store() only) or promote
> some messages.
> 
> DEBUG perhaps should stay debug.
> 
> > We certainly should not mess with SCHED or with anything in between
> > EMERG and ERR.
> 
>   [EMERG, WARN]

This is getting too complicated. It would introduce too many
hidden rules. While the explicitly passed loglevel parameter
is straightforward and clear.

I am getting more inclined to the solution introduced by this
patchset. It looks reasonable for the different use-cases.

Best Regards,
Petr

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  8:35                 ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-12  8:35 UTC (permalink / raw)
  To: openrisc

On Tue 2019-11-12 13:57:04, Sergey Senozhatsky wrote:
> On (19/11/12 13:44), Sergey Senozhatsky wrote:
> [..]
> > > But yes, this per-code-section loglevel is problematic. The feedback
> > > against the patchset shows that people want it also the other way.
> > > I mean to keep pr_debug() as pr_debug().
> > 
> > Hmm. Right.
> > 
> > > A solution might be to use the per-code-section loglevel only instead
> > > of some special loglevel.
> > 
> > So maybe we can "overwrite" only KERN_DEFAULT loglevels?
> 
> LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?
> 
> So we can downgrade some messages (log_store() only) or promote
> some messages.
> 
> DEBUG perhaps should stay debug.
> 
> > We certainly should not mess with SCHED or with anything in between
> > EMERG and ERR.
> 
>   [EMERG, WARN]

This is getting too complicated. It would introduce too many
hidden rules. While the explicitly passed loglevel parameter
is straightforward and clear.

I am getting more inclined to the solution introduced by this
patchset. It looks reasonable for the different use-cases.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  8:35                 ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-12  8:35 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Dmitry Safonov, linux-kernel, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J. Bottomley, linux-parisc,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev, Christian Borntraeger, Heiko Carstens,
	Vasily Gorbik, linux-s390, Rich Felker, linux-sh,
	David S. Miller, sparclinux, Anton Ivanov, Jeff Dike,
	Richard Weinberger, linux-um, Guan Xuetao, Borislav Petkov,
	H. Peter Anvin, x86, Chris Zankel, Max Filippov, linux-xtensa,
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

On Tue 2019-11-12 13:57:04, Sergey Senozhatsky wrote:
> On (19/11/12 13:44), Sergey Senozhatsky wrote:
> [..]
> > > But yes, this per-code-section loglevel is problematic. The feedback
> > > against the patchset shows that people want it also the other way.
> > > I mean to keep pr_debug() as pr_debug().
> > 
> > Hmm. Right.
> > 
> > > A solution might be to use the per-code-section loglevel only instead
> > > of some special loglevel.
> > 
> > So maybe we can "overwrite" only KERN_DEFAULT loglevels?
> 
> LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?
> 
> So we can downgrade some messages (log_store() only) or promote
> some messages.
> 
> DEBUG perhaps should stay debug.
> 
> > We certainly should not mess with SCHED or with anything in between
> > EMERG and ERR.
> 
>   [EMERG, WARN]

This is getting too complicated. It would introduce too many
hidden rules. While the explicitly passed loglevel parameter
is straightforward and clear.

I am getting more inclined to the solution introduced by this
patchset. It looks reasonable for the different use-cases.

Best Regards,
Petr


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12  8:35                 ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-12  8:35 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On Tue 2019-11-12 13:57:04, Sergey Senozhatsky wrote:
> On (19/11/12 13:44), Sergey Senozhatsky wrote:
> [..]
> > > But yes, this per-code-section loglevel is problematic. The feedback
> > > against the patchset shows that people want it also the other way.
> > > I mean to keep pr_debug() as pr_debug().
> > 
> > Hmm. Right.
> > 
> > > A solution might be to use the per-code-section loglevel only instead
> > > of some special loglevel.
> > 
> > So maybe we can "overwrite" only KERN_DEFAULT loglevels?
> 
> LOGLEVEL_DEFAULT, LOGLEVEL_NOTICE, LOGLEVEL_INFO?
> 
> So we can downgrade some messages (log_store() only) or promote
> some messages.
> 
> DEBUG perhaps should stay debug.
> 
> > We certainly should not mess with SCHED or with anything in between
> > EMERG and ERR.
> 
>   [EMERG, WARN]

This is getting too complicated. It would introduce too many
hidden rules. While the explicitly passed loglevel parameter
is straightforward and clear.

I am getting more inclined to the solution introduced by this
patchset. It looks reasonable for the different use-cases.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-12  8:35                 ` Petr Mladek
                                     ` (3 preceding siblings ...)
  (?)
@ 2019-11-12 10:12                   ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12 10:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/12 09:35), Petr Mladek wrote:
[..]
> This is getting too complicated. It would introduce too many
> hidden rules. While the explicitly passed loglevel parameter
> is straightforward and clear.

If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
(either downgrade or upgrade). That's one rule, basically. Not too
complicated, I guess.

> I am getting more inclined to the solution introduced by this
> patchset. It looks reasonable for the different use-cases.

No pressure from my side. Up to arch maintainers.

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12 10:12                   ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12 10:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Dmitry Safonov, Will Deacon, Daniel Thompson,
	Brian Cain, Christian Borntraeger, kgdb-bugreport,
	linux-snps-arc, Fenghua Yu, Borislav Petkov, Jeff Dike,
	Steven Rostedt, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/12 09:35), Petr Mladek wrote:
[..]
> This is getting too complicated. It would introduce too many
> hidden rules. While the explicitly passed loglevel parameter
> is straightforward and clear.

If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
(either downgrade or upgrade). That's one rule, basically. Not too
complicated, I guess.

> I am getting more inclined to the solution introduced by this
> patchset. It looks reasonable for the different use-cases.

No pressure from my side. Up to arch maintainers.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12 10:12                   ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12 10:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/12 09:35), Petr Mladek wrote:
[..]
> This is getting too complicated. It would introduce too many
> hidden rules. While the explicitly passed loglevel parameter
> is straightforward and clear.

If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
(either downgrade or upgrade). That's one rule, basically. Not too
complicated, I guess.

> I am getting more inclined to the solution introduced by this
> patchset. It looks reasonable for the different use-cases.

No pressure from my side. Up to arch maintainers.

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12 10:12                   ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12 10:12 UTC (permalink / raw)
  To: openrisc

On (19/11/12 09:35), Petr Mladek wrote:
[..]
> This is getting too complicated. It would introduce too many
> hidden rules. While the explicitly passed loglevel parameter
> is straightforward and clear.

If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
(either downgrade or upgrade). That's one rule, basically. Not too
complicated, I guess.

> I am getting more inclined to the solution introduced by this
> patchset. It looks reasonable for the different use-cases.

No pressure from my side. Up to arch maintainers.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12 10:12                   ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12 10:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sergey Senozhatsky, Dmitry Safonov, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On (19/11/12 09:35), Petr Mladek wrote:
[..]
> This is getting too complicated. It would introduce too many
> hidden rules. While the explicitly passed loglevel parameter
> is straightforward and clear.

If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
(either downgrade or upgrade). That's one rule, basically. Not too
complicated, I guess.

> I am getting more inclined to the solution introduced by this
> patchset. It looks reasonable for the different use-cases.

No pressure from my side. Up to arch maintainers.

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-12 10:12                   ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-12 10:12 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman

On (19/11/12 09:35), Petr Mladek wrote:
[..]
> This is getting too complicated. It would introduce too many
> hidden rules. While the explicitly passed loglevel parameter
> is straightforward and clear.

If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
(either downgrade or upgrade). That's one rule, basically. Not too
complicated, I guess.

> I am getting more inclined to the solution introduced by this
> patchset. It looks reasonable for the different use-cases.

No pressure from my side. Up to arch maintainers.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-12 10:12                   ` Sergey Senozhatsky
                                       ` (3 preceding siblings ...)
  (?)
@ 2019-11-13  1:23                     ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  1:23 UTC (permalink / raw)
  To: Petr Mladek, Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/12 19:12), Sergey Senozhatsky wrote:
> On (19/11/12 09:35), Petr Mladek wrote:
> [..]
> > This is getting too complicated. It would introduce too many
> > hidden rules. While the explicitly passed loglevel parameter
> > is straightforward and clear.
>
> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
> (either downgrade or upgrade). That's one rule, basically. Not too
> complicated, I guess.

Can be taken even a bit further than

	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
or
	show_stack(NULL, NULL, LOGLEVEL_ERR);

For instance,

	spin_lock_irqsave(&rq->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		show_stack(...);
		printk();
		printk();
		...
	spin_unlock_irqrestore(&rq->lock, flags);

or

	spin_lock_irqsave(&uart_port->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		printk();
		printk();
		...

and so on.

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  1:23                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  1:23 UTC (permalink / raw)
  To: Petr Mladek, Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/12 19:12), Sergey Senozhatsky wrote:
> On (19/11/12 09:35), Petr Mladek wrote:
> [..]
> > This is getting too complicated. It would introduce too many
> > hidden rules. While the explicitly passed loglevel parameter
> > is straightforward and clear.
>
> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
> (either downgrade or upgrade). That's one rule, basically. Not too
> complicated, I guess.

Can be taken even a bit further than

	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
or
	show_stack(NULL, NULL, LOGLEVEL_ERR);

For instance,

	spin_lock_irqsave(&rq->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		show_stack(...);
		printk();
		printk();
		...
	spin_unlock_irqrestore(&rq->lock, flags);

or

	spin_lock_irqsave(&uart_port->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		printk();
		printk();
		...

and so on.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  1:23                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  1:23 UTC (permalink / raw)
  To: Petr Mladek, Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/12 19:12), Sergey Senozhatsky wrote:
> On (19/11/12 09:35), Petr Mladek wrote:
> [..]
> > This is getting too complicated. It would introduce too many
> > hidden rules. While the explicitly passed loglevel parameter
> > is straightforward and clear.
>
> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
> (either downgrade or upgrade). That's one rule, basically. Not too
> complicated, I guess.

Can be taken even a bit further than

	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
or
	show_stack(NULL, NULL, LOGLEVEL_ERR);

For instance,

	spin_lock_irqsave(&rq->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		show_stack(...);
		printk();
		printk();
		...
	spin_unlock_irqrestore(&rq->lock, flags);

or

	spin_lock_irqsave(&uart_port->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		printk();
		printk();
		...

and so on.

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  1:23                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  1:23 UTC (permalink / raw)
  To: openrisc

On (19/11/12 19:12), Sergey Senozhatsky wrote:
> On (19/11/12 09:35), Petr Mladek wrote:
> [..]
> > This is getting too complicated. It would introduce too many
> > hidden rules. While the explicitly passed loglevel parameter
> > is straightforward and clear.
>
> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
> (either downgrade or upgrade). That's one rule, basically. Not too
> complicated, I guess.

Can be taken even a bit further than

	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
or
	show_stack(NULL, NULL, LOGLEVEL_ERR);

For instance,

	spin_lock_irqsave(&rq->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		show_stack(...);
		printk();
		printk();
		...
	spin_unlock_irqrestore(&rq->lock, flags);

or

	spin_lock_irqsave(&uart_port->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		printk();
		printk();
		...

and so on.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  1:23                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  1:23 UTC (permalink / raw)
  To: Petr Mladek, Dmitry Safonov
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Sergey Senozhatsky, Steven Rostedt,
	Tetsuo Handa, Albert Ou, Ben Segall, Dietmar Eggemann,
	Greentime Hu, Ingo Molnar, James Hogan, Juri Lelli, Mel Gorman,
	Michal Simek, Palmer Dabbelt, Paul Burton, Paul Walmsley,
	Peter Zijlstra, Ralf Baechle, Thomas Gleixner, Vincent Chen,
	Vincent Guittot, Will Deacon, linux-mips, linux-riscv,
	Ivan Kokshaysky, Matt Turner, Richard Henderson, linux-alpha,
	Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport, Sergey Senozhatsky

On (19/11/12 19:12), Sergey Senozhatsky wrote:
> On (19/11/12 09:35), Petr Mladek wrote:
> [..]
> > This is getting too complicated. It would introduce too many
> > hidden rules. While the explicitly passed loglevel parameter
> > is straightforward and clear.
>
> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
> (either downgrade or upgrade). That's one rule, basically. Not too
> complicated, I guess.

Can be taken even a bit further than

	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
or
	show_stack(NULL, NULL, LOGLEVEL_ERR);

For instance,

	spin_lock_irqsave(&rq->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		show_stack(...);
		printk();
		printk();
		...
	spin_unlock_irqrestore(&rq->lock, flags);

or

	spin_lock_irqsave(&uart_port->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		printk();
		printk();
		...

and so on.

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  1:23                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  1:23 UTC (permalink / raw)
  To: Petr Mladek, Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki

On (19/11/12 19:12), Sergey Senozhatsky wrote:
> On (19/11/12 09:35), Petr Mladek wrote:
> [..]
> > This is getting too complicated. It would introduce too many
> > hidden rules. While the explicitly passed loglevel parameter
> > is straightforward and clear.
>
> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
> (either downgrade or upgrade). That's one rule, basically. Not too
> complicated, I guess.

Can be taken even a bit further than

	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
or
	show_stack(NULL, NULL, LOGLEVEL_ERR);

For instance,

	spin_lock_irqsave(&rq->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		show_stack(...);
		printk();
		printk();
		...
	spin_unlock_irqrestore(&rq->lock, flags);

or

	spin_lock_irqsave(&uart_port->lock, flags);
	printk_emergency_enter(LOGLEVEL_SCHED);
		...
		printk();
		printk();
		...

and so on.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-13  1:23                     ` Sergey Senozhatsky
                                         ` (3 preceding siblings ...)
  (?)
@ 2019-11-13  2:25                       ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:25 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek, Steven Rostedt
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On 11/13/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/12 19:12), Sergey Senozhatsky wrote:
>> On (19/11/12 09:35), Petr Mladek wrote:
>> [..]
>>> This is getting too complicated. It would introduce too many
>>> hidden rules. While the explicitly passed loglevel parameter
>>> is straightforward and clear.
>>
>> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
>> (either downgrade or upgrade). That's one rule, basically. Not too
>> complicated, I guess.
> 
> Can be taken even a bit further than
> 
> 	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
> or
> 	show_stack(NULL, NULL, LOGLEVEL_ERR);
> 
> For instance,
> 
> 	spin_lock_irqsave(&rq->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		show_stack(...);
> 		printk();
> 		printk();
> 		...
> 	spin_unlock_irqrestore(&rq->lock, flags);
> 
> or
> 
> 	spin_lock_irqsave(&uart_port->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		printk();
> 		printk();
> 		...

Yeah, that makes sense.

I believe it's up to you, Petr and Steven to decide what's better for
printk(). I mean, after all you care for all this code.

I guess I've pointed that in my point of view price for one-time testing
code is cheaper than adding a new printk feature to swap log levels on
the fly. But again, it's just how I see it - if we fix those printing
problems, than in half year we will forget they ever existed, but in
your proposal, there will still be some clever printk code.

On the other side, also worth to note that current patches set fix
problems for kdb (and for my hung task printing patch), but it's
incomplete for sysrq driver. I've gone through functions used by sysrq
driver and the same changes introducing log level parameter would be
needed for: sched_show_task(), debug_show_all_locks(), show_regs(),
show_state(), show_mem(). Some of them don't need any platform changes,
but at least show_regs() needs.
So, you also need to have that in mind making the decision.

Thanks,
          Dmitry

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:25                       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:25 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek, Steven Rostedt
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On 11/13/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/12 19:12), Sergey Senozhatsky wrote:
>> On (19/11/12 09:35), Petr Mladek wrote:
>> [..]
>>> This is getting too complicated. It would introduce too many
>>> hidden rules. While the explicitly passed loglevel parameter
>>> is straightforward and clear.
>>
>> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
>> (either downgrade or upgrade). That's one rule, basically. Not too
>> complicated, I guess.
> 
> Can be taken even a bit further than
> 
> 	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
> or
> 	show_stack(NULL, NULL, LOGLEVEL_ERR);
> 
> For instance,
> 
> 	spin_lock_irqsave(&rq->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		show_stack(...);
> 		printk();
> 		printk();
> 		...
> 	spin_unlock_irqrestore(&rq->lock, flags);
> 
> or
> 
> 	spin_lock_irqsave(&uart_port->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		printk();
> 		printk();
> 		...

Yeah, that makes sense.

I believe it's up to you, Petr and Steven to decide what's better for
printk(). I mean, after all you care for all this code.

I guess I've pointed that in my point of view price for one-time testing
code is cheaper than adding a new printk feature to swap log levels on
the fly. But again, it's just how I see it - if we fix those printing
problems, than in half year we will forget they ever existed, but in
your proposal, there will still be some clever printk code.

On the other side, also worth to note that current patches set fix
problems for kdb (and for my hung task printing patch), but it's
incomplete for sysrq driver. I've gone through functions used by sysrq
driver and the same changes introducing log level parameter would be
needed for: sched_show_task(), debug_show_all_locks(), show_regs(),
show_state(), show_mem(). Some of them don't need any platform changes,
but at least show_regs() needs.
So, you also need to have that in mind making the decision.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:25                       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:25 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek, Steven Rostedt
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On 11/13/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/12 19:12), Sergey Senozhatsky wrote:
>> On (19/11/12 09:35), Petr Mladek wrote:
>> [..]
>>> This is getting too complicated. It would introduce too many
>>> hidden rules. While the explicitly passed loglevel parameter
>>> is straightforward and clear.
>>
>> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
>> (either downgrade or upgrade). That's one rule, basically. Not too
>> complicated, I guess.
> 
> Can be taken even a bit further than
> 
> 	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
> or
> 	show_stack(NULL, NULL, LOGLEVEL_ERR);
> 
> For instance,
> 
> 	spin_lock_irqsave(&rq->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		show_stack(...);
> 		printk();
> 		printk();
> 		...
> 	spin_unlock_irqrestore(&rq->lock, flags);
> 
> or
> 
> 	spin_lock_irqsave(&uart_port->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		printk();
> 		printk();
> 		...

Yeah, that makes sense.

I believe it's up to you, Petr and Steven to decide what's better for
printk(). I mean, after all you care for all this code.

I guess I've pointed that in my point of view price for one-time testing
code is cheaper than adding a new printk feature to swap log levels on
the fly. But again, it's just how I see it - if we fix those printing
problems, than in half year we will forget they ever existed, but in
your proposal, there will still be some clever printk code.

On the other side, also worth to note that current patches set fix
problems for kdb (and for my hung task printing patch), but it's
incomplete for sysrq driver. I've gone through functions used by sysrq
driver and the same changes introducing log level parameter would be
needed for: sched_show_task(), debug_show_all_locks(), show_regs(),
show_state(), show_mem(). Some of them don't need any platform changes,
but at least show_regs() needs.
So, you also need to have that in mind making the decision.

Thanks,
          Dmitry

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:25                       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:25 UTC (permalink / raw)
  To: openrisc

On 11/13/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/12 19:12), Sergey Senozhatsky wrote:
>> On (19/11/12 09:35), Petr Mladek wrote:
>> [..]
>>> This is getting too complicated. It would introduce too many
>>> hidden rules. While the explicitly passed loglevel parameter
>>> is straightforward and clear.
>>
>> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
>> (either downgrade or upgrade). That's one rule, basically. Not too
>> complicated, I guess.
> 
> Can be taken even a bit further than
> 
> 	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
> or
> 	show_stack(NULL, NULL, LOGLEVEL_ERR);
> 
> For instance,
> 
> 	spin_lock_irqsave(&rq->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		show_stack(...);
> 		printk();
> 		printk();
> 		...
> 	spin_unlock_irqrestore(&rq->lock, flags);
> 
> or
> 
> 	spin_lock_irqsave(&uart_port->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		printk();
> 		printk();
> 		...

Yeah, that makes sense.

I believe it's up to you, Petr and Steven to decide what's better for
printk(). I mean, after all you care for all this code.

I guess I've pointed that in my point of view price for one-time testing
code is cheaper than adding a new printk feature to swap log levels on
the fly. But again, it's just how I see it - if we fix those printing
problems, than in half year we will forget they ever existed, but in
your proposal, there will still be some clever printk code.

On the other side, also worth to note that current patches set fix
problems for kdb (and for my hung task printing patch), but it's
incomplete for sysrq driver. I've gone through functions used by sysrq
driver and the same changes introducing log level parameter would be
needed for: sched_show_task(), debug_show_all_locks(), show_regs(),
show_state(), show_mem(). Some of them don't need any platform changes,
but at least show_regs() needs.
So, you also need to have that in mind making the decision.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:25                       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:25 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek, Steven Rostedt
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Sergey Senozhatsky, Tetsuo Handa,
	Albert Ou, Ben Segall, Dietmar Eggemann, Greentime Hu,
	Ingo Molnar, James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On 11/13/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/12 19:12), Sergey Senozhatsky wrote:
>> On (19/11/12 09:35), Petr Mladek wrote:
>> [..]
>>> This is getting too complicated. It would introduce too many
>>> hidden rules. While the explicitly passed loglevel parameter
>>> is straightforward and clear.
>>
>> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
>> (either downgrade or upgrade). That's one rule, basically. Not too
>> complicated, I guess.
> 
> Can be taken even a bit further than
> 
> 	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
> or
> 	show_stack(NULL, NULL, LOGLEVEL_ERR);
> 
> For instance,
> 
> 	spin_lock_irqsave(&rq->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		show_stack(...);
> 		printk();
> 		printk();
> 		...
> 	spin_unlock_irqrestore(&rq->lock, flags);
> 
> or
> 
> 	spin_lock_irqsave(&uart_port->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		printk();
> 		printk();
> 		...

Yeah, that makes sense.

I believe it's up to you, Petr and Steven to decide what's better for
printk(). I mean, after all you care for all this code.

I guess I've pointed that in my point of view price for one-time testing
code is cheaper than adding a new printk feature to swap log levels on
the fly. But again, it's just how I see it - if we fix those printing
problems, than in half year we will forget they ever existed, but in
your proposal, there will still be some clever printk code.

On the other side, also worth to note that current patches set fix
problems for kdb (and for my hung task printing patch), but it's
incomplete for sysrq driver. I've gone through functions used by sysrq
driver and the same changes introducing log level parameter would be
needed for: sched_show_task(), debug_show_all_locks(), show_regs(),
show_state(), show_mem(). Some of them don't need any platform changes,
but at least show_regs() needs.
So, you also need to have that in mind making the decision.

Thanks,
          Dmitry


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:25                       ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:25 UTC (permalink / raw)
  To: Sergey Senozhatsky, Petr Mladek, Steven Rostedt
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

On 11/13/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/12 19:12), Sergey Senozhatsky wrote:
>> On (19/11/12 09:35), Petr Mladek wrote:
>> [..]
>>> This is getting too complicated. It would introduce too many
>>> hidden rules. While the explicitly passed loglevel parameter
>>> is straightforward and clear.
>>
>> If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
>> (either downgrade or upgrade). That's one rule, basically. Not too
>> complicated, I guess.
> 
> Can be taken even a bit further than
> 
> 	show_stack(NULL, NULL, LOGLEVEL_DEBUG);
> or
> 	show_stack(NULL, NULL, LOGLEVEL_ERR);
> 
> For instance,
> 
> 	spin_lock_irqsave(&rq->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		show_stack(...);
> 		printk();
> 		printk();
> 		...
> 	spin_unlock_irqrestore(&rq->lock, flags);
> 
> or
> 
> 	spin_lock_irqsave(&uart_port->lock, flags);
> 	printk_emergency_enter(LOGLEVEL_SCHED);
> 		...
> 		printk();
> 		printk();
> 		...

Yeah, that makes sense.

I believe it's up to you, Petr and Steven to decide what's better for
printk(). I mean, after all you care for all this code.

I guess I've pointed that in my point of view price for one-time testing
code is cheaper than adding a new printk feature to swap log levels on
the fly. But again, it's just how I see it - if we fix those printing
problems, than in half year we will forget they ever existed, but in
your proposal, there will still be some clever printk code.

On the other side, also worth to note that current patches set fix
problems for kdb (and for my hung task printing patch), but it's
incomplete for sysrq driver. I've gone through functions used by sysrq
driver and the same changes introducing log level parameter would be
needed for: sched_show_task(), debug_show_all_locks(), show_regs(),
show_state(), show_mem(). Some of them don't need any platform changes,
but at least show_regs() needs.
So, you also need to have that in mind making the decision.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-12  4:25                 ` Sergey Senozhatsky
                                     ` (3 preceding siblings ...)
  (?)
@ 2019-11-13  2:41                   ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:41 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On 11/12/19 4:25 AM, Sergey Senozhatsky wrote:
> On (19/11/12 02:40), Dmitry Safonov wrote:
> [..]
>> In my point of view the cost of one-time [mostly build] testing every
>> architecture is cheaper than introducing some new smart code that will
>> live forever.
> 
> Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
> on that arch invokes bar(), which invokes foo() and now foo() does printk(),
> but we don't see it". The context which decided to backtaraces decided
> to do so for a reason, probably, so I guess we can look at it as "a special
> error reporting code block".
> 
> The proposed patch set passes loglevel via slightly unusual channel -
> via sprintf(). We probably can do it, but I would prefer to minimize
> the number of such printk-s in the kernel. The code snippet which I
> posted also does pretty unusual thing w.r.t loglevel. Both approaches
> are "non-standard" from that POV.

I don't strongly disagree, but if you look at those results:
git grep 'printk("%s.*", \(lvl\|level\)'

it seems to be used in quite a few places.

Thanks,
          Dmitry

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:41                   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:41 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On 11/12/19 4:25 AM, Sergey Senozhatsky wrote:
> On (19/11/12 02:40), Dmitry Safonov wrote:
> [..]
>> In my point of view the cost of one-time [mostly build] testing every
>> architecture is cheaper than introducing some new smart code that will
>> live forever.
> 
> Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
> on that arch invokes bar(), which invokes foo() and now foo() does printk(),
> but we don't see it". The context which decided to backtaraces decided
> to do so for a reason, probably, so I guess we can look at it as "a special
> error reporting code block".
> 
> The proposed patch set passes loglevel via slightly unusual channel -
> via sprintf(). We probably can do it, but I would prefer to minimize
> the number of such printk-s in the kernel. The code snippet which I
> posted also does pretty unusual thing w.r.t loglevel. Both approaches
> are "non-standard" from that POV.

I don't strongly disagree, but if you look at those results:
git grep 'printk("%s.*", \(lvl\|level\)'

it seems to be used in quite a few places.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:41                   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:41 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On 11/12/19 4:25 AM, Sergey Senozhatsky wrote:
> On (19/11/12 02:40), Dmitry Safonov wrote:
> [..]
>> In my point of view the cost of one-time [mostly build] testing every
>> architecture is cheaper than introducing some new smart code that will
>> live forever.
> 
> Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
> on that arch invokes bar(), which invokes foo() and now foo() does printk(),
> but we don't see it". The context which decided to backtaraces decided
> to do so for a reason, probably, so I guess we can look at it as "a special
> error reporting code block".
> 
> The proposed patch set passes loglevel via slightly unusual channel -
> via sprintf(). We probably can do it, but I would prefer to minimize
> the number of such printk-s in the kernel. The code snippet which I
> posted also does pretty unusual thing w.r.t loglevel. Both approaches
> are "non-standard" from that POV.

I don't strongly disagree, but if you look at those results:
git grep 'printk("%s.*", \(lvl\|level\)'

it seems to be used in quite a few places.

Thanks,
          Dmitry

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:41                   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:41 UTC (permalink / raw)
  To: openrisc

On 11/12/19 4:25 AM, Sergey Senozhatsky wrote:
> On (19/11/12 02:40), Dmitry Safonov wrote:
> [..]
>> In my point of view the cost of one-time [mostly build] testing every
>> architecture is cheaper than introducing some new smart code that will
>> live forever.
> 
> Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
> on that arch invokes bar(), which invokes foo() and now foo() does printk(),
> but we don't see it". The context which decided to backtaraces decided
> to do so for a reason, probably, so I guess we can look at it as "a special
> error reporting code block".
> 
> The proposed patch set passes loglevel via slightly unusual channel -
> via sprintf(). We probably can do it, but I would prefer to minimize
> the number of such printk-s in the kernel. The code snippet which I
> posted also does pretty unusual thing w.r.t loglevel. Both approaches
> are "non-standard" from that POV.

I don't strongly disagree, but if you look at those results:
git grep 'printk("%s.*", \(lvl\|level\)'

it seems to be used in quite a few places.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:41                   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:41 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Petr Mladek, linux-kernel, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Sergey Senozhatsky,
	Steven Rostedt, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J. Bottomley, linux-parisc,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev, Christian Borntraeger, Heiko Carstens,
	Vasily Gorbik, linux-s390, Rich Felker, linux-sh,
	David S. Miller, sparclinux, Anton Ivanov, Jeff Dike,
	Richard Weinberger, linux-um, Guan Xuetao, Borislav Petkov,
	H. Peter Anvin, x86, Chris Zankel, Max Filippov, linux-xtensa,
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

On 11/12/19 4:25 AM, Sergey Senozhatsky wrote:
> On (19/11/12 02:40), Dmitry Safonov wrote:
> [..]
>> In my point of view the cost of one-time [mostly build] testing every
>> architecture is cheaper than introducing some new smart code that will
>> live forever.
> 
> Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
> on that arch invokes bar(), which invokes foo() and now foo() does printk(),
> but we don't see it". The context which decided to backtaraces decided
> to do so for a reason, probably, so I guess we can look at it as "a special
> error reporting code block".
> 
> The proposed patch set passes loglevel via slightly unusual channel -
> via sprintf(). We probably can do it, but I would prefer to minimize
> the number of such printk-s in the kernel. The code snippet which I
> posted also does pretty unusual thing w.r.t loglevel. Both approaches
> are "non-standard" from that POV.

I don't strongly disagree, but if you look at those results:
git grep 'printk("%s.*", \(lvl\|level\)'

it seems to be used in quite a few places.

Thanks,
          Dmitry


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:41                   ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13  2:41 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

On 11/12/19 4:25 AM, Sergey Senozhatsky wrote:
> On (19/11/12 02:40), Dmitry Safonov wrote:
> [..]
>> In my point of view the cost of one-time [mostly build] testing every
>> architecture is cheaper than introducing some new smart code that will
>> live forever.
> 
> Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
> on that arch invokes bar(), which invokes foo() and now foo() does printk(),
> but we don't see it". The context which decided to backtaraces decided
> to do so for a reason, probably, so I guess we can look at it as "a special
> error reporting code block".
> 
> The proposed patch set passes loglevel via slightly unusual channel -
> via sprintf(). We probably can do it, but I would prefer to minimize
> the number of such printk-s in the kernel. The code snippet which I
> posted also does pretty unusual thing w.r.t loglevel. Both approaches
> are "non-standard" from that POV.

I don't strongly disagree, but if you look at those results:
git grep 'printk("%s.*", \(lvl\|level\)'

it seems to be used in quite a few places.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-13  2:41                   ` Dmitry Safonov
                                       ` (3 preceding siblings ...)
  (?)
@ 2019-11-13  2:51                     ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  2:51 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 02:41), Dmitry Safonov wrote:
[..]
> 
> I don't strongly disagree, but if you look at those results:
> git grep 'printk("%s.*", \(lvl\|level\)'
> 
> it seems to be used in quite a few places.

Yes, you are right, it is used in some places. That's why I said
that I'd prefer to keep that number low (minimize it). But it's
not 0 (that ship has sailed).

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:51                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  2:51 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Petr Mladek, linux-pm, Heiko Carstens,
	linux-um, Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Len Brown, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 02:41), Dmitry Safonov wrote:
[..]
> 
> I don't strongly disagree, but if you look at those results:
> git grep 'printk("%s.*", \(lvl\|level\)'
> 
> it seems to be used in quite a few places.

Yes, you are right, it is used in some places. That's why I said
that I'd prefer to keep that number low (minimize it). But it's
not 0 (that ship has sailed).

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:51                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  2:51 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 02:41), Dmitry Safonov wrote:
[..]
> 
> I don't strongly disagree, but if you look at those results:
> git grep 'printk("%s.*", \(lvl\|level\)'
> 
> it seems to be used in quite a few places.

Yes, you are right, it is used in some places. That's why I said
that I'd prefer to keep that number low (minimize it). But it's
not 0 (that ship has sailed).

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:51                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  2:51 UTC (permalink / raw)
  To: openrisc

On (19/11/13 02:41), Dmitry Safonov wrote:
[..]
> 
> I don't strongly disagree, but if you look at those results:
> git grep 'printk("%s.*", \(lvl\|level\)'
> 
> it seems to be used in quite a few places.

Yes, you are right, it is used in some places. That's why I said
that I'd prefer to keep that number low (minimize it). But it's
not 0 (that ship has sailed).

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:51                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  2:51 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Sergey Senozhatsky, Petr Mladek, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Steven Rostedt, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On (19/11/13 02:41), Dmitry Safonov wrote:
[..]
> 
> I don't strongly disagree, but if you look at those results:
> git grep 'printk("%s.*", \(lvl\|level\)'
> 
> it seems to be used in quite a few places.

Yes, you are right, it is used in some places. That's why I said
that I'd prefer to keep that number low (minimize it). But it's
not 0 (that ship has sailed).

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  2:51                     ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  2:51 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki

On (19/11/13 02:41), Dmitry Safonov wrote:
[..]
> 
> I don't strongly disagree, but if you look at those results:
> git grep 'printk("%s.*", \(lvl\|level\)'
> 
> it seems to be used in quite a few places.

Yes, you are right, it is used in some places. That's why I said
that I'd prefer to keep that number low (minimize it). But it's
not 0 (that ship has sailed).

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-13  2:25                       ` Dmitry Safonov
                                           ` (3 preceding siblings ...)
  (?)
@ 2019-11-13  6:33                         ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  6:33 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 02:25), Dmitry Safonov wrote:
> I guess I've pointed that in my point of view price for one-time testing
> code is cheaper than adding a new printk feature to swap log levels on
> the fly.
[..]
> I've gone through functions used by sysrq driver and the same changes
> introducing log level parameter would be needed for: sched_show_task(),
> debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> them don't need any platform changes, but at least show_regs() needs.

Good points and nice conclusion.

Well, here we go. There is a number of generally useful functions that
print nice data and where people might want to have better loglevel control
(for debugging purposes). show_stack() is just one of them. Patching all
those functions, which you have mentioned above, is hardly a fun task to do.
Hence the printk() per-CPU per-context loglevel proposition. The code there
is not clever or complicated and is meant for debugging purposes only, but
with just 3 lines of code one can do some stuff:

	/* @BTW you can't do this with "%s" KERN_FOO ;P */
+	printk_emergency_enter(LOGLEVEL_SCHED);
+	debug_show_all_locks();
+	printk_emergency_exit();

Now...
I'm not sure if this whole thing is up to "printk maintainers only".
If no one is going to use "emergency printk contexts" then there is
no point in having that code in the kernel.

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  6:33                         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  6:33 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Petr Mladek, linux-pm, Heiko Carstens,
	linux-um, Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Len Brown, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 02:25), Dmitry Safonov wrote:
> I guess I've pointed that in my point of view price for one-time testing
> code is cheaper than adding a new printk feature to swap log levels on
> the fly.
[..]
> I've gone through functions used by sysrq driver and the same changes
> introducing log level parameter would be needed for: sched_show_task(),
> debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> them don't need any platform changes, but at least show_regs() needs.

Good points and nice conclusion.

Well, here we go. There is a number of generally useful functions that
print nice data and where people might want to have better loglevel control
(for debugging purposes). show_stack() is just one of them. Patching all
those functions, which you have mentioned above, is hardly a fun task to do.
Hence the printk() per-CPU per-context loglevel proposition. The code there
is not clever or complicated and is meant for debugging purposes only, but
with just 3 lines of code one can do some stuff:

	/* @BTW you can't do this with "%s" KERN_FOO ;P */
+	printk_emergency_enter(LOGLEVEL_SCHED);
+	debug_show_all_locks();
+	printk_emergency_exit();

Now...
I'm not sure if this whole thing is up to "printk maintainers only".
If no one is going to use "emergency printk contexts" then there is
no point in having that code in the kernel.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  6:33                         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  6:33 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 02:25), Dmitry Safonov wrote:
> I guess I've pointed that in my point of view price for one-time testing
> code is cheaper than adding a new printk feature to swap log levels on
> the fly.
[..]
> I've gone through functions used by sysrq driver and the same changes
> introducing log level parameter would be needed for: sched_show_task(),
> debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> them don't need any platform changes, but at least show_regs() needs.

Good points and nice conclusion.

Well, here we go. There is a number of generally useful functions that
print nice data and where people might want to have better loglevel control
(for debugging purposes). show_stack() is just one of them. Patching all
those functions, which you have mentioned above, is hardly a fun task to do.
Hence the printk() per-CPU per-context loglevel proposition. The code there
is not clever or complicated and is meant for debugging purposes only, but
with just 3 lines of code one can do some stuff:

	/* @BTW you can't do this with "%s" KERN_FOO ;P */
+	printk_emergency_enter(LOGLEVEL_SCHED);
+	debug_show_all_locks();
+	printk_emergency_exit();

Now...
I'm not sure if this whole thing is up to "printk maintainers only".
If no one is going to use "emergency printk contexts" then there is
no point in having that code in the kernel.

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  6:33                         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  6:33 UTC (permalink / raw)
  To: openrisc

On (19/11/13 02:25), Dmitry Safonov wrote:
> I guess I've pointed that in my point of view price for one-time testing
> code is cheaper than adding a new printk feature to swap log levels on
> the fly.
[..]
> I've gone through functions used by sysrq driver and the same changes
> introducing log level parameter would be needed for: sched_show_task(),
> debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> them don't need any platform changes, but at least show_regs() needs.

Good points and nice conclusion.

Well, here we go. There is a number of generally useful functions that
print nice data and where people might want to have better loglevel control
(for debugging purposes). show_stack() is just one of them. Patching all
those functions, which you have mentioned above, is hardly a fun task to do.
Hence the printk() per-CPU per-context loglevel proposition. The code there
is not clever or complicated and is meant for debugging purposes only, but
with just 3 lines of code one can do some stuff:

	/* @BTW you can't do this with "%s" KERN_FOO ;P */
+	printk_emergency_enter(LOGLEVEL_SCHED);
+	debug_show_all_locks();
+	printk_emergency_exit();

Now...
I'm not sure if this whole thing is up to "printk maintainers only".
If no one is going to use "emergency printk contexts" then there is
no point in having that code in the kernel.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  6:33                         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  6:33 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman, Ingo Molnar,
	Jiri Slaby, Sergey Senozhatsky, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On (19/11/13 02:25), Dmitry Safonov wrote:
> I guess I've pointed that in my point of view price for one-time testing
> code is cheaper than adding a new printk feature to swap log levels on
> the fly.
[..]
> I've gone through functions used by sysrq driver and the same changes
> introducing log level parameter would be needed for: sched_show_task(),
> debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> them don't need any platform changes, but at least show_regs() needs.

Good points and nice conclusion.

Well, here we go. There is a number of generally useful functions that
print nice data and where people might want to have better loglevel control
(for debugging purposes). show_stack() is just one of them. Patching all
those functions, which you have mentioned above, is hardly a fun task to do.
Hence the printk() per-CPU per-context loglevel proposition. The code there
is not clever or complicated and is meant for debugging purposes only, but
with just 3 lines of code one can do some stuff:

	/* @BTW you can't do this with "%s" KERN_FOO ;P */
+	printk_emergency_enter(LOGLEVEL_SCHED);
+	debug_show_all_locks();
+	printk_emergency_exit();

Now...
I'm not sure if this whole thing is up to "printk maintainers only".
If no one is going to use "emergency printk contexts" then there is
no point in having that code in the kernel.

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  6:33                         ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-13  6:33 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki

On (19/11/13 02:25), Dmitry Safonov wrote:
> I guess I've pointed that in my point of view price for one-time testing
> code is cheaper than adding a new printk feature to swap log levels on
> the fly.
[..]
> I've gone through functions used by sysrq driver and the same changes
> introducing log level parameter would be needed for: sched_show_task(),
> debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> them don't need any platform changes, but at least show_regs() needs.

Good points and nice conclusion.

Well, here we go. There is a number of generally useful functions that
print nice data and where people might want to have better loglevel control
(for debugging purposes). show_stack() is just one of them. Patching all
those functions, which you have mentioned above, is hardly a fun task to do.
Hence the printk() per-CPU per-context loglevel proposition. The code there
is not clever or complicated and is meant for debugging purposes only, but
with just 3 lines of code one can do some stuff:

	/* @BTW you can't do this with "%s" KERN_FOO ;P */
+	printk_emergency_enter(LOGLEVEL_SCHED);
+	debug_show_all_locks();
+	printk_emergency_exit();

Now...
I'm not sure if this whole thing is up to "printk maintainers only".
If no one is going to use "emergency printk contexts" then there is
no point in having that code in the kernel.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-13  6:33                         ` Sergey Senozhatsky
                                             ` (3 preceding siblings ...)
  (?)
@ 2019-11-13  8:47                           ` Petr Mladek
  -1 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-13  8:47 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed 2019-11-13 15:33:34, Sergey Senozhatsky wrote:
> On (19/11/13 02:25), Dmitry Safonov wrote:
> > I guess I've pointed that in my point of view price for one-time testing
> > code is cheaper than adding a new printk feature to swap log levels on
> > the fly.
> [..]
> > I've gone through functions used by sysrq driver and the same changes
> > introducing log level parameter would be needed for: sched_show_task(),
> > debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> > them don't need any platform changes, but at least show_regs() needs.
> 
> Good points and nice conclusion.
> 
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them.

Could you please provide some examples so that we get an idea about
the scope, usefulness, and requirements?

> Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

But this will not solve situations where the original loglevel should
stay from any reason. It happened in this patchset, see

https://lkml.kernel.org/r/20191106091258.GS25745@shell.armlinux.org.uk
https://lkml.kernel.org/r/20191106132516.GC5808@willie-the-truck

We would need to investigate more potential users of this feature to
see eventual requirements. If there are too many exceptions and modes
then the generic API might get pretty complicated.

At the moment, I am in favor of this patchset. It is huge and
needed a lot of manual work. But the result is straightforward and
easy to understand.

Best Regards,
Petr

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  8:47                           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-13  8:47 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Wed 2019-11-13 15:33:34, Sergey Senozhatsky wrote:
> On (19/11/13 02:25), Dmitry Safonov wrote:
> > I guess I've pointed that in my point of view price for one-time testing
> > code is cheaper than adding a new printk feature to swap log levels on
> > the fly.
> [..]
> > I've gone through functions used by sysrq driver and the same changes
> > introducing log level parameter would be needed for: sched_show_task(),
> > debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> > them don't need any platform changes, but at least show_regs() needs.
> 
> Good points and nice conclusion.
> 
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them.

Could you please provide some examples so that we get an idea about
the scope, usefulness, and requirements?

> Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

But this will not solve situations where the original loglevel should
stay from any reason. It happened in this patchset, see

https://lkml.kernel.org/r/20191106091258.GS25745@shell.armlinux.org.uk
https://lkml.kernel.org/r/20191106132516.GC5808@willie-the-truck

We would need to investigate more potential users of this feature to
see eventual requirements. If there are too many exceptions and modes
then the generic API might get pretty complicated.

At the moment, I am in favor of this patchset. It is huge and
needed a lot of manual work. But the result is straightforward and
easy to understand.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  8:47                           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-13  8:47 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed 2019-11-13 15:33:34, Sergey Senozhatsky wrote:
> On (19/11/13 02:25), Dmitry Safonov wrote:
> > I guess I've pointed that in my point of view price for one-time testing
> > code is cheaper than adding a new printk feature to swap log levels on
> > the fly.
> [..]
> > I've gone through functions used by sysrq driver and the same changes
> > introducing log level parameter would be needed for: sched_show_task(),
> > debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> > them don't need any platform changes, but at least show_regs() needs.
> 
> Good points and nice conclusion.
> 
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them.

Could you please provide some examples so that we get an idea about
the scope, usefulness, and requirements?

> Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

But this will not solve situations where the original loglevel should
stay from any reason. It happened in this patchset, see

https://lkml.kernel.org/r/20191106091258.GS25745@shell.armlinux.org.uk
https://lkml.kernel.org/r/20191106132516.GC5808@willie-the-truck

We would need to investigate more potential users of this feature to
see eventual requirements. If there are too many exceptions and modes
then the generic API might get pretty complicated.

At the moment, I am in favor of this patchset. It is huge and
needed a lot of manual work. But the result is straightforward and
easy to understand.

Best Regards,
Petr

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  8:47                           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-13  8:47 UTC (permalink / raw)
  To: openrisc

On Wed 2019-11-13 15:33:34, Sergey Senozhatsky wrote:
> On (19/11/13 02:25), Dmitry Safonov wrote:
> > I guess I've pointed that in my point of view price for one-time testing
> > code is cheaper than adding a new printk feature to swap log levels on
> > the fly.
> [..]
> > I've gone through functions used by sysrq driver and the same changes
> > introducing log level parameter would be needed for: sched_show_task(),
> > debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> > them don't need any platform changes, but at least show_regs() needs.
> 
> Good points and nice conclusion.
> 
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them.

Could you please provide some examples so that we get an idea about
the scope, usefulness, and requirements?

> Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

But this will not solve situations where the original loglevel should
stay from any reason. It happened in this patchset, see

https://lkml.kernel.org/r/20191106091258.GS25745 at shell.armlinux.org.uk
https://lkml.kernel.org/r/20191106132516.GC5808 at willie-the-truck

We would need to investigate more potential users of this feature to
see eventual requirements. If there are too many exceptions and modes
then the generic API might get pretty complicated.

At the moment, I am in favor of this patchset. It is huge and
needed a lot of manual work. But the result is straightforward and
easy to understand.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  8:47                           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-13  8:47 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Dmitry Safonov, Steven Rostedt, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J. Bottomley, linux-parisc,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev, Christian Borntraeger, Heiko Carstens,
	Vasily Gorbik, linux-s390, Rich Felker, linux-sh,
	David S. Miller, sparclinux, Anton Ivanov, Jeff Dike,
	Richard Weinberger, linux-um, Guan Xuetao, Borislav Petkov,
	H. Peter Anvin, x86, Chris Zankel, Max Filippov, linux-xtensa,
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

On Wed 2019-11-13 15:33:34, Sergey Senozhatsky wrote:
> On (19/11/13 02:25), Dmitry Safonov wrote:
> > I guess I've pointed that in my point of view price for one-time testing
> > code is cheaper than adding a new printk feature to swap log levels on
> > the fly.
> [..]
> > I've gone through functions used by sysrq driver and the same changes
> > introducing log level parameter would be needed for: sched_show_task(),
> > debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> > them don't need any platform changes, but at least show_regs() needs.
> 
> Good points and nice conclusion.
> 
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them.

Could you please provide some examples so that we get an idea about
the scope, usefulness, and requirements?

> Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

But this will not solve situations where the original loglevel should
stay from any reason. It happened in this patchset, see

https://lkml.kernel.org/r/20191106091258.GS25745@shell.armlinux.org.uk
https://lkml.kernel.org/r/20191106132516.GC5808@willie-the-truck

We would need to investigate more potential users of this feature to
see eventual requirements. If there are too many exceptions and modes
then the generic API might get pretty complicated.

At the moment, I am in favor of this patchset. It is huge and
needed a lot of manual work. But the result is straightforward and
easy to understand.

Best Regards,
Petr


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13  8:47                           ` Petr Mladek
  0 siblings, 0 replies; 323+ messages in thread
From: Petr Mladek @ 2019-11-13  8:47 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On Wed 2019-11-13 15:33:34, Sergey Senozhatsky wrote:
> On (19/11/13 02:25), Dmitry Safonov wrote:
> > I guess I've pointed that in my point of view price for one-time testing
> > code is cheaper than adding a new printk feature to swap log levels on
> > the fly.
> [..]
> > I've gone through functions used by sysrq driver and the same changes
> > introducing log level parameter would be needed for: sched_show_task(),
> > debug_show_all_locks(), show_regs(), show_state(), show_mem(). Some of
> > them don't need any platform changes, but at least show_regs() needs.
> 
> Good points and nice conclusion.
> 
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them.

Could you please provide some examples so that we get an idea about
the scope, usefulness, and requirements?

> Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

But this will not solve situations where the original loglevel should
stay from any reason. It happened in this patchset, see

https://lkml.kernel.org/r/20191106091258.GS25745@shell.armlinux.org.uk
https://lkml.kernel.org/r/20191106132516.GC5808@willie-the-truck

We would need to investigate more potential users of this feature to
see eventual requirements. If there are too many exceptions and modes
then the generic API might get pretty complicated.

At the moment, I am in favor of this patchset. It is huge and
needed a lot of manual work. But the result is straightforward and
easy to understand.

Best Regards,
Petr

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-12  4:44             ` Sergey Senozhatsky
                                 ` (3 preceding siblings ...)
  (?)
@ 2019-11-13 15:32               ` Steven Rostedt
  -1 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:32 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Petr Mladek, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Tue, 12 Nov 2019 13:44:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> > > I do recall that we talked about per-CPU printk state bit which would
> > > start/end "just print it" section. We probably can extend it to "just
> > > log_store" type of functionality. Doesn't look like a very bad idea.  
> > 
> > The problem with per-CPU printk is that we would need to disable
> > interrupts.  
> 
> Or disable preemption and have loglevel per-CPU and per-context.
> preempt_count can navigate us to the right context loglevel on
> particular CPU. I'm talking here only about backtrace (error)
> reporting contexts. Those can be atomic perfectly fine.

With my real-time hat on, I'm totally against disabling of preemption
for this purpose.

-- Steve

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:32               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:32 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Ivan Kokshaysky,
	Greentime Hu, Guan Xuetao, linux-parisc, linux-alpha,
	Ley Foon Tan, David S. Miller, Rich Felker, Petr Mladek,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Tue, 12 Nov 2019 13:44:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> > > I do recall that we talked about per-CPU printk state bit which would
> > > start/end "just print it" section. We probably can extend it to "just
> > > log_store" type of functionality. Doesn't look like a very bad idea.  
> > 
> > The problem with per-CPU printk is that we would need to disable
> > interrupts.  
> 
> Or disable preemption and have loglevel per-CPU and per-context.
> preempt_count can navigate us to the right context loglevel on
> particular CPU. I'm talking here only about backtrace (error)
> reporting contexts. Those can be atomic perfectly fine.

With my real-time hat on, I'm totally against disabling of preemption
for this purpose.

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:32               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:32 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Petr Mladek, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Tue, 12 Nov 2019 13:44:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> > > I do recall that we talked about per-CPU printk state bit which would
> > > start/end "just print it" section. We probably can extend it to "just
> > > log_store" type of functionality. Doesn't look like a very bad idea.  
> > 
> > The problem with per-CPU printk is that we would need to disable
> > interrupts.  
> 
> Or disable preemption and have loglevel per-CPU and per-context.
> preempt_count can navigate us to the right context loglevel on
> particular CPU. I'm talking here only about backtrace (error)
> reporting contexts. Those can be atomic perfectly fine.

With my real-time hat on, I'm totally against disabling of preemption
for this purpose.

-- Steve

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:32               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:32 UTC (permalink / raw)
  To: openrisc

On Tue, 12 Nov 2019 13:44:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> > > I do recall that we talked about per-CPU printk state bit which would
> > > start/end "just print it" section. We probably can extend it to "just
> > > log_store" type of functionality. Doesn't look like a very bad idea.  
> > 
> > The problem with per-CPU printk is that we would need to disable
> > interrupts.  
> 
> Or disable preemption and have loglevel per-CPU and per-context.
> preempt_count can navigate us to the right context loglevel on
> particular CPU. I'm talking here only about backtrace (error)
> reporting contexts. Those can be atomic perfectly fine.

With my real-time hat on, I'm totally against disabling of preemption
for this purpose.

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:32               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:32 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Petr Mladek, Dmitry Safonov, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J.

On Tue, 12 Nov 2019 13:44:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> > > I do recall that we talked about per-CPU printk state bit which would
> > > start/end "just print it" section. We probably can extend it to "just
> > > log_store" type of functionality. Doesn't look like a very bad idea.  
> > 
> > The problem with per-CPU printk is that we would need to disable
> > interrupts.  
> 
> Or disable preemption and have loglevel per-CPU and per-context.
> preempt_count can navigate us to the right context loglevel on
> particular CPU. I'm talking here only about backtrace (error)
> reporting contexts. Those can be atomic perfectly fine.

With my real-time hat on, I'm totally against disabling of preemption
for this purpose.

-- Steve


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:32               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:32 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On Tue, 12 Nov 2019 13:44:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> > > I do recall that we talked about per-CPU printk state bit which would
> > > start/end "just print it" section. We probably can extend it to "just
> > > log_store" type of functionality. Doesn't look like a very bad idea.  
> > 
> > The problem with per-CPU printk is that we would need to disable
> > interrupts.  
> 
> Or disable preemption and have loglevel per-CPU and per-context.
> preempt_count can navigate us to the right context loglevel on
> particular CPU. I'm talking here only about backtrace (error)
> reporting contexts. Those can be atomic perfectly fine.

With my real-time hat on, I'm totally against disabling of preemption
for this purpose.

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-12  2:17             ` Sergey Senozhatsky
                                 ` (3 preceding siblings ...)
  (?)
@ 2019-11-13 15:39               ` Steven Rostedt
  -1 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:39 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Petr Mladek, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Tue, 12 Nov 2019 11:17:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> {
> 	printk_emergency_enter(log_level);
> 	__show_stack(task, sp);
> 	printk_emergency_exit();
> }
> // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> 
> show_stack() never schedules, disabling preemption around it should
> not change anything. Should it be interrupted, we will handle it via
> preempt count.

Please no! The whole point of the printk rewrite was to allow for
printk to be preemptible and used in more contexts. The show_stack() can
be all over the place and is not a fast function. Let's not disable
preemption for it.

-- Steve

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:39               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:39 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Ivan Kokshaysky,
	Greentime Hu, Guan Xuetao, linux-parisc, linux-alpha,
	Ley Foon Tan, David S. Miller, Rich Felker, Petr Mladek,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Tue, 12 Nov 2019 11:17:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> {
> 	printk_emergency_enter(log_level);
> 	__show_stack(task, sp);
> 	printk_emergency_exit();
> }
> // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> 
> show_stack() never schedules, disabling preemption around it should
> not change anything. Should it be interrupted, we will handle it via
> preempt count.

Please no! The whole point of the printk rewrite was to allow for
printk to be preemptible and used in more contexts. The show_stack() can
be all over the place and is not a fast function. Let's not disable
preemption for it.

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:39               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:39 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Petr Mladek, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Tue, 12 Nov 2019 11:17:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> {
> 	printk_emergency_enter(log_level);
> 	__show_stack(task, sp);
> 	printk_emergency_exit();
> }
> // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> 
> show_stack() never schedules, disabling preemption around it should
> not change anything. Should it be interrupted, we will handle it via
> preempt count.

Please no! The whole point of the printk rewrite was to allow for
printk to be preemptible and used in more contexts. The show_stack() can
be all over the place and is not a fast function. Let's not disable
preemption for it.

-- Steve

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:39               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:39 UTC (permalink / raw)
  To: openrisc

On Tue, 12 Nov 2019 11:17:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> {
> 	printk_emergency_enter(log_level);
> 	__show_stack(task, sp);
> 	printk_emergency_exit();
> }
> // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> 
> show_stack() never schedules, disabling preemption around it should
> not change anything. Should it be interrupted, we will handle it via
> preempt count.

Please no! The whole point of the printk rewrite was to allow for
printk to be preemptible and used in more contexts. The show_stack() can
be all over the place and is not a fast function. Let's not disable
preemption for it.

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:39               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:39 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Dmitry Safonov, Petr Mladek, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J.

On Tue, 12 Nov 2019 11:17:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> {
> 	printk_emergency_enter(log_level);
> 	__show_stack(task, sp);
> 	printk_emergency_exit();
> }
> // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> 
> show_stack() never schedules, disabling preemption around it should
> not change anything. Should it be interrupted, we will handle it via
> preempt count.

Please no! The whole point of the printk rewrite was to allow for
printk to be preemptible and used in more contexts. The show_stack() can
be all over the place and is not a fast function. Let's not disable
preemption for it.

-- Steve


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:39               ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:39 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On Tue, 12 Nov 2019 11:17:47 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:

> void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> {
> 	printk_emergency_enter(log_level);
> 	__show_stack(task, sp);
> 	printk_emergency_exit();
> }
> // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> 
> show_stack() never schedules, disabling preemption around it should
> not change anything. Should it be interrupted, we will handle it via
> preempt count.

Please no! The whole point of the printk rewrite was to allow for
printk to be preemptible and used in more contexts. The show_stack() can
be all over the place and is not a fast function. Let's not disable
preemption for it.

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06 20:34       ` Peter Zijlstra
                           ` (3 preceding siblings ...)
  (?)
@ 2019-11-13 15:41         ` Steven Rostedt
  -1 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:41 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Petr Mladek, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On Wed, 6 Nov 2019 21:34:40 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Unfortunately that is the case. As my tests will fail if a backtrace is
detected.

> 
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

I usually end up removing backtraces for my tests, so I'm for this.
Specifically this happens in the drm and i915 drivers :-p

-- Steve


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:41         ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:41 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Ivan Kokshaysky,
	Greentime Hu, Guan Xuetao, linux-parisc, linux-alpha,
	Ley Foon Tan, David S. Miller, Rich Felker, Petr Mladek,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Wed, 6 Nov 2019 21:34:40 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Unfortunately that is the case. As my tests will fail if a backtrace is
detected.

> 
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

I usually end up removing backtraces for my tests, so I'm for this.
Specifically this happens in the drm and i915 drivers :-p

-- Steve


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:41         ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:41 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Petr Mladek, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On Wed, 6 Nov 2019 21:34:40 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Unfortunately that is the case. As my tests will fail if a backtrace is
detected.

> 
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

I usually end up removing backtraces for my tests, so I'm for this.
Specifically this happens in the drm and i915 drivers :-p

-- Steve


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:41         ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:41 UTC (permalink / raw)
  To: openrisc

On Wed, 6 Nov 2019 21:34:40 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Unfortunately that is the case. As my tests will fail if a backtrace is
detected.

> 
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

I usually end up removing backtraces for my tests, so I'm for this.
Specifically this happens in the drm and i915 drivers :-p

-- Steve


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:41         ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:41 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Dmitry Safonov, linux-kernel, Dmitry Safonov, Andrew Morton,
	Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby, Petr Mladek,
	Sergey Senozhatsky, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Ralf Baechle, Thomas Gleixner,
	Vincent Chen, Vincent Guittot, Will Deacon, linux-mips,
	linux-riscv, Ivan Kokshaysky, Matt Turner, Richard Henderson,
	linux-alpha, Vineet Gupta, linux-snps-arc, Russell King,
	linux-arm-kernel, clang-built-linux, Catalin Marinas,
	Aurelien Jacquiot, Mark Salter, linux-c6x-dev, Guo Ren,
	Yoshinori Sato, uclinux-h8-devel, Brian Cain, linux-hexagon,
	Fenghua Yu, Tony Luck, linux-ia64, Geert Uytterhoeven,
	linux-m68k, Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller, James E.J.

On Wed, 6 Nov 2019 21:34:40 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Unfortunately that is the case. As my tests will fail if a backtrace is
detected.

> 
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

I usually end up removing backtraces for my tests, so I'm for this.
Specifically this happens in the drm and i915 drivers :-p

-- Steve



^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:41         ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:41 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On Wed, 6 Nov 2019 21:34:40 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.

Unfortunately that is the case. As my tests will fail if a backtrace is
detected.

> 
> Perhaps we should be removing backtraces if they're not important
> instead of allowing to print them as lower loglevels?

I usually end up removing backtraces for my tests, so I'm for this.
Specifically this happens in the drm and i915 drivers :-p

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-06 23:25         ` Russell King - ARM Linux admin
                             ` (3 preceding siblings ...)
  (?)
@ 2019-11-13 15:44           ` Steven Rostedt
  -1 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:44 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Petr Mladek, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, clang-built-linux, Ingo Molnar,
	Mark Salter, Albert Ou, Stefan Kristiansson, openrisc,
	Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, 6 Nov 2019 23:25:13 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:

> On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.  
> 
> Or utterly meaningless.
> 
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?  
> 
> Definitely!  WARN_ON() is well overused - and as is typical, used
> without much thought.  Bound to happen after Linus got shirty about
> BUG_ON() being over used.  Everyone just grabbed the next nearest thing
> to assert().
> 
> As a kind of example, I've recently come across one WARN_ON() in a
> driver subsystem (that shall remain nameless at the moment) which very
> likely has multiple different devices on a platform.  The WARN_ON()
> triggers as a result of a problem with the hardware, but because it's a
> WARN_ON(), you've no idea which device has a problem.  The backtrace is
> mostly meaningless.  So you know that a problem has occurred, but the
> kernel prints *useless* backtrace to let you know, and totally omits
> the *useful* information.
> 

I would like to bring up a topic for the next maintainers summit
(although I may not even be there), that we define a clear use of
WARN_ON(). I use it only if the code does something I do not expect it
to do, and is considered a bug in the code if it triggers. But it
appears that some drivers use it for "oh I didn't realize this hardware
does something I didn't expect". And is ignored when the warn on is
triggered and reported, with "you have buggy hardware" but my hardware
appears to work just fine!

-- Steve

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:44           ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:44 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Ivan Kokshaysky,
	Greentime Hu, Guan Xuetao, linux-parisc, linux-alpha,
	Ley Foon Tan, David S. Miller, Rich Felker, Petr Mladek,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Wed, 6 Nov 2019 23:25:13 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:

> On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.  
> 
> Or utterly meaningless.
> 
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?  
> 
> Definitely!  WARN_ON() is well overused - and as is typical, used
> without much thought.  Bound to happen after Linus got shirty about
> BUG_ON() being over used.  Everyone just grabbed the next nearest thing
> to assert().
> 
> As a kind of example, I've recently come across one WARN_ON() in a
> driver subsystem (that shall remain nameless at the moment) which very
> likely has multiple different devices on a platform.  The WARN_ON()
> triggers as a result of a problem with the hardware, but because it's a
> WARN_ON(), you've no idea which device has a problem.  The backtrace is
> mostly meaningless.  So you know that a problem has occurred, but the
> kernel prints *useless* backtrace to let you know, and totally omits
> the *useful* information.
> 

I would like to bring up a topic for the next maintainers summit
(although I may not even be there), that we define a clear use of
WARN_ON(). I use it only if the code does something I do not expect it
to do, and is considered a bug in the code if it triggers. But it
appears that some drivers use it for "oh I didn't realize this hardware
does something I didn't expect". And is ignored when the warn on is
triggered and reported, with "you have buggy hardware" but my hardware
appears to work just fine!

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:44           ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:44 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Petr Mladek, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, clang-built-linux, Ingo Molnar,
	Mark Salter, Albert Ou, Stefan Kristiansson, openrisc,
	Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On Wed, 6 Nov 2019 23:25:13 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:

> On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.  
> 
> Or utterly meaningless.
> 
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?  
> 
> Definitely!  WARN_ON() is well overused - and as is typical, used
> without much thought.  Bound to happen after Linus got shirty about
> BUG_ON() being over used.  Everyone just grabbed the next nearest thing
> to assert().
> 
> As a kind of example, I've recently come across one WARN_ON() in a
> driver subsystem (that shall remain nameless at the moment) which very
> likely has multiple different devices on a platform.  The WARN_ON()
> triggers as a result of a problem with the hardware, but because it's a
> WARN_ON(), you've no idea which device has a problem.  The backtrace is
> mostly meaningless.  So you know that a problem has occurred, but the
> kernel prints *useless* backtrace to let you know, and totally omits
> the *useful* information.
> 

I would like to bring up a topic for the next maintainers summit
(although I may not even be there), that we define a clear use of
WARN_ON(). I use it only if the code does something I do not expect it
to do, and is considered a bug in the code if it triggers. But it
appears that some drivers use it for "oh I didn't realize this hardware
does something I didn't expect". And is ignored when the warn on is
triggered and reported, with "you have buggy hardware" but my hardware
appears to work just fine!

-- Steve

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:44           ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:44 UTC (permalink / raw)
  To: openrisc

On Wed, 6 Nov 2019 23:25:13 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:

> On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.  
> 
> Or utterly meaningless.
> 
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?  
> 
> Definitely!  WARN_ON() is well overused - and as is typical, used
> without much thought.  Bound to happen after Linus got shirty about
> BUG_ON() being over used.  Everyone just grabbed the next nearest thing
> to assert().
> 
> As a kind of example, I've recently come across one WARN_ON() in a
> driver subsystem (that shall remain nameless at the moment) which very
> likely has multiple different devices on a platform.  The WARN_ON()
> triggers as a result of a problem with the hardware, but because it's a
> WARN_ON(), you've no idea which device has a problem.  The backtrace is
> mostly meaningless.  So you know that a problem has occurred, but the
> kernel prints *useless* backtrace to let you know, and totally omits
> the *useful* information.
> 

I would like to bring up a topic for the next maintainers summit
(although I may not even be there), that we define a clear use of
WARN_ON(). I use it only if the code does something I do not expect it
to do, and is considered a bug in the code if it triggers. But it
appears that some drivers use it for "oh I didn't realize this hardware
does something I didn't expect". And is ignored when the warn on is
triggered and reported, with "you have buggy hardware" but my hardware
appears to work just fine!

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:44           ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:44 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Peter Zijlstra, Dmitry Safonov, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Petr Mladek, Sergey Senozhatsky, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	linux-arm-kernel, clang-built-linux, Catalin Marinas,
	Aurelien Jacquiot, Mark Salter, linux-c6x-dev, Guo Ren,
	Yoshinori Sato, uclinux-h8-devel, Brian Cain, linux-hexagon,
	Fenghua Yu, Tony Luck, linux-ia64, Geert Uytterhoeven,
	linux-m68k, Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On Wed, 6 Nov 2019 23:25:13 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:

> On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.  
> 
> Or utterly meaningless.
> 
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?  
> 
> Definitely!  WARN_ON() is well overused - and as is typical, used
> without much thought.  Bound to happen after Linus got shirty about
> BUG_ON() being over used.  Everyone just grabbed the next nearest thing
> to assert().
> 
> As a kind of example, I've recently come across one WARN_ON() in a
> driver subsystem (that shall remain nameless at the moment) which very
> likely has multiple different devices on a platform.  The WARN_ON()
> triggers as a result of a problem with the hardware, but because it's a
> WARN_ON(), you've no idea which device has a problem.  The backtrace is
> mostly meaningless.  So you know that a problem has occurred, but the
> kernel prints *useless* backtrace to let you know, and totally omits
> the *useful* information.
> 

I would like to bring up a topic for the next maintainers summit
(although I may not even be there), that we define a clear use of
WARN_ON(). I use it only if the code does something I do not expect it
to do, and is considered a bug in the code if it triggers. But it
appears that some drivers use it for "oh I didn't realize this hardware
does something I didn't expect". And is ignored when the warn on is
triggered and reported, with "you have buggy hardware" but my hardware
appears to work just fine!

-- Steve


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 15:44           ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:44 UTC (permalink / raw)
  To: Russell King - ARM Linux admin
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Dmitry Safonov,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kerne

On Wed, 6 Nov 2019 23:25:13 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:

> On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> > I suppose I'm surprised there are backtraces that are not important.
> > Either badness happened and it needs printing, or the user asked for it
> > and it needs printing.  
> 
> Or utterly meaningless.
> 
> > Perhaps we should be removing backtraces if they're not important
> > instead of allowing to print them as lower loglevels?  
> 
> Definitely!  WARN_ON() is well overused - and as is typical, used
> without much thought.  Bound to happen after Linus got shirty about
> BUG_ON() being over used.  Everyone just grabbed the next nearest thing
> to assert().
> 
> As a kind of example, I've recently come across one WARN_ON() in a
> driver subsystem (that shall remain nameless at the moment) which very
> likely has multiple different devices on a platform.  The WARN_ON()
> triggers as a result of a problem with the hardware, but because it's a
> WARN_ON(), you've no idea which device has a problem.  The backtrace is
> mostly meaningless.  So you know that a problem has occurred, but the
> kernel prints *useless* backtrace to let you know, and totally omits
> the *useful* information.
> 

I would like to bring up a topic for the next maintainers summit
(although I may not even be there), that we define a clear use of
WARN_ON(). I use it only if the code does something I do not expect it
to do, and is considered a bug in the code if it triggers. But it
appears that some drivers use it for "oh I didn't realize this hardware
does something I didn't expect". And is ignored when the warn on is
triggered and reported, with "you have buggy hardware" but my hardware
appears to work just fine!

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 01/50] kallsyms/printk: Add loglvl to print_ip_sym()
  2019-11-06  3:04   ` Dmitry Safonov
@ 2019-11-13 15:49     ` Steven Rostedt
  -1 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:49 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: linux-kernel, Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman,
	Ingo Molnar, Jiri Slaby, Petr Mladek, Sergey Senozhatsky,
	Tetsuo Handa, Albert Ou, Ben Segall, Dietmar Eggemann,
	Greentime Hu, Ingo Molnar, James Hogan, Juri Lelli, Mel Gorman,
	Michal Simek, Palmer Dabbelt, Paul Burton, Paul Walmsley,
	Peter Zijlstra, Ralf Baechle, Thomas Gleixner, Vincent Chen,
	Vincent Guittot, Will Deacon, linux-mips, linux-riscv

On Wed,  6 Nov 2019 03:04:52 +0000
Dmitry Safonov <dima@arista.com> wrote:

> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -2002,12 +2002,12 @@ void ftrace_bug(int failed, struct dyn_ftrace *rec)
>  	case -EFAULT:
>  		FTRACE_WARN_ON_ONCE(1);
>  		pr_info("ftrace faulted on modifying ");

Hmm, I wonder if I should change that from info to something more
important, as this is important information for debugging. But this has
nothing to do with this patch set.

> -		print_ip_sym(ip);
> +		print_ip_sym(KERN_INFO, ip);

Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

-- Steve

>  		break;
>  	case -EINVAL:
>  		FTRACE_WARN_ON_ONCE(1);
>  		pr_info("ftrace failed to modify ");
> -		print_ip_sym(ip);
> +		print_ip_sym(KERN_INFO, ip);
>  		print_ip_ins(" actual:   ", (unsigned char *)ip);
>  		pr_cont("\n");
>  		if (ftrace_expected) {
> @@ -2018,12 +2018,12 @@ void ftrace_bug(int failed, struct dyn_ftrace *rec)
>  	case -EPERM:
>  		FTRACE_WARN_ON_ONCE(1);
>  		pr_info("ftrace faulted on writing ");
> -		print_ip_sym(ip);
> +		print_ip_sym(KERN_INFO, ip);
>  		break;
>  	default:
>  		FTRACE_WARN_ON_ONCE(1);
>  		pr_info("ftrace faulted on unknown error ");
> -		print_ip_sym(ip);
> +		print_ip_sym(KERN_INFO, ip);
>  	}
>  	print_bug_type();
>  	if (rec) {


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 01/50] kallsyms/printk: Add loglvl to print_ip_sym()
@ 2019-11-13 15:49     ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 15:49 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Tetsuo Handa, James Hogan, Dmitry Safonov,
	linux-mips, Ben Segall, linux-riscv, Vincent Chen, Will Deacon,
	Ingo Molnar, Vincent Guittot, Paul Burton, Peter Zijlstra,
	Ingo Molnar, Mel Gorman, Jiri Slaby, Petr Mladek, Albert Ou,
	Greentime Hu, Paul Walmsley, Thomas Gleixner, Dietmar Eggemann,
	Michal Simek, Greg Kroah-Hartman, linux-kernel, Ralf Baechle,
	Sergey Senozhatsky, Palmer Dabbelt, Andrew Morton

On Wed,  6 Nov 2019 03:04:52 +0000
Dmitry Safonov <dima@arista.com> wrote:

> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -2002,12 +2002,12 @@ void ftrace_bug(int failed, struct dyn_ftrace *rec)
>  	case -EFAULT:
>  		FTRACE_WARN_ON_ONCE(1);
>  		pr_info("ftrace faulted on modifying ");

Hmm, I wonder if I should change that from info to something more
important, as this is important information for debugging. But this has
nothing to do with this patch set.

> -		print_ip_sym(ip);
> +		print_ip_sym(KERN_INFO, ip);

Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

-- Steve

>  		break;
>  	case -EINVAL:
>  		FTRACE_WARN_ON_ONCE(1);
>  		pr_info("ftrace failed to modify ");
> -		print_ip_sym(ip);
> +		print_ip_sym(KERN_INFO, ip);
>  		print_ip_ins(" actual:   ", (unsigned char *)ip);
>  		pr_cont("\n");
>  		if (ftrace_expected) {
> @@ -2018,12 +2018,12 @@ void ftrace_bug(int failed, struct dyn_ftrace *rec)
>  	case -EPERM:
>  		FTRACE_WARN_ON_ONCE(1);
>  		pr_info("ftrace faulted on writing ");
> -		print_ip_sym(ip);
> +		print_ip_sym(KERN_INFO, ip);
>  		break;
>  	default:
>  		FTRACE_WARN_ON_ONCE(1);
>  		pr_info("ftrace faulted on unknown error ");
> -		print_ip_sym(ip);
> +		print_ip_sym(KERN_INFO, ip);
>  	}
>  	print_bug_type();
>  	if (rec) {


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-13  8:47                           ` Petr Mladek
                                               ` (3 preceding siblings ...)
  (?)
@ 2019-11-13 16:24                             ` Steven Rostedt
  -1 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 16:24 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On Wed, 13 Nov 2019 09:47:22 +0100
Petr Mladek <pmladek@suse.com> wrote:

> At the moment, I am in favor of this patchset. It is huge and
> needed a lot of manual work. But the result is straightforward and
> easy to understand.

I'm in favor of this patchset too. If there's other areas that need to
adjust the current loglevel (say per task context), then we can cross
that bridge when the need arises. But I don't want to over engineer
this as the stack trace logic should have a way to explicitly state how
important this stack trace really is (or better yet, we should be
removing stack traces that are not important!)

-- Steve

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:24                             ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 16:24 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Dmitry Safonov, Will Deacon, Daniel Thompson,
	Brian Cain, Christian Borntraeger, kgdb-bugreport,
	linux-snps-arc, Fenghua Yu, Borislav Petkov, Jeff Dike,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Peter Zijlstra, H. Peter Anvin, sparclinux, linux-riscv,
	Anton Ivanov, Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On Wed, 13 Nov 2019 09:47:22 +0100
Petr Mladek <pmladek@suse.com> wrote:

> At the moment, I am in favor of this patchset. It is huge and
> needed a lot of manual work. But the result is straightforward and
> easy to understand.

I'm in favor of this patchset too. If there's other areas that need to
adjust the current loglevel (say per task context), then we can cross
that bridge when the need arises. But I don't want to over engineer
this as the stack trace logic should have a way to explicitly state how
important this stack trace really is (or better yet, we should be
removing stack traces that are not important!)

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:24                             ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 16:24 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On Wed, 13 Nov 2019 09:47:22 +0100
Petr Mladek <pmladek@suse.com> wrote:

> At the moment, I am in favor of this patchset. It is huge and
> needed a lot of manual work. But the result is straightforward and
> easy to understand.

I'm in favor of this patchset too. If there's other areas that need to
adjust the current loglevel (say per task context), then we can cross
that bridge when the need arises. But I don't want to over engineer
this as the stack trace logic should have a way to explicitly state how
important this stack trace really is (or better yet, we should be
removing stack traces that are not important!)

-- Steve

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:24                             ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 16:24 UTC (permalink / raw)
  To: openrisc

On Wed, 13 Nov 2019 09:47:22 +0100
Petr Mladek <pmladek@suse.com> wrote:

> At the moment, I am in favor of this patchset. It is huge and
> needed a lot of manual work. But the result is straightforward and
> easy to understand.

I'm in favor of this patchset too. If there's other areas that need to
adjust the current loglevel (say per task context), then we can cross
that bridge when the need arises. But I don't want to over engineer
this as the stack trace logic should have a way to explicitly state how
important this stack trace really is (or better yet, we should be
removing stack traces that are not important!)

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:24                             ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 16:24 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Sergey Senozhatsky, Dmitry Safonov, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J.

On Wed, 13 Nov 2019 09:47:22 +0100
Petr Mladek <pmladek@suse.com> wrote:

> At the moment, I am in favor of this patchset. It is huge and
> needed a lot of manual work. But the result is straightforward and
> easy to understand.

I'm in favor of this patchset too. If there's other areas that need to
adjust the current loglevel (say per task context), then we can cross
that bridge when the need arises. But I don't want to over engineer
this as the stack trace logic should have a way to explicitly state how
important this stack trace really is (or better yet, we should be
removing stack traces that are not important!)

-- Steve


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:24                             ` Steven Rostedt
  0 siblings, 0 replies; 323+ messages in thread
From: Steven Rostedt @ 2019-11-13 16:24 UTC (permalink / raw)
  To: Petr Mladek
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman

On Wed, 13 Nov 2019 09:47:22 +0100
Petr Mladek <pmladek@suse.com> wrote:

> At the moment, I am in favor of this patchset. It is huge and
> needed a lot of manual work. But the result is straightforward and
> easy to understand.

I'm in favor of this patchset too. If there's other areas that need to
adjust the current loglevel (say per task context), then we can cross
that bridge when the need arises. But I don't want to over engineer
this as the stack trace logic should have a way to explicitly state how
important this stack trace really is (or better yet, we should be
removing stack traces that are not important!)

-- Steve

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-13  6:33                         ` Sergey Senozhatsky
                                             ` (3 preceding siblings ...)
  (?)
@ 2019-11-13 16:40                           ` Dmitry Safonov
  -1 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13 16:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

Hi Sergey,

On 11/13/19 6:33 AM, Sergey Senozhatsky wrote:
[..]
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them. Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

Not that I want to critic your proposal more, but just to clarify what
I've meant by "cleaver and complicated":

I don't think semantically there is any difference between:

printk_emergency_enter(LOGLEVEL_SCHED);
printk();
printk_emergency_exit();
vs
printk("%s ...", KERN_SHED, ...);

I was speaking about complexity not about usage, but about realization
inside printk_emergency_enter(): there will be some business logic that
will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade
the loglevel..." and other smart details those are really logic which
one have to think about and later maintain.

There will be also minor issues like people inserting print with one log
level and seeing it in dmesg with another, but I presume those
printk_enter() and printk_exit() will cover little amount of code
without much nesting [as long as it's not getting overused]. And also it
can be documented and people will learn about another feature of printk().

And this year I've seen the presentation "Why printk() is so
complicated?" and I presumed that the approach is to keep things as
simple as possible.

In conclusion:
I see that your proposal also solves the problem [except preemption and
some pr_debug() that shouldn't be printed]. And I think your approach is
better in the sense of short-term (we won't have any missed %s KERN_ in
linux-next), but in a long-term it adds some amount of business logic to
printk and another feature.

Just in case: again, I don't mind, it's up to you, maintainers of
printk. It's also not very fun for me to create those patches.
But they fix console_loglevel issues (I hope we could un-export it in
the end) and also I need it for my other patches those will produce
warnings with debug loglevel when configured through sysctl.

Thanks,
          Dmitry

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:40                           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13 16:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Geert Uytterhoeven,
	Mel Gorman, Jiri Slaby, Matt Turner, uclinux-h8-devel, Len Brown,
	linux-pm, Heiko Carstens, linux-um, Thomas Gleixner,
	Dietmar Eggemann, Richard Henderson, Greg Kroah-Hartman,
	Rafael J. Wysocki, linux-kernel, Ralf Baechle, Paul Mackerras,
	Andrew Morton, linux-ia64, Tetsuo Handa, James Hogan,
	James E.J. Bottomley, Max Filippov, Vincent Chen, Ingo Molnar,
	linux-s390, linux-c6x-dev, Yoshinori Sato, linux-hexagon,
	Helge Deller, linux-xtensa, Vasily Gorbik, Aurelien Jacquiot,
	linux-m68k, Stafford Horne, linux-arm-kernel, Chris Zankel,
	Tony Luck, Douglas Anderson, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

Hi Sergey,

On 11/13/19 6:33 AM, Sergey Senozhatsky wrote:
[..]
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them. Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

Not that I want to critic your proposal more, but just to clarify what
I've meant by "cleaver and complicated":

I don't think semantically there is any difference between:

printk_emergency_enter(LOGLEVEL_SCHED);
printk();
printk_emergency_exit();
vs
printk("%s ...", KERN_SHED, ...);

I was speaking about complexity not about usage, but about realization
inside printk_emergency_enter(): there will be some business logic that
will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade
the loglevel..." and other smart details those are really logic which
one have to think about and later maintain.

There will be also minor issues like people inserting print with one log
level and seeing it in dmesg with another, but I presume those
printk_enter() and printk_exit() will cover little amount of code
without much nesting [as long as it's not getting overused]. And also it
can be documented and people will learn about another feature of printk().

And this year I've seen the presentation "Why printk() is so
complicated?" and I presumed that the approach is to keep things as
simple as possible.

In conclusion:
I see that your proposal also solves the problem [except preemption and
some pr_debug() that shouldn't be printed]. And I think your approach is
better in the sense of short-term (we won't have any missed %s KERN_ in
linux-next), but in a long-term it adds some amount of business logic to
printk and another feature.

Just in case: again, I don't mind, it's up to you, maintainers of
printk. It's also not very fun for me to create those patches.
But they fix console_loglevel issues (I hope we could un-export it in
the end) and also I need it for my other patches those will produce
warnings with debug loglevel when configured through sysctl.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:40                           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13 16:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Benjamin Herrenschmidt, Dmitry Safonov, Will Deacon,
	Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Petr Mladek, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

Hi Sergey,

On 11/13/19 6:33 AM, Sergey Senozhatsky wrote:
[..]
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them. Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

Not that I want to critic your proposal more, but just to clarify what
I've meant by "cleaver and complicated":

I don't think semantically there is any difference between:

printk_emergency_enter(LOGLEVEL_SCHED);
printk();
printk_emergency_exit();
vs
printk("%s ...", KERN_SHED, ...);

I was speaking about complexity not about usage, but about realization
inside printk_emergency_enter(): there will be some business logic that
will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade
the loglevel..." and other smart details those are really logic which
one have to think about and later maintain.

There will be also minor issues like people inserting print with one log
level and seeing it in dmesg with another, but I presume those
printk_enter() and printk_exit() will cover little amount of code
without much nesting [as long as it's not getting overused]. And also it
can be documented and people will learn about another feature of printk().

And this year I've seen the presentation "Why printk() is so
complicated?" and I presumed that the approach is to keep things as
simple as possible.

In conclusion:
I see that your proposal also solves the problem [except preemption and
some pr_debug() that shouldn't be printed]. And I think your approach is
better in the sense of short-term (we won't have any missed %s KERN_ in
linux-next), but in a long-term it adds some amount of business logic to
printk and another feature.

Just in case: again, I don't mind, it's up to you, maintainers of
printk. It's also not very fun for me to create those patches.
But they fix console_loglevel issues (I hope we could un-export it in
the end) and also I need it for my other patches those will produce
warnings with debug loglevel when configured through sysctl.

Thanks,
          Dmitry

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:40                           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13 16:40 UTC (permalink / raw)
  To: openrisc

Hi Sergey,

On 11/13/19 6:33 AM, Sergey Senozhatsky wrote:
[..]
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them. Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

Not that I want to critic your proposal more, but just to clarify what
I've meant by "cleaver and complicated":

I don't think semantically there is any difference between:

printk_emergency_enter(LOGLEVEL_SCHED);
printk();
printk_emergency_exit();
vs
printk("%s ...", KERN_SHED, ...);

I was speaking about complexity not about usage, but about realization
inside printk_emergency_enter(): there will be some business logic that
will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade
the loglevel..." and other smart details those are really logic which
one have to think about and later maintain.

There will be also minor issues like people inserting print with one log
level and seeing it in dmesg with another, but I presume those
printk_enter() and printk_exit() will cover little amount of code
without much nesting [as long as it's not getting overused]. And also it
can be documented and people will learn about another feature of printk().

And this year I've seen the presentation "Why printk() is so
complicated?" and I presumed that the approach is to keep things as
simple as possible.

In conclusion:
I see that your proposal also solves the problem [except preemption and
some pr_debug() that shouldn't be printed]. And I think your approach is
better in the sense of short-term (we won't have any missed %s KERN_ in
linux-next), but in a long-term it adds some amount of business logic to
printk and another feature.

Just in case: again, I don't mind, it's up to you, maintainers of
printk. It's also not very fun for me to create those patches.
But they fix console_loglevel issues (I hope we could un-export it in
the end) and also I need it for my other patches those will produce
warnings with debug loglevel when configured through sysctl.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:40                           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13 16:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Petr Mladek, Steven Rostedt, linux-kernel, Dmitry Safonov,
	Andrew Morton, Greg Kroah-Hartman, Ingo Molnar, Jiri Slaby,
	Sergey Senozhatsky, Tetsuo Handa, Albert Ou, Ben Segall,
	Dietmar Eggemann, Greentime Hu, Ingo Molnar, James Hogan,
	Juri Lelli, Mel Gorman, Michal Simek, Palmer Dabbelt,
	Paul Burton, Paul Walmsley, Peter Zijlstra, Ralf Baechle,
	Thomas Gleixner, Vincent Chen, Vincent Guittot, Will Deacon,
	linux-mips, linux-riscv, Ivan Kokshaysky, Matt Turner,
	Richard Henderson, linux-alpha, Vineet Gupta, linux-snps-arc,
	Russell King, linux-arm-kernel, clang-built-linux,
	Catalin Marinas, Aurelien Jacquiot, Mark Salter, linux-c6x-dev,
	Guo Ren, Yoshinori Sato, uclinux-h8-devel, Brian Cain,
	linux-hexagon, Fenghua Yu, Tony Luck, linux-ia64,
	Geert Uytterhoeven, linux-m68k, Ley Foon Tan, nios2-dev,
	Jonas Bonn, Stafford Horne, Stefan Kristiansson, openrisc,
	Helge Deller, James E.J. Bottomley, linux-parisc,
	Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras,
	linuxppc-dev, Christian Borntraeger, Heiko Carstens,
	Vasily Gorbik, linux-s390, Rich Felker, linux-sh,
	David S. Miller, sparclinux, Anton Ivanov, Jeff Dike,
	Richard Weinberger, linux-um, Guan Xuetao, Borislav Petkov,
	H. Peter Anvin, x86, Chris Zankel, Max Filippov, linux-xtensa,
	Len Brown, Pavel Machek, Rafael J. Wysocki, linux-pm,
	Daniel Thompson, Douglas Anderson, Jason Wessel, kgdb-bugreport

Hi Sergey,

On 11/13/19 6:33 AM, Sergey Senozhatsky wrote:
[..]
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them. Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

Not that I want to critic your proposal more, but just to clarify what
I've meant by "cleaver and complicated":

I don't think semantically there is any difference between:

printk_emergency_enter(LOGLEVEL_SCHED);
printk();
printk_emergency_exit();
vs
printk("%s ...", KERN_SHED, ...);

I was speaking about complexity not about usage, but about realization
inside printk_emergency_enter(): there will be some business logic that
will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade
the loglevel..." and other smart details those are really logic which
one have to think about and later maintain.

There will be also minor issues like people inserting print with one log
level and seeing it in dmesg with another, but I presume those
printk_enter() and printk_exit() will cover little amount of code
without much nesting [as long as it's not getting overused]. And also it
can be documented and people will learn about another feature of printk().

And this year I've seen the presentation "Why printk() is so
complicated?" and I presumed that the approach is to keep things as
simple as possible.

In conclusion:
I see that your proposal also solves the problem [except preemption and
some pr_debug() that shouldn't be printed]. And I think your approach is
better in the sense of short-term (we won't have any missed %s KERN_ in
linux-next), but in a long-term it adds some amount of business logic to
printk and another feature.

Just in case: again, I don't mind, it's up to you, maintainers of
printk. It's also not very fun for me to create those patches.
But they fix console_loglevel issues (I hope we could un-export it in
the end) and also I need it for my other patches those will produce
warnings with debug loglevel when configured through sysctl.

Thanks,
          Dmitry


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-13 16:40                           ` Dmitry Safonov
  0 siblings, 0 replies; 323+ messages in thread
From: Dmitry Safonov @ 2019-11-13 16:40 UTC (permalink / raw)
  To: Sergey Senozhatsky
  Cc: Juri Lelli, linux-sh, Catalin Marinas, Ben Segall, Guo Ren,
	Pavel Machek, Vincent Guittot, Paul Burton, Michael Ellerman,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Len Brown, linux-pm, Heiko Carstens, linux-um,
	Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle

Hi Sergey,

On 11/13/19 6:33 AM, Sergey Senozhatsky wrote:
[..]
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them. Patching all
> those functions, which you have mentioned above, is hardly a fun task to do.
> Hence the printk() per-CPU per-context loglevel proposition. The code there
> is not clever or complicated and is meant for debugging purposes only, but
> with just 3 lines of code one can do some stuff:
> 
> 	/* @BTW you can't do this with "%s" KERN_FOO ;P */
> +	printk_emergency_enter(LOGLEVEL_SCHED);
> +	debug_show_all_locks();
> +	printk_emergency_exit();

Not that I want to critic your proposal more, but just to clarify what
I've meant by "cleaver and complicated":

I don't think semantically there is any difference between:

printk_emergency_enter(LOGLEVEL_SCHED);
printk();
printk_emergency_exit();
vs
printk("%s ...", KERN_SHED, ...);

I was speaking about complexity not about usage, but about realization
inside printk_emergency_enter(): there will be some business logic that
will do "it's NMI? Use loglevel given. it's KERN_ALERT? Don't downgrade
the loglevel..." and other smart details those are really logic which
one have to think about and later maintain.

There will be also minor issues like people inserting print with one log
level and seeing it in dmesg with another, but I presume those
printk_enter() and printk_exit() will cover little amount of code
without much nesting [as long as it's not getting overused]. And also it
can be documented and people will learn about another feature of printk().

And this year I've seen the presentation "Why printk() is so
complicated?" and I presumed that the approach is to keep things as
simple as possible.

In conclusion:
I see that your proposal also solves the problem [except preemption and
some pr_debug() that shouldn't be printed]. And I think your approach is
better in the sense of short-term (we won't have any missed %s KERN_ in
linux-next), but in a long-term it adds some amount of business logic to
printk and another feature.

Just in case: again, I don't mind, it's up to you, maintainers of
printk. It's also not very fun for me to create those patches.
But they fix console_loglevel issues (I hope we could un-export it in
the end) and also I need it for my other patches those will produce
warnings with debug loglevel when configured through sysctl.

Thanks,
          Dmitry

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-13 16:40                           ` Dmitry Safonov
                                               ` (3 preceding siblings ...)
  (?)
@ 2019-11-15  0:50                             ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  0:50 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 16:40), Dmitry Safonov wrote:
> It's also not very fun for me to create those patches.
> But they fix console_loglevel issues (I hope we could un-export it in
> the end) and also I need it for my other patches those will produce
> warnings with debug loglevel when configured through sysctl.

No objections.

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  0:50                             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  0:50 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Geert Uytterhoeven, Mel Gorman, Jiri Slaby, Matt Turner,
	uclinux-h8-devel, Petr Mladek, linux-pm, Heiko Carstens,
	linux-um, Thomas Gleixner, Dietmar Eggemann, Richard Henderson,
	Greg Kroah-Hartman, Rafael J. Wysocki, linux-kernel,
	Ralf Baechle, Paul Mackerras, Andrew Morton, linux-ia64,
	Tetsuo Handa, James Hogan, James E.J. Bottomley, Max Filippov,
	Vincent Chen, Ingo Molnar, linux-s390, linux-c6x-dev,
	Yoshinori Sato, linux-hexagon, Helge Deller, linux-xtensa,
	Vasily Gorbik, Aurelien Jacquiot, linux-m68k, Stafford Horne,
	linux-arm-kernel, Chris Zankel, Tony Luck, Douglas Anderson,
	Dmitry Safonov, Will Deacon, Daniel Thompson, Brian Cain,
	Christian Borntraeger, kgdb-bugreport, linux-snps-arc,
	Fenghua Yu, Borislav Petkov, Jeff Dike, Steven Rostedt,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Len Brown, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 16:40), Dmitry Safonov wrote:
> It's also not very fun for me to create those patches.
> But they fix console_loglevel issues (I hope we could un-export it in
> the end) and also I need it for my other patches those will produce
> warnings with debug loglevel when configured through sysctl.

No objections.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  0:50                             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  0:50 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Steven Rostedt, Ivan Kokshaysky, Greentime Hu,
	Guan Xuetao, linux-parisc, linux-alpha, Ley Foon Tan,
	David S. Miller, Rich Felker, Len Brown, Peter Zijlstra,
	H. Peter Anvin, sparclinux, linux-riscv, Anton Ivanov,
	Jonas Bonn, Richard Weinberger, x86, Russell King,
	clang-built-linux, Ingo Molnar, Mark Salter, Albert Ou,
	Stefan Kristiansson, openrisc, Paul Walmsley, Michal Simek,
	Vineet Gupta, linux-mips, Sergey Senozhatsky, Palmer Dabbelt,
	Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 16:40), Dmitry Safonov wrote:
> It's also not very fun for me to create those patches.
> But they fix console_loglevel issues (I hope we could un-export it in
> the end) and also I need it for my other patches those will produce
> warnings with debug loglevel when configured through sysctl.

No objections.

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  0:50                             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  0:50 UTC (permalink / raw)
  To: openrisc

On (19/11/13 16:40), Dmitry Safonov wrote:
> It's also not very fun for me to create those patches.
> But they fix console_loglevel issues (I hope we could un-export it in
> the end) and also I need it for my other patches those will produce
> warnings with debug loglevel when configured through sysctl.

No objections.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  0:50                             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  0:50 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Sergey Senozhatsky, Petr Mladek, Steven Rostedt, linux-kernel,
	Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman, Ingo Molnar,
	Jiri Slaby, Sergey Senozhatsky, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On (19/11/13 16:40), Dmitry Safonov wrote:
> It's also not very fun for me to create those patches.
> But they fix console_loglevel issues (I hope we could un-export it in
> the end) and also I need it for my other patches those will produce
> warnings with debug loglevel when configured through sysctl.

No objections.

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  0:50                             ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  0:50 UTC (permalink / raw)
  To: Dmitry Safonov
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Michael Ellerman, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki

On (19/11/13 16:40), Dmitry Safonov wrote:
> It's also not very fun for me to create those patches.
> But they fix console_loglevel issues (I hope we could un-export it in
> the end) and also I need it for my other patches those will produce
> warnings with debug loglevel when configured through sysctl.

No objections.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
  2019-11-13 15:39               ` Steven Rostedt
                                   ` (3 preceding siblings ...)
  (?)
@ 2019-11-15  3:36                 ` Sergey Senozhatsky
  -1 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  3:36 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Len Brown, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/13 10:39), Steven Rostedt wrote:
[..]
> > void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> > {
> > 	printk_emergency_enter(log_level);
> > 	__show_stack(task, sp);
> > 	printk_emergency_exit();
> > }
> > // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> >
> > show_stack() never schedules, disabling preemption around it should
> > not change anything. Should it be interrupted, we will handle it via
> > preempt count.
>
> Please no! The whole point of the printk rewrite was to allow for
> printk to be preemptible and used in more contexts. The show_stack() can
> be all over the place and is not a fast function. Let's not disable
> preemption for it.

I never said that this code should be used all over the place. What
I did say several times was that this code is for quick debugging,
when one sits behind a slow serial console and wants to tweak loglevel
of all printk-s of a particular context/function only.

	-ss

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  3:36                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  3:36 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Geert Uytterhoeven, Mel Gorman, Jiri Slaby,
	Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Dmitry Safonov, Will Deacon, Daniel Thompson,
	Brian Cain, Christian Borntraeger, kgdb-bugreport,
	linux-snps-arc, Fenghua Yu, Borislav Petkov, Jeff Dike,
	Ivan Kokshaysky, Greentime Hu, Guan Xuetao, linux-parisc,
	linux-alpha, Ley Foon Tan, David S. Miller, Rich Felker,
	Len Brown, Peter Zijlstra, H. Peter Anvin, sparclinux,
	linux-riscv, Anton Ivanov, Jonas Bonn, Richard Weinberger, x86,
	Russell King, clang-built-linux, Ingo Molnar, Mark Salter,
	Albert Ou, Stefan Kristiansson, openrisc, Paul Walmsley,
	Michal Simek, Vineet Gupta, linux-mips, Sergey Senozhatsky,
	Palmer Dabbelt, Jason Wessel, nios2-dev, linuxppc-dev

On (19/11/13 10:39), Steven Rostedt wrote:
[..]
> > void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> > {
> > 	printk_emergency_enter(log_level);
> > 	__show_stack(task, sp);
> > 	printk_emergency_exit();
> > }
> > // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> >
> > show_stack() never schedules, disabling preemption around it should
> > not change anything. Should it be interrupted, we will handle it via
> > preempt count.
>
> Please no! The whole point of the printk rewrite was to allow for
> printk to be preemptible and used in more contexts. The show_stack() can
> be all over the place and is not a fast function. Let's not disable
> preemption for it.

I never said that this code should be used all over the place. What
I did say several times was that this code is for quick debugging,
when one sits behind a slow serial console and wants to tweak loglevel
of all printk-s of a particular context/function only.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  3:36                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  3:36 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman, Rafael J. Wysocki,
	linux-kernel, Ralf Baechle, Paul Mackerras, Andrew Morton,
	linux-ia64, Tetsuo Handa, James Hogan, James E.J. Bottomley,
	Max Filippov, Vincent Chen, Ingo Molnar, linux-s390,
	linux-c6x-dev, Yoshinori Sato, linux-hexagon, Helge Deller,
	linux-xtensa, Vasily Gorbik, Aurelien Jacquiot, linux-m68k,
	Stafford Horne, linux-arm-kernel, Chris Zankel, Tony Luck,
	Douglas Anderson, Benjamin Herrenschmidt, Dmitry Safonov,
	Will Deacon, Daniel Thompson, Brian Cain, Christian Borntraeger,
	kgdb-bugreport, linux-snps-arc, Fenghua Yu, Borislav Petkov,
	Jeff Dike, Ivan Kokshaysky, Greentime Hu, Guan Xuetao,
	linux-parisc, linux-alpha, Ley Foon Tan, David S. Miller,
	Rich Felker, Len Brown, Peter Zijlstra, H. Peter Anvin,
	sparclinux, linux-riscv, Anton Ivanov, Jonas Bonn,
	Richard Weinberger, x86, Russell King, clang-built-linux,
	Ingo Molnar, Mark Salter, Albert Ou, Stefan Kristiansson,
	openrisc, Paul Walmsley, Michal Simek, Vineet Gupta, linux-mips,
	Sergey Senozhatsky, Palmer Dabbelt, Jason Wessel, nios2-dev,
	linuxppc-dev

On (19/11/13 10:39), Steven Rostedt wrote:
[..]
> > void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> > {
> > 	printk_emergency_enter(log_level);
> > 	__show_stack(task, sp);
> > 	printk_emergency_exit();
> > }
> > // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> >
> > show_stack() never schedules, disabling preemption around it should
> > not change anything. Should it be interrupted, we will handle it via
> > preempt count.
>
> Please no! The whole point of the printk rewrite was to allow for
> printk to be preemptible and used in more contexts. The show_stack() can
> be all over the place and is not a fast function. Let's not disable
> preemption for it.

I never said that this code should be used all over the place. What
I did say several times was that this code is for quick debugging,
when one sits behind a slow serial console and wants to tweak loglevel
of all printk-s of a particular context/function only.

	-ss

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply	[flat|nested] 323+ messages in thread

* [OpenRISC] [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  3:36                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  3:36 UTC (permalink / raw)
  To: openrisc

On (19/11/13 10:39), Steven Rostedt wrote:
[..]
> > void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> > {
> > 	printk_emergency_enter(log_level);
> > 	__show_stack(task, sp);
> > 	printk_emergency_exit();
> > }
> > // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> >
> > show_stack() never schedules, disabling preemption around it should
> > not change anything. Should it be interrupted, we will handle it via
> > preempt count.
>
> Please no! The whole point of the printk rewrite was to allow for
> printk to be preemptible and used in more contexts. The show_stack() can
> be all over the place and is not a fast function. Let's not disable
> preemption for it.

I never said that this code should be used all over the place. What
I did say several times was that this code is for quick debugging,
when one sits behind a slow serial console and wants to tweak loglevel
of all printk-s of a particular context/function only.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  3:36                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  3:36 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Sergey Senozhatsky, Dmitry Safonov, Petr Mladek, linux-kernel,
	Dmitry Safonov, Andrew Morton, Greg Kroah-Hartman, Ingo Molnar,
	Jiri Slaby, Sergey Senozhatsky, Tetsuo Handa, Albert Ou,
	Ben Segall, Dietmar Eggemann, Greentime Hu, Ingo Molnar,
	James Hogan, Juri Lelli, Mel Gorman, Michal Simek,
	Palmer Dabbelt, Paul Burton, Paul Walmsley, Peter Zijlstra,
	Ralf Baechle, Thomas Gleixner, Vincent Chen, Vincent Guittot,
	Will Deacon, linux-mips, linux-riscv, Ivan Kokshaysky,
	Matt Turner, Richard Henderson, linux-alpha, Vineet Gupta,
	linux-snps-arc, Russell King, linux-arm-kernel,
	clang-built-linux, Catalin Marinas, Aurelien Jacquiot,
	Mark Salter, linux-c6x-dev, Guo Ren, Yoshinori Sato,
	uclinux-h8-devel, Brian Cain, linux-hexagon, Fenghua Yu,
	Tony Luck, linux-ia64, Geert Uytterhoeven, linux-m68k,
	Ley Foon Tan, nios2-dev, Jonas Bonn, Stafford Horne,
	Stefan Kristiansson, openrisc, Helge Deller,
	James E.J. Bottomley, linux-parisc, Benjamin Herrenschmidt,
	Michael Ellerman, Paul Mackerras, linuxppc-dev,
	Christian Borntraeger, Heiko Carstens, Vasily Gorbik, linux-s390,
	Rich Felker, linux-sh, David S. Miller, sparclinux, Anton Ivanov,
	Jeff Dike, Richard Weinberger, linux-um, Guan Xuetao,
	Borislav Petkov, H. Peter Anvin, x86, Chris Zankel, Max Filippov,
	linux-xtensa, Len Brown, Pavel Machek, Rafael J. Wysocki,
	linux-pm, Daniel Thompson, Douglas Anderson, Jason Wessel,
	kgdb-bugreport

On (19/11/13 10:39), Steven Rostedt wrote:
[..]
> > void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> > {
> > 	printk_emergency_enter(log_level);
> > 	__show_stack(task, sp);
> > 	printk_emergency_exit();
> > }
> > // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> >
> > show_stack() never schedules, disabling preemption around it should
> > not change anything. Should it be interrupted, we will handle it via
> > preempt count.
>
> Please no! The whole point of the printk rewrite was to allow for
> printk to be preemptible and used in more contexts. The show_stack() can
> be all over the place and is not a fast function. Let's not disable
> preemption for it.

I never said that this code should be used all over the place. What
I did say several times was that this code is for quick debugging,
when one sits behind a slow serial console and wants to tweak loglevel
of all printk-s of a particular context/function only.

	-ss


^ permalink raw reply	[flat|nested] 323+ messages in thread

* Re: [PATCH 00/50] Add log level to show_stack()
@ 2019-11-15  3:36                 ` Sergey Senozhatsky
  0 siblings, 0 replies; 323+ messages in thread
From: Sergey Senozhatsky @ 2019-11-15  3:36 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Juri Lelli, Sergey Senozhatsky, linux-sh, Catalin Marinas,
	Ben Segall, Guo Ren, Pavel Machek, Vincent Guittot, Paul Burton,
	Dmitry Safonov, Michael Ellerman, Geert Uytterhoeven, Mel Gorman,
	Jiri Slaby, Matt Turner, uclinux-h8-devel, Petr Mladek, linux-pm,
	Heiko Carstens, linux-um, Thomas Gleixner, Dietmar Eggemann,
	Richard Henderson, Greg Kroah-Hartman

On (19/11/13 10:39), Steven Rostedt wrote:
[..]
> > void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> > {
> > 	printk_emergency_enter(log_level);
> > 	__show_stack(task, sp);
> > 	printk_emergency_exit();
> > }
> > // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //
> >
> > show_stack() never schedules, disabling preemption around it should
> > not change anything. Should it be interrupted, we will handle it via
> > preempt count.
>
> Please no! The whole point of the printk rewrite was to allow for
> printk to be preemptible and used in more contexts. The show_stack() can
> be all over the place and is not a fast function. Let's not disable
> preemption for it.

I never said that this code should be used all over the place. What
I did say several times was that this code is for quick debugging,
when one sits behind a slow serial console and wants to tweak loglevel
of all printk-s of a particular context/function only.

	-ss

^ permalink raw reply	[flat|nested] 323+ messages in thread

end of thread, other threads:[~2019-11-15  4:09 UTC | newest]

Thread overview: 323+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-06  3:04 [PATCH 00/50] Add log level to show_stack() Dmitry Safonov
2019-11-06  3:04 ` Dmitry Safonov
2019-11-06  3:04 ` Dmitry Safonov
2019-11-06  3:04 ` [OpenRISC] " Dmitry Safonov
2019-11-06  3:04 ` Dmitry Safonov
2019-11-06  3:04 ` Dmitry Safonov
2019-11-06  3:04 ` [PATCH 01/50] kallsyms/printk: Add loglvl to print_ip_sym() Dmitry Safonov
2019-11-06  3:04   ` Dmitry Safonov
2019-11-06  4:38   ` Sergey Senozhatsky
2019-11-06  4:38     ` Sergey Senozhatsky
2019-11-06 16:39     ` Dmitry Safonov
2019-11-06 16:39       ` Dmitry Safonov
2019-11-13 15:49   ` Steven Rostedt
2019-11-13 15:49     ` Steven Rostedt
2019-11-06  3:04 ` [PATCH 02/50] alpha: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  3:04 ` [PATCH 03/50] arc: " Dmitry Safonov
2019-11-06  3:04   ` Dmitry Safonov
2019-11-06  3:04 ` [PATCH 04/50] arm/asm: Add loglvl to c_backtrace() Dmitry Safonov
2019-11-06  3:04   ` Dmitry Safonov
2019-11-06  3:04 ` [PATCH 05/50] arm: Add loglvl to unwind_backtrace() Dmitry Safonov
2019-11-06  3:04   ` Dmitry Safonov
2019-11-06  9:12   ` Russell King - ARM Linux admin
2019-11-06  9:12     ` Russell King - ARM Linux admin
2019-11-06 16:32     ` Dmitry Safonov
2019-11-06 16:32       ` Dmitry Safonov
2019-11-06  3:04 ` [PATCH 06/50] arm: Add loglvl to dump_backtrace() Dmitry Safonov
2019-11-06  3:04   ` Dmitry Safonov
2019-11-06  3:04 ` [PATCH 07/50] arm: Wire up dump_backtrace_{entry,stm} Dmitry Safonov
2019-11-06  3:04   ` Dmitry Safonov
2019-11-06  3:04 ` [PATCH 08/50] arm: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  3:04   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 09/50] arm64: Add loglvl to dump_backtrace() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06 13:25   ` Will Deacon
2019-11-06 13:25     ` Will Deacon
2019-11-06 16:00     ` Dmitry Safonov
2019-11-06 16:00       ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 10/50] arm64: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 11/50] c6x: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 12/50] csky: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 13/50] h8300: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 14/50] hexagon: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 15/50] ia64: Pass log level as arg into ia64_do_show_stack() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 16/50] ia64: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 17/50] m68k: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 18/50] microblaze: Add loglvl to microblaze_unwind_inner() Dmitry Safonov
2019-11-07  8:59   ` Michal Simek
2019-11-08  7:52   ` kbuild test robot
2019-11-08  7:52     ` kbuild test robot
2019-11-06  3:05 ` [PATCH 19/50] microblaze: Add loglvl to microblaze_unwind() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 20/50] microblaze: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 21/50] mips: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 22/50] nds32: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 23/50] nios2: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 24/50] openrisc: " Dmitry Safonov
2019-11-06  3:05   ` [OpenRISC] " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 25/50] parisc: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 26/50] powerpc: " Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  9:52   ` Michael Ellerman
2019-11-06  9:52     ` Michael Ellerman
2019-11-06 16:01     ` Dmitry Safonov
2019-11-06 16:01       ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 27/50] riscv: " Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 28/50] s390: " Dmitry Safonov
2019-11-06  3:05 ` [PATCH 29/50] sh: Add loglvl to dump_mem() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 30/50] sh: Remove needless printk() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 31/50] sh: Add loglvl to printk_address() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 32/50] sh: Add loglvl to show_trace() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 33/50] sh: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 34/50] sparc: " Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:33   ` David Miller
2019-11-06  3:33     ` David Miller
2019-11-06 16:02     ` Dmitry Safonov
2019-11-06 16:02       ` Dmitry Safonov
2019-11-08  7:08   ` kbuild test robot
2019-11-08  7:08     ` kbuild test robot
2019-11-08  7:08     ` kbuild test robot
2019-11-06  3:05 ` [PATCH 35/50] um/sysrq: Remove needless variable sp Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 36/50] um: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05   ` Dmitry Safonov
2019-11-06  3:05 ` [PATCH 37/50] unicore32: Remove unused pmode argument in c_backtrace() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 38/50] unicore32: Add loglvl to c_backtrace() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 39/50] unicore32: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 40/50] x86: Add missing const qualifiers for log_lvl Dmitry Safonov
2019-11-06  3:05 ` [PATCH 41/50] x86: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 42/50] xtensa: Add loglvl to show_trace() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 43/50] xtensa: Add show_stack_loglvl() Dmitry Safonov
2019-11-06  4:13   ` Max Filippov
2019-11-06  8:15     ` Petr Mladek
2019-11-06 16:06       ` Dmitry Safonov
2019-11-06 16:44       ` Max Filippov
2019-11-06  3:05 ` [PATCH 44/50] sysrq: Use show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 45/50] x86/amd_gart: Print stacktrace for a leak with KERN_ERR Dmitry Safonov
2019-11-06  3:05 ` [PATCH 46/50] power: Use show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 47/50] kdb: Don't play with console_loglevel Dmitry Safonov
2019-11-06  3:05 ` [PATCH 48/50] sched: Print stack trace with KERN_INFO Dmitry Safonov
2019-11-06  3:05 ` [PATCH 49/50] kernel: Use show_stack_loglvl() Dmitry Safonov
2019-11-06  3:05 ` [PATCH 50/50] kernel: Rename show_stack_loglvl() => show_stack() Dmitry Safonov
2019-11-08 10:08   ` kbuild test robot
2019-11-08 10:08     ` kbuild test robot
2019-11-06  8:35 ` [PATCH 00/50] Add log level to show_stack() Petr Mladek
2019-11-06  8:35   ` Petr Mladek
2019-11-06  8:35   ` Petr Mladek
2019-11-06  8:35   ` [OpenRISC] " Petr Mladek
2019-11-06  8:35   ` Petr Mladek
2019-11-06  8:35   ` Petr Mladek
2019-11-06 16:12   ` Dmitry Safonov
2019-11-06 16:12     ` Dmitry Safonov
2019-11-06 16:12     ` Dmitry Safonov
2019-11-06 16:12     ` [OpenRISC] " Dmitry Safonov
2019-11-06 16:12     ` Dmitry Safonov
2019-11-06 16:12     ` Dmitry Safonov
2019-11-08 10:37   ` Sergey Senozhatsky
2019-11-08 10:37     ` Sergey Senozhatsky
2019-11-08 10:37     ` Sergey Senozhatsky
2019-11-08 10:37     ` [OpenRISC] " Sergey Senozhatsky
2019-11-08 10:37     ` Sergey Senozhatsky
2019-11-08 10:37     ` Sergey Senozhatsky
2019-11-08 13:04     ` Petr Mladek
2019-11-08 13:04       ` Petr Mladek
2019-11-08 13:04       ` Petr Mladek
2019-11-08 13:04       ` [OpenRISC] " Petr Mladek
2019-11-08 13:04       ` Petr Mladek
2019-11-08 13:04       ` Petr Mladek
2019-11-11  1:23       ` Sergey Senozhatsky
2019-11-11  1:23         ` Sergey Senozhatsky
2019-11-11  1:23         ` Sergey Senozhatsky
2019-11-11  1:23         ` [OpenRISC] " Sergey Senozhatsky
2019-11-11  1:23         ` Sergey Senozhatsky
2019-11-11  1:23         ` Sergey Senozhatsky
2019-11-11  9:12         ` Petr Mladek
2019-11-11  9:12           ` Petr Mladek
2019-11-11  9:12           ` Petr Mladek
2019-11-11  9:12           ` [OpenRISC] " Petr Mladek
2019-11-11  9:12           ` Petr Mladek
2019-11-11  9:12           ` Petr Mladek
2019-11-12  4:44           ` Sergey Senozhatsky
2019-11-12  4:44             ` Sergey Senozhatsky
2019-11-12  4:44             ` Sergey Senozhatsky
2019-11-12  4:44             ` [OpenRISC] " Sergey Senozhatsky
2019-11-12  4:44             ` Sergey Senozhatsky
2019-11-12  4:44             ` Sergey Senozhatsky
2019-11-12  4:57             ` Sergey Senozhatsky
2019-11-12  4:57               ` Sergey Senozhatsky
2019-11-12  4:57               ` Sergey Senozhatsky
2019-11-12  4:57               ` [OpenRISC] " Sergey Senozhatsky
2019-11-12  4:57               ` Sergey Senozhatsky
2019-11-12  4:57               ` Sergey Senozhatsky
2019-11-12  8:35               ` Petr Mladek
2019-11-12  8:35                 ` Petr Mladek
2019-11-12  8:35                 ` Petr Mladek
2019-11-12  8:35                 ` [OpenRISC] " Petr Mladek
2019-11-12  8:35                 ` Petr Mladek
2019-11-12  8:35                 ` Petr Mladek
2019-11-12 10:12                 ` Sergey Senozhatsky
2019-11-12 10:12                   ` Sergey Senozhatsky
2019-11-12 10:12                   ` Sergey Senozhatsky
2019-11-12 10:12                   ` [OpenRISC] " Sergey Senozhatsky
2019-11-12 10:12                   ` Sergey Senozhatsky
2019-11-12 10:12                   ` Sergey Senozhatsky
2019-11-13  1:23                   ` Sergey Senozhatsky
2019-11-13  1:23                     ` Sergey Senozhatsky
2019-11-13  1:23                     ` Sergey Senozhatsky
2019-11-13  1:23                     ` [OpenRISC] " Sergey Senozhatsky
2019-11-13  1:23                     ` Sergey Senozhatsky
2019-11-13  1:23                     ` Sergey Senozhatsky
2019-11-13  2:25                     ` Dmitry Safonov
2019-11-13  2:25                       ` Dmitry Safonov
2019-11-13  2:25                       ` Dmitry Safonov
2019-11-13  2:25                       ` [OpenRISC] " Dmitry Safonov
2019-11-13  2:25                       ` Dmitry Safonov
2019-11-13  2:25                       ` Dmitry Safonov
2019-11-13  6:33                       ` Sergey Senozhatsky
2019-11-13  6:33                         ` Sergey Senozhatsky
2019-11-13  6:33                         ` Sergey Senozhatsky
2019-11-13  6:33                         ` [OpenRISC] " Sergey Senozhatsky
2019-11-13  6:33                         ` Sergey Senozhatsky
2019-11-13  6:33                         ` Sergey Senozhatsky
2019-11-13  8:47                         ` Petr Mladek
2019-11-13  8:47                           ` Petr Mladek
2019-11-13  8:47                           ` Petr Mladek
2019-11-13  8:47                           ` [OpenRISC] " Petr Mladek
2019-11-13  8:47                           ` Petr Mladek
2019-11-13  8:47                           ` Petr Mladek
2019-11-13 16:24                           ` Steven Rostedt
2019-11-13 16:24                             ` Steven Rostedt
2019-11-13 16:24                             ` Steven Rostedt
2019-11-13 16:24                             ` [OpenRISC] " Steven Rostedt
2019-11-13 16:24                             ` Steven Rostedt
2019-11-13 16:24                             ` Steven Rostedt
2019-11-13 16:40                         ` Dmitry Safonov
2019-11-13 16:40                           ` Dmitry Safonov
2019-11-13 16:40                           ` Dmitry Safonov
2019-11-13 16:40                           ` [OpenRISC] " Dmitry Safonov
2019-11-13 16:40                           ` Dmitry Safonov
2019-11-13 16:40                           ` Dmitry Safonov
2019-11-15  0:50                           ` Sergey Senozhatsky
2019-11-15  0:50                             ` Sergey Senozhatsky
2019-11-15  0:50                             ` Sergey Senozhatsky
2019-11-15  0:50                             ` [OpenRISC] " Sergey Senozhatsky
2019-11-15  0:50                             ` Sergey Senozhatsky
2019-11-15  0:50                             ` Sergey Senozhatsky
2019-11-13 15:32             ` Steven Rostedt
2019-11-13 15:32               ` Steven Rostedt
2019-11-13 15:32               ` Steven Rostedt
2019-11-13 15:32               ` [OpenRISC] " Steven Rostedt
2019-11-13 15:32               ` Steven Rostedt
2019-11-13 15:32               ` Steven Rostedt
2019-11-11 19:47         ` Dmitry Safonov
2019-11-11 19:47           ` Dmitry Safonov
2019-11-11 19:47           ` Dmitry Safonov
2019-11-11 19:47           ` [OpenRISC] " Dmitry Safonov
2019-11-11 19:47           ` Dmitry Safonov
2019-11-11 19:47           ` Dmitry Safonov
2019-11-12  2:17           ` Sergey Senozhatsky
2019-11-12  2:17             ` Sergey Senozhatsky
2019-11-12  2:17             ` Sergey Senozhatsky
2019-11-12  2:17             ` [OpenRISC] " Sergey Senozhatsky
2019-11-12  2:17             ` Sergey Senozhatsky
2019-11-12  2:17             ` Sergey Senozhatsky
2019-11-12  2:40             ` Dmitry Safonov
2019-11-12  2:40               ` Dmitry Safonov
2019-11-12  2:40               ` Dmitry Safonov
2019-11-12  2:40               ` [OpenRISC] " Dmitry Safonov
2019-11-12  2:40               ` Dmitry Safonov
2019-11-12  2:40               ` Dmitry Safonov
2019-11-12  4:25               ` Sergey Senozhatsky
2019-11-12  4:25                 ` Sergey Senozhatsky
2019-11-12  4:25                 ` Sergey Senozhatsky
2019-11-12  4:25                 ` [OpenRISC] " Sergey Senozhatsky
2019-11-12  4:25                 ` Sergey Senozhatsky
2019-11-12  4:25                 ` Sergey Senozhatsky
2019-11-13  2:41                 ` Dmitry Safonov
2019-11-13  2:41                   ` Dmitry Safonov
2019-11-13  2:41                   ` Dmitry Safonov
2019-11-13  2:41                   ` [OpenRISC] " Dmitry Safonov
2019-11-13  2:41                   ` Dmitry Safonov
2019-11-13  2:41                   ` Dmitry Safonov
2019-11-13  2:51                   ` Sergey Senozhatsky
2019-11-13  2:51                     ` Sergey Senozhatsky
2019-11-13  2:51                     ` Sergey Senozhatsky
2019-11-13  2:51                     ` [OpenRISC] " Sergey Senozhatsky
2019-11-13  2:51                     ` Sergey Senozhatsky
2019-11-13  2:51                     ` Sergey Senozhatsky
2019-11-13 15:39             ` Steven Rostedt
2019-11-13 15:39               ` Steven Rostedt
2019-11-13 15:39               ` Steven Rostedt
2019-11-13 15:39               ` [OpenRISC] " Steven Rostedt
2019-11-13 15:39               ` Steven Rostedt
2019-11-13 15:39               ` Steven Rostedt
2019-11-15  3:36               ` Sergey Senozhatsky
2019-11-15  3:36                 ` Sergey Senozhatsky
2019-11-15  3:36                 ` Sergey Senozhatsky
2019-11-15  3:36                 ` [OpenRISC] " Sergey Senozhatsky
2019-11-15  3:36                 ` Sergey Senozhatsky
2019-11-15  3:36                 ` Sergey Senozhatsky
2019-11-06  9:20 ` Peter Zijlstra
2019-11-06  9:20   ` Peter Zijlstra
2019-11-06  9:20   ` Peter Zijlstra
2019-11-06  9:20   ` [OpenRISC] " Peter Zijlstra
2019-11-06  9:20   ` Peter Zijlstra
2019-11-06  9:20   ` Peter Zijlstra
2019-11-06 16:27   ` Dmitry Safonov
2019-11-06 16:27     ` Dmitry Safonov
2019-11-06 16:27     ` Dmitry Safonov
2019-11-06 16:27     ` [OpenRISC] " Dmitry Safonov
2019-11-06 16:27     ` Dmitry Safonov
2019-11-06 16:27     ` Dmitry Safonov
2019-11-06 20:34     ` Peter Zijlstra
2019-11-06 20:34       ` Peter Zijlstra
2019-11-06 20:34       ` Peter Zijlstra
2019-11-06 20:34       ` [OpenRISC] " Peter Zijlstra
2019-11-06 20:34       ` Peter Zijlstra
2019-11-06 20:34       ` Peter Zijlstra
2019-11-06 23:25       ` Russell King - ARM Linux admin
2019-11-06 23:25         ` Russell King - ARM Linux admin
2019-11-06 23:25         ` Russell King - ARM Linux admin
2019-11-06 23:25         ` [OpenRISC] " Russell King - ARM Linux admin
2019-11-06 23:25         ` Russell King - ARM Linux admin
2019-11-06 23:25         ` Russell King - ARM Linux admin
2019-11-07  7:27         ` Geert Uytterhoeven
2019-11-13 15:44         ` Steven Rostedt
2019-11-13 15:44           ` Steven Rostedt
2019-11-13 15:44           ` Steven Rostedt
2019-11-13 15:44           ` [OpenRISC] " Steven Rostedt
2019-11-13 15:44           ` Steven Rostedt
2019-11-13 15:44           ` Steven Rostedt
2019-11-08 16:28       ` Dmitry Safonov
2019-11-08 16:28         ` Dmitry Safonov
2019-11-08 16:28         ` Dmitry Safonov
2019-11-08 16:28         ` [OpenRISC] " Dmitry Safonov
2019-11-08 16:28         ` Dmitry Safonov
2019-11-08 16:28         ` Dmitry Safonov
2019-11-08 17:30         ` Russell King - ARM Linux admin
2019-11-08 17:30           ` Russell King - ARM Linux admin
2019-11-08 17:30           ` Russell King - ARM Linux admin
2019-11-08 17:30           ` [OpenRISC] " Russell King - ARM Linux admin
2019-11-08 17:30           ` Russell King - ARM Linux admin
2019-11-08 17:30           ` Russell King - ARM Linux admin
2019-11-08 21:08           ` Dmitry Safonov
2019-11-08 21:08             ` Dmitry Safonov
2019-11-08 21:08             ` Dmitry Safonov
2019-11-08 21:08             ` [OpenRISC] " Dmitry Safonov
2019-11-08 21:08             ` Dmitry Safonov
2019-11-08 21:08             ` Dmitry Safonov
2019-11-13 15:41       ` Steven Rostedt
2019-11-13 15:41         ` Steven Rostedt
2019-11-13 15:41         ` Steven Rostedt
2019-11-13 15:41         ` [OpenRISC] " Steven Rostedt
2019-11-13 15:41         ` Steven Rostedt
2019-11-13 15:41         ` Steven Rostedt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.