user/sven/linux.git/include/linux/printk.h, branch v5.1.14

Merge tag 'printk-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk

2019-03-09T17:22:42Z

Pull printk updates from Petr Mladek: - Allow to sort mixed lines by an extra information about the caller - Remove no longer used LOG_PREFIX. - Some clean up and documentation update. * tag 'printk-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk: printk/docs: Add extra integer types to printk-formats printk: Remove no longer used LOG_PREFIX. lib/vsprintf: Remove %pCr remnant in comment printk: Pass caller information to log_store(). printk: Add caller information to printk() output.

linux/printk.h: use DYNAMIC_DEBUG_BRANCH in pr_debug_ratelimited

2019-03-08T02:32:00Z

pr_debug_ratelimited tests the dynamic debug descriptor the old-fashioned way, and doesn't utilize the static key/jump label implementation when CONFIG_JUMP_LABEL is set. Use the DYNAMIC_DEBUG_BRANCH which is defined appropriately. Link: http://lkml.kernel.org/r/20190212214150.4807-4-linux@rasmusvillemoes.dk Signed-off-by: Rasmus Villemoes Acked-by: Petr Mladek Acked-by: Jason Baron Cc: Steven Rostedt Cc: David Sterba Cc: Greg Kroah-Hartman Cc: Ingo Molnar Cc: "Rafael J . Wysocki" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

printk: Remove no longer used LOG_PREFIX.

2019-03-04T12:42:05Z

When commit 5becfb1df5ac8e49 ("kmsg: merge continuation records while printing") introduced LOG_PREFIX, we used KERN_DEFAULT etc. as a flag for setting LOG_PREFIX in order to tell whether to call cont_add() (i.e. whether to append the message to "struct cont"). But since commit 4bcc595ccd80decb ("printk: reinstate KERN_CONT for printing continuation lines") inverted the behavior (i.e. don't append the message to "struct cont" unless KERN_CONT is specified) and commit 5aa068ea4082b39e ("printk: remove games with previous record flags") removed the last LOG_PREFIX check, setting LOG_PREFIX via KERN_DEFAULT etc. is no longer meaningful. Therefore, we can remove LOG_PREFIX and make KERN_DEFAULT empty string. Link: http://lkml.kernel.org/r/1550829580-9189-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp To: Steven Rostedt To: Linus Torvalds Cc: linux-kernel@vger.kernel.org Cc: Tetsuo Handa Signed-off-by: Tetsuo Handa Reviewed-by: Sergey Senozhatsky Signed-off-by: Petr Mladek

include/linux/printk.h: drop silly "static inline asmlinkage" from dump_stack()

2019-01-04T21:13:46Z

Empty function will be inlined so asmlinkage doesn't do anything. Link: http://lkml.kernel.org/r/20181124093530.GE10969@avx2 Signed-off-by: Alexey Dobriyan Reviewed-by: Andrew Morton Acked-by: Joey Pabalinas Cc: Petr Mladek Cc: Sergey Senozhatsky Cc: Steven Rostedt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

printk: Make printk_emit() local function.

2018-11-29T09:59:40Z

printk_emit() is called from only devkmsg_write() in the same file. Save object size by making it a local function. Link: http://lkml.kernel.org/r/5cc99d2c-c408-34f7-d1fc-e1cd2a9e31da@i-love.sakura.ne.jp Cc: Steven Rostedt Signed-off-by: Tetsuo Handa Reviewed-by: Sergey Senozhatsky Signed-off-by: Petr Mladek

Merge branch 'for-4.19-nmi' into for-linus

2018-08-14T11:36:15Z

printk/nmi: Prevent deadlock when accessing the main log buffer in NMI

2018-07-09T12:10:40Z

The commit 719f6a7040f1bdaf96 ("printk: Use the main logbuf in NMI when logbuf_lock is available") brought back the possible deadlocks in printk() and NMI. The check of logbuf_lock is done only in printk_nmi_enter() to prevent mixed output. But another CPU might take the lock later, enter NMI, and: + Both NMIs might be serialized by yet another lock, for example, the one in nmi_cpu_backtrace(). + The other CPU might get stopped in NMI, see smp_send_stop() in panic(). The only safe solution is to use trylock when storing the message into the main log-buffer. It might cause reordering when some lines go to the main lock buffer directly and others are delayed via the per-CPU buffer. It means that it is not useful in general. This patch replaces the problematic NMI deferred context with NMI direct context. It can be used to mark a code that might produce many messages in NMI and the risk of losing them is more critical than problems with eventual reordering. The context is then used when dumping trace buffers on oops. It was the primary motivation for the original fix. Also the reordering is even smaller issue there because some traces have their own time stamps. Finally, nmi_cpu_backtrace() need not longer be serialized because it will always us the per-CPU buffers again. Fixes: 719f6a7040f1bdaf96 ("printk: Use the main logbuf in NMI when logbuf_lock is available") Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20180627142028.11259-1-pmladek@suse.com To: Steven Rostedt Cc: Peter Zijlstra Cc: Tetsuo Handa Cc: Sergey Senozhatsky Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Acked-by: Sergey Senozhatsky Signed-off-by: Petr Mladek

printk: Make CONSOLE_LOGLEVEL_QUIET configurable

2018-06-27T14:14:29Z

The goal of passing the "quiet" option to the kernel is for the kernel to be quiet unless something really is wrong. Sofar passing quiet has been (mostly) equivalent to passing loglevel=4 on the kernel commandline. Which means to show any messages with a level of KERN_ERR or higher severity on the console. In practice this often does not result in a quiet boot though, since there are many false-positive or otherwise harmless error messages printed, defeating the purpose of the quiet option. Esp. the ACPICA code is really bad wrt this, but there are plenty of others too. This commit makes CONSOLE_LOGLEVEL_QUIET configurable. This for example will allow distros which want quiet to really mean quiet to set CONSOLE_LOGLEVEL_QUIET so that only messages with a higher severity then KERN_ERR (CRIT, ALERT, EMERG) get printed, avoiding an endless game of whack-a-mole silencing harmless error messages. Link: http://lkml.kernel.org/r/20180619115726.3098-1-hdegoede@redhat.com To: Petr Mladek To: Sergey Senozhatsky Cc: Hans de Goede Cc: Steven Rostedt Cc: linux-kernel@vger.kernel.org Signed-off-by: Hans de Goede Acked-by: Steven Rostedt (VMware) Reviewed-by: Sergey Senozhatsky Signed-off-by: Petr Mladek

printk: move dump stack related code to lib/dump_stack.c

2018-03-15T12:25:36Z

dump_stack related stuff should belong to lib/dump_stack.c thus move them there. Also conditionally compile lib/dump_stack.c since dump_stack code does not make sense if printk is disabled. Link: http://lkml.kernel.org/r/20180213072834.GA24784@dhcp-128-65.nay.redhat.com To: Steven Rostedt Cc: linux-kernel@vger.kernel.org Cc: akpm@linux-foundation.org Cc: Andi Kleen Signed-off-by: Dave Young Suggested-by: Steven Rostedt Suggested-by: Sergey Senozhatsky Reviewed-by: Sergey Senozhatsky Signed-off-by: Petr Mladek

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk

2017-11-21T15:28:13Z

Pull printk updates from Petr Mladek: - print the warning about dropped messages on consoles on a separate line. It makes it more legible. - one typo fix and small code clean up. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk: added new line symbol after warning about dropped messages printk: fix typo in printk_safe.c printk: simplify no_printk()