1. 09 Jun, 2020 11 commits
    • Dmitry Safonov's avatar
      c6x: add show_stack_loglvl() · a1eea2ef
      Dmitry Safonov authored
      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().
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com>
      Cc: Mark Salter <msalter@redhat.com>
      Link: http://lkml.kernel.org/r/20200418201944.482088-12-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a1eea2ef
    • Dmitry Safonov's avatar
      arm64: add show_stack_loglvl() · c0fe096a
      Dmitry Safonov authored
      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().
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/20200418201944.482088-11-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c0fe096a
    • Dmitry Safonov's avatar
      arm64: add loglvl to dump_backtrace() · c7689837
      Dmitry Safonov authored
      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().
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/20200418201944.482088-10-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c7689837
    • Dmitry Safonov's avatar
      arm: add show_stack_loglvl() · a4502d04
      Dmitry Safonov authored
      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().
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/20200418201944.482088-9-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a4502d04
    • Dmitry Safonov's avatar
      arm: wire up dump_backtrace_{entry,stm} · 34135eac
      Dmitry Safonov authored
      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.
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/20200418201944.482088-8-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      34135eac
    • Dmitry Safonov's avatar
      arm: add loglvl to dump_backtrace() · ee65ca01
      Dmitry Safonov authored
      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.
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/20200418201944.482088-7-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ee65ca01
    • Dmitry Safonov's avatar
      arm: add loglvl to unwind_backtrace() · e8d7b735
      Dmitry Safonov authored
      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.
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/20200418201944.482088-6-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e8d7b735
    • Dmitry Safonov's avatar
      arm/asm: add loglvl to c_backtrace() · 5489ab50
      Dmitry Safonov authored
      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().
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/20200418201944.482088-5-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5489ab50
    • Dmitry Safonov's avatar
      arc: add show_stack_loglvl() · 8ca4d199
      Dmitry Safonov authored
      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.
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Link: http://lkml.kernel.org/r/20200418201944.482088-4-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8ca4d199
    • Dmitry Safonov's avatar
      alpha: add show_stack_loglvl() · 8c49a909
      Dmitry Safonov authored
      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().
      
      [1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#uSigned-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Link: http://lkml.kernel.org/r/20200418201944.482088-3-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8c49a909
    • Dmitry Safonov's avatar
      kallsyms/printk: add loglvl to print_ip_sym() · 2062a4e8
      Dmitry Safonov authored
      Patch series "Add log level to show_stack()", v3.
      
      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:
      
      - It's a design mistake to move a business-logic decision into platform
        realization detail.
      
      - 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).
      
      - 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).
      
      - 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.
      
      See also discussion on v1:
      https://lore.kernel.org/linux-riscv/20191106083538.z5nlpuf64cigxigh@pathway.suse.cz/
      
      This patch (of 50):
      
      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.
      Signed-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Acked-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      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: 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: Dmitry Safonov <0x7f454c46@gmail.com>
      Cc: Dmitry Safonov <dima@arista.com>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Guo Ren <guoren@kernel.org>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Brian Cain <bcain@codeaurora.org>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Rich Felker <dalias@libc.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Guan Xuetao <gxt@pku.edu.cn>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Douglas Anderson <dianders@chromium.org>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20200418201944.482088-2-dima@arista.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2062a4e8
  2. 08 Jun, 2020 29 commits