1. 09 7月, 2018 1 次提交
    • P
      printk/nmi: Prevent deadlock when accessing the main log buffer in NMI · 03fc7f9c
      Petr Mladek 提交于
      The commit 719f6a70 ("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: 719f6a70 ("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 <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org
      Acked-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      03fc7f9c
  2. 19 5月, 2017 1 次提交
    • P
      printk: Use the main logbuf in NMI when logbuf_lock is available · 719f6a70
      Petr Mladek 提交于
      The commit 42a0bb3f ("printk/nmi: generic solution for safe
      printk in NMI") caused that printk stores messages into a temporary
      buffer in NMI context.
      
      The buffer is per-CPU and therefore the size is rather limited.
      It works quite well for NMI backtraces. But there are longer logs
      that might get printed in NMI context, for example, lockdep
      warnings, ftrace_dump_on_oops.
      
      The temporary buffer is used to avoid deadlocks caused by
      logbuf_lock. Also it is needed to avoid races with the other
      temporary buffer that is used when PRINTK_SAFE_CONTEXT is entered.
      But the main buffer can be used in NMI if the lock is available
      and we did not interrupt PRINTK_SAFE_CONTEXT.
      
      The lock is checked using raw_spin_is_locked(). It might cause
      false negatives when the lock is taken on another CPU and
      this CPU is in the safe context from other reasons. Note that
      the safe context is used also to get console semaphore or when
      calling console drivers. For this reason, we do the check in
      printk_nmi_enter(). It makes the handling consistent for
      the entire NMI handler and avoids reshuffling of the messages.
      
      The patch also defines special printk context that allows
      to use printk_deferred() in NMI. Note that we could not flush
      the messages to the consoles because console drivers might use
      many other internal locks.
      
      The newly created vprintk_deferred() disables the preemption
      only around the irq work handling. It is needed there to keep
      the consistency between the two per-CPU variables. But there
      is no reason to disable preemption around vprintk_emit().
      
      Finally, the patch puts back explicit serialization of the NMI
      backtraces from different CPUs. It was removed by the
      commit a9edc880 ("x86/nmi: Perform a safe
      NMI stack trace on all CPUs"). It was not needed because
      the flushing of the temporary per-CPU buffers was serialized.
      
      Link: http://lkml.kernel.org/r/1493912763-24873-1-git-send-email-pmladek@suse.com
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rack+kernel@arm.linux.org.uk>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: x86@kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Suggested-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Acked-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      719f6a70
  3. 08 2月, 2017 2 次提交
    • S
      printk: report lost messages in printk safe/nmi contexts · ddb9baa8
      Sergey Senozhatsky 提交于
      Account lost messages in pritk-safe and printk-safe-nmi
      contexts and report those numbers during printk_safe_flush().
      
      The patch also moves lost message counter to struct
      `printk_safe_seq_buf' instead of having dedicated static
      counters - this simplifies the code.
      
      Link: http://lkml.kernel.org/r/20161227141611.940-6-sergey.senozhatsky@gmail.com
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Calvin Owens <calvinowens@fb.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      ddb9baa8
    • S
      printk: introduce per-cpu safe_print seq buffer · 099f1c84
      Sergey Senozhatsky 提交于
      This patch extends the idea of NMI per-cpu buffers to regions
      that may cause recursive printk() calls and possible deadlocks.
      Namely, printk() can't handle printk calls from schedule code
      or printk() calls from lock debugging code (spin_dump() for instance);
      because those may be called with `sem->lock' already taken or any
      other `critical' locks (p->pi_lock, etc.). An example of deadlock
      can be
      
       vprintk_emit()
        console_unlock()
         up()                        << raw_spin_lock_irqsave(&sem->lock, flags);
          wake_up_process()
           try_to_wake_up()
            ttwu_queue()
             ttwu_activate()
              activate_task()
               enqueue_task()
                enqueue_task_fair()
                 cfs_rq_of()
                  task_of()
                   WARN_ON_ONCE(!entity_is_task(se))
                    vprintk_emit()
                     console_trylock()
                      down_trylock()
                       raw_spin_lock_irqsave(&sem->lock, flags)
                       ^^^^ deadlock
      
      and some other cases.
      
      Just like in NMI implementation, the solution uses a per-cpu
      `printk_func' pointer to 'redirect' printk() calls to a 'safe'
      callback, that store messages in a per-cpu buffer and flushes
      them back to logbuf buffer later.
      
      Usage example:
      
       printk()
        printk_safe_enter_irqsave(flags)
        //
        //  any printk() call from here will endup in vprintk_safe(),
        //  that stores messages in a special per-CPU buffer.
        //
        printk_safe_exit_irqrestore(flags)
      
      The 'redirection' mechanism, though, has been reworked, as suggested
      by Petr Mladek. Instead of using a per-cpu @print_func callback we now
      keep a per-cpu printk-context variable and call either default or nmi
      vprintk function depending on its value. printk_nmi_entrer/exit and
      printk_safe_enter/exit, thus, just set/celar corresponding bits in
      printk-context functions.
      
      The patch only adds printk_safe support, we don't use it yet.
      
      Link: http://lkml.kernel.org/r/20161227141611.940-4-sergey.senozhatsky@gmail.com
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Calvin Owens <calvinowens@fb.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Reviewed-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      099f1c84
  4. 10 8月, 2016 1 次提交
    • L
      Revert "printk: create pr_<level> functions" · a0cba217
      Linus Torvalds 提交于
      This reverts commit 874f9c7d.
      
      Geert Uytterhoeven reports:
       "This change seems to have an (unintendent?) side-effect.
      
        Before, pr_*() calls without a trailing newline characters would be
        printed with a newline character appended, both on the console and in
        the output of the dmesg command.
      
        After this commit, no new line character is appended, and the output
        of the next pr_*() call of the same type may be appended, like in:
      
          - Truncating RAM at 0x0000000040000000-0x00000000c0000000 to -0x0000000070000000
          - Ignoring RAM at 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)
          + Truncating RAM at 0x0000000040000000-0x00000000c0000000 to -0x0000000070000000Ignoring RAM at 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)"
      
      Joe Perches says:
       "No, that is not intentional.
      
        The newline handling code inside vprintk_emit is a bit involved and
        for now I suggest a revert until this has all the same behavior as
        earlier"
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Requested-by: NJoe Perches <joe@perches.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a0cba217
  5. 03 8月, 2016 1 次提交
  6. 21 5月, 2016 3 次提交
    • P
      printk/nmi: flush NMI messages on the system panic · cf9b1106
      Petr Mladek 提交于
      In NMI context, printk() messages are stored into per-CPU buffers to
      avoid a possible deadlock.  They are normally flushed to the main ring
      buffer via an IRQ work.  But the work is never called when the system
      calls panic() in the very same NMI handler.
      
      This patch tries to flush NMI buffers before the crash dump is
      generated.  In this case it does not risk a double release and bails out
      when the logbuf_lock is already taken.  The aim is to get the messages
      into the main ring buffer when possible.  It makes them better
      accessible in the vmcore.
      
      Then the patch tries to flush the buffers second time when other CPUs
      are down.  It might be more aggressive and reset logbuf_lock.  The aim
      is to get the messages available for the consequent kmsg_dump() and
      console_flush_on_panic() calls.
      
      The patch causes vprintk_emit() to be called even in NMI context again.
      But it is done via printk_deferred() so that the console handling is
      skipped.  Consoles use internal locks and we could not prevent a
      deadlock easily.  They are explicitly called later when the crash dump
      is not generated, see console_flush_on_panic().
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cf9b1106
    • P
      printk/nmi: warn when some message has been lost in NMI context · b522deab
      Petr Mladek 提交于
      We could not resize the temporary buffer in NMI context.  Let's warn if
      a message is lost.
      
      This is rather theoretical.  printk() should not be used in NMI.  The
      only sensible use is when we want to print backtrace from all CPUs.  The
      current buffer should be enough for this purpose.
      
      [akpm@linux-foundation.org: whitespace fixlet]
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Jiri Kosina <jkosina@suse.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b522deab
    • P
      printk/nmi: generic solution for safe printk in NMI · 42a0bb3f
      Petr Mladek 提交于
      printk() takes some locks and could not be used a safe way in NMI
      context.
      
      The chance of a deadlock is real especially when printing stacks from
      all CPUs.  This particular problem has been addressed on x86 by the
      commit a9edc880 ("x86/nmi: Perform a safe NMI stack trace on all
      CPUs").
      
      The patchset brings two big advantages.  First, it makes the NMI
      backtraces safe on all architectures for free.  Second, it makes all NMI
      messages almost safe on all architectures (the temporary buffer is
      limited.  We still should keep the number of messages in NMI context at
      minimum).
      
      Note that there already are several messages printed in NMI context:
      WARN_ON(in_nmi()), BUG_ON(in_nmi()), anything being printed out from MCE
      handlers.  These are not easy to avoid.
      
      This patch reuses most of the code and makes it generic.  It is useful
      for all messages and architectures that support NMI.
      
      The alternative printk_func is set when entering and is reseted when
      leaving NMI context.  It queues IRQ work to copy the messages into the
      main ring buffer in a safe context.
      
      __printk_nmi_flush() copies all available messages and reset the buffer.
      Then we could use a simple cmpxchg operations to get synchronized with
      writers.  There is also used a spinlock to get synchronized with other
      flushers.
      
      We do not longer use seq_buf because it depends on external lock.  It
      would be hard to make all supported operations safe for a lockless use.
      It would be confusing and error prone to make only some operations safe.
      
      The code is put into separate printk/nmi.c as suggested by Steven
      Rostedt.  It needs a per-CPU buffer and is compiled only on
      architectures that call nmi_enter().  This is achieved by the new
      HAVE_NMI Kconfig flag.
      
      The are MN10300 and Xtensa architectures.  We need to clean up NMI
      handling there first.  Let's do it separately.
      
      The patch is heavily based on the draft from Peter Zijlstra, see
      
        https://lkml.org/lkml/2015/6/10/327
      
      [arnd@arndb.de: printk-nmi: use %zu format string for size_t]
      [akpm@linux-foundation.org: min_t->min - all types are size_t here]
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Suggested-by: NPeter Zijlstra <peterz@infradead.org>
      Suggested-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Jan Kara <jack@suse.cz>
      Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>	[arm part]
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Cc: Jiri Kosina <jkosina@suse.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Daniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42a0bb3f