1. 13 8月, 2014 1 次提交
  2. 07 8月, 2014 11 次提交
    • N
      kernel/printk/printk.c: fix bool assignements · d25d9fec
      Neil Zhang 提交于
      Fix coccinelle warnings.
      Signed-off-by: NNeil Zhang <zhangwm@marvell.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d25d9fec
    • J
      printk: enable interrupts before calling console_trylock_for_printk() · 5874af20
      Jan Kara 提交于
      We need interrupts disabled when calling console_trylock_for_printk()
      only so that cpu id we pass to can_use_console() remains valid (for
      other things console_sem provides all the exclusion we need and
      deadlocks on console_sem due to interrupts are impossible because we use
      down_trylock()).  However if we are rescheduled, we are guaranteed to
      run on an online cpu so we can easily just get the cpu id in
      can_use_console().
      
      We can lose a bit of performance when we enable interrupts in
      vprintk_emit() and then disable them again in console_unlock() but OTOH
      it can somewhat reduce interrupt latency caused by console_unlock().
      
      We differ from (reverted) commit 939f04be in that we avoid calling
      console_unlock() from vprintk_emit() with lockdep enabled as that has
      unveiled quite some bugs leading to system freezes during boot (e.g.
        https://lkml.org/lkml/2014/5/30/242,
        https://lkml.org/lkml/2014/6/28/521).
      Signed-off-by: NJan Kara <jack@suse.cz>
      Tested-by: NAndreas Bombe <aeb@debian.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5874af20
    • A
      printk: miscellaneous cleanups · 249771b8
      Alex Elder 提交于
      Some small cleanups to kernel/printk/printk.c.  None of them should
      cause any change in behavior.
      
        - When CONFIG_PRINTK is defined, parenthesize the value of LOG_LINE_MAX.
        - When CONFIG_PRINTK is *not* defined, there is an extra LOG_LINE_MAX
          definition; delete it.
        - Pull an assignment out of a conditional expression in console_setup().
        - Use isdigit() in console_setup() rather than open coding it.
        - In update_console_cmdline(), drop a NUL-termination assignment;
          the strlcpy() call that precedes it guarantees it's not needed.
        - Simplify some logic in printk_timed_ratelimit().
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Reviewed-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Jan Kara <jack@suse.cz>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      249771b8
    • A
      printk: use a clever macro · e99aa461
      Alex Elder 提交于
      Use the IS_ENABLED() macro rather than #ifdef blocks to set certain
      global values.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e99aa461
    • A
      printk: fix some comments · 0b90fec3
      Alex Elder 提交于
      Fix a few comments that don't accurately describe their corresponding
      code.  It also fixes some minor typographical errors.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Reviewed-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Jan Kara <jack@suse.cz>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b90fec3
    • A
      printk: rename DEFAULT_MESSAGE_LOGLEVEL · 42a9dc0b
      Alex Elder 提交于
      Commit a8fe19eb ("kernel/printk: use symbolic defines for console
      loglevels") makes consistent use of symbolic values for printk() log
      levels.
      
      The naming scheme used is different from the one used for
      DEFAULT_MESSAGE_LOGLEVEL though.  Change that symbol name to be
      MESSAGE_LOGLEVEL_DEFAULT for consistency.  And because the value of that
      symbol comes from a similarly-named config option, rename
      CONFIG_DEFAULT_MESSAGE_LOGLEVEL as well.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Jan Kara <jack@suse.cz>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      42a9dc0b
    • A
      printk: tweak do_syslog() to match comments · e97e1267
      Alex Elder 提交于
      In do_syslog() there's a path used by kmsg_poll() and kmsg_read() that
      only needs to know whether there's any data available to read (and not
      its size).  These callers only check for non-zero return.  As a
      shortcut, do_syslog() returns the difference between what has been
      logged and what has been "seen."
      
      The comments say that the "count of records" should be returned but it's
      not.  Instead it returns (log_next_idx - syslog_idx), which is a
      difference between buffer offsets--and the result could be negative.
      
      The behavior is the same (it'll be zero or not in the same cases), but
      the count of records is more meaningful and it matches what the comments
      say.  So change the code to return that.
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e97e1267
    • L
      printk: allow increasing the ring buffer depending on the number of CPUs · 23b2899f
      Luis R. Rodriguez 提交于
      The default size of the ring buffer is too small for machines with a
      large amount of CPUs under heavy load.  What ends up happening when
      debugging is the ring buffer overlaps and chews up old messages making
      debugging impossible unless the size is passed as a kernel parameter.
      An idle system upon boot up will on average spew out only about one or
      two extra lines but where this really matters is on heavy load and that
      will vary widely depending on the system and environment.
      
      There are mechanisms to help increase the kernel ring buffer for tracing
      through debugfs, and those interfaces even allow growing the kernel ring
      buffer per CPU.  We also have a static value which can be passed upon
      boot.  Relying on debugfs however is not ideal for production, and
      relying on the value passed upon bootup is can only used *after* an
      issue has creeped up.  Instead of being reactive this adds a proactive
      measure which lets you scale the amount of contributions you'd expect to
      the kernel ring buffer under load by each CPU in the worst case
      scenario.
      
      We use num_possible_cpus() to avoid complexities which could be
      introduced by dynamically changing the ring buffer size at run time,
      num_possible_cpus() lets us use the upper limit on possible number of
      CPUs therefore avoiding having to deal with hotplugging CPUs on and off.
      This introduces the kernel configuration option LOG_CPU_MAX_BUF_SHIFT
      which is used to specify the maximum amount of contributions to the
      kernel ring buffer in the worst case before the kernel ring buffer flips
      over, the size is specified as a power of 2.  The total amount of
      contributions made by each CPU must be greater than half of the default
      kernel ring buffer size (1 << LOG_BUF_SHIFT bytes) in order to trigger
      an increase upon bootup.  The kernel ring buffer is increased to the
      next power of two that would fit the required minimum kernel ring buffer
      size plus the additional CPU contribution.  For example if LOG_BUF_SHIFT
      is 18 (256 KB) you'd require at least 128 KB contributions by other CPUs
      in order to trigger an increase of the kernel ring buffer.  With a
      LOG_CPU_BUF_SHIFT of 12 (4 KB) you'd require at least anything over > 64
      possible CPUs to trigger an increase.  If you had 128 possible CPUs the
      amount of minimum required kernel ring buffer bumps to:
      
         ((1 << 18) + ((128 - 1) * (1 << 12))) / 1024 = 764 KB
      
      Since we require the ring buffer to be a power of two the new required
      size would be 1024 KB.
      
      This CPU contributions are ignored when the "log_buf_len" kernel
      parameter is used as it forces the exact size of the ring buffer to an
      expected power of two value.
      
      [pmladek@suse.cz: fix build]
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Tested-by: NDavidlohr Bueso <davidlohr@hp.com>
      Tested-by: NPetr Mladek <pmladek@suse.cz>
      Reviewed-by: NDavidlohr Bueso <davidlohr@hp.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Arun KS <arunks.linux@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      23b2899f
    • L
      printk: make dynamic units clear for the kernel ring buffer · f5405172
      Luis R. Rodriguez 提交于
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Suggested-by: NDavidlohr Bueso <davidlohr@hp.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Arun KS <arunks.linux@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f5405172
    • L
      printk: move power of 2 practice of ring buffer size to a helper · c0a318a3
      Luis R. Rodriguez 提交于
      In practice the power of 2 practice of the size of the kernel ring
      buffer remains purely historical but not a requirement, specially now
      that we have LOG_ALIGN and use it for both static and dynamic
      allocations.  It could have helped with implicit alignment back in the
      days given the even the dynamically sized ring buffer was guaranteed to
      be aligned so long as CONFIG_LOG_BUF_SHIFT was set to produce a
      __LOG_BUF_LEN which is architecture aligned, since log_buf_len=n would
      be allowed only if it was > __LOG_BUF_LEN and we always ended up
      rounding the log_buf_len=n to the next power of 2 with
      roundup_pow_of_two(), any multiple of 2 then should be also architecture
      aligned.  These assumptions of course relied heavily on
      CONFIG_LOG_BUF_SHIFT producing an aligned value but users can always
      change this.
      
      We now have precise alignment requirements set for the log buffer size
      for both static and dynamic allocations, but lets upkeep the old
      practice of using powers of 2 for its size to help with easy expected
      scalable values and the allocators for dynamic allocations.  We'll reuse
      this later so move this into a helper.
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Arun KS <arunks.linux@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c0a318a3
    • L
      printk: make dynamic kernel ring buffer alignment explicit · 70300177
      Luis R. Rodriguez 提交于
      We have to consider alignment for the ring buffer both for the default
      static size, and then also for when an dynamic allocation is made when
      the log_buf_len=n kernel parameter is passed to set the size
      specifically to a size larger than the default size set by the
      architecture through CONFIG_LOG_BUF_SHIFT.
      
      The default static kernel ring buffer can be aligned properly if
      architectures set CONFIG_LOG_BUF_SHIFT properly, we provide ranges for
      the size though so even if CONFIG_LOG_BUF_SHIFT has a sensible aligned
      value it can be reduced to a non aligned value.  Commit 6ebb017d
      ("printk: Fix alignment of buf causing crash on ARM EABI") by Andrew
      Lunn ensures the static buffer is always aligned and the decision of
      alignment is done by the compiler by using __alignof__(struct log).
      
      When log_buf_len=n is used we allocate the ring buffer dynamically.
      Dynamic allocation varies, for the early allocation called before
      setup_arch() memblock_virt_alloc() requests a page aligment and for the
      default kernel allocation memblock_virt_alloc_nopanic() requests no
      special alignment, which in turn ends up aligning the allocation to
      SMP_CACHE_BYTES, which is L1 cache aligned.
      
      Since we already have the required alignment for the kernel ring buffer
      though we can do better and request explicit alignment for LOG_ALIGN.
      This does that to be safe and make dynamic allocation alignment
      explicit.
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Tested-by: NPetr Mladek <pmladek@suse.cz>
      Acked-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Arun KS <arunks.linux@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      70300177
  3. 04 7月, 2014 1 次提交
  4. 05 6月, 2014 14 次提交
    • B
      kernel/printk: use symbolic defines for console loglevels · a8fe19eb
      Borislav Petkov 提交于
      ... instead of naked numbers.
      
      Stuff in sysrq.c used to set it to 8 which is supposed to mean above
      default level so set it to DEBUG instead as we're terminating/killing all
      tasks and we want to be verbose there.
      
      Also, correct the check in x86_64_start_kernel which should be >= as
      we're clearly issuing the string there for all debug levels, not only
      the magical 10.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NKees Cook <keescook@chromium.org>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a8fe19eb
    • W
      printk: report dropping of messages from logbuf · 84b5ec8a
      Will Deacon 提交于
      If the log ring buffer becomes full, we silently overwrite old messages
      with new data.  console_unlock will detect this case and fast-forward the
      console_* pointers to skip over the corrupted data, but nothing will be
      reported to the user.
      
      This patch hijacks the first valid log message after detecting that we
      dropped messages and prefixes it with a note detailing how many messages
      were dropped.  For long (~1000 char) messages, this will result in some
      truncation of the real message, but given that we're dropping things
      anyway, that doesn't seem to be the end of the world.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Kay Sievers <kay@vrfy.org>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      84b5ec8a
    • J
      printk: rename printk_sched to printk_deferred · aac74dc4
      John Stultz 提交于
      After learning we'll need some sort of deferred printk functionality in
      the timekeeping core, Peter suggested we rename the printk_sched function
      so it can be reused by needed subsystems.
      
      This only changes the function name. No logic changes.
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jiri Bohac <jbohac@suse.cz>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      aac74dc4
    • J
      printk: disable preemption for printk_sched · 81954606
      John Stultz 提交于
      An earlier change in -mm (printk: remove separate printk_sched
      buffers...), removed the printk_sched irqsave/restore lines since it was
      safe for current users.  Since we may be expanding usage of
      printk_sched(), disable preepmtion for this function to make it more
      generally safe to call.
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Jiri Bohac <jbohac@suse.cz>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      81954606
    • S
      printk: remove separate printk_sched buffers and use printk buf instead · 458df9fd
      Steven Rostedt 提交于
      To prevent deadlocks with doing a printk inside the scheduler,
      printk_sched() was created.  The issue is that printk has a console_sem
      that it can grab and release.  The release does a wake up if there's a
      task pending on the sem, and this wake up grabs the rq locks that is
      held in the scheduler.  This leads to a possible deadlock if the wake up
      uses the same rq as the one with the rq lock held already.
      
      What printk_sched() does is to save the printk write in a per cpu buffer
      and sets the PRINTK_PENDING_SCHED flag.  On a timer tick, if this flag is
      set, the printk() is done against the buffer.
      
      There's a couple of issues with this approach.
      
      1) If two printk_sched()s are called before the tick, the second one
         will overwrite the first one.
      
      2) The temporary buffer is 512 bytes and is per cpu.  This is a quite a
         bit of space wasted for something that is seldom used.
      
      In order to remove this, the printk_sched() can use the printk buffer
      instead, and delay the console_trylock()/console_unlock() to the queued
      work.
      
      Because printk_sched() would then be taking the logbuf_lock, the
      logbuf_lock must not be held while doing anything that may call into the
      scheduler functions, which includes wake ups.  Unfortunately, printk()
      also has a console_sem that it uses, and on release, the up(&console_sem)
      may do a wake up of any pending waiters.  This must be avoided while
      holding the logbuf_lock.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      458df9fd
    • J
      printk: enable interrupts before calling console_trylock_for_printk() · 939f04be
      Jan Kara 提交于
      We need interrupts disabled when calling console_trylock_for_printk()
      only so that cpu id we pass to can_use_console() remains valid (for
      other things console_sem provides all the exclusion we need and
      deadlocks on console_sem due to interrupts are impossible because we use
      down_trylock()).  However if we are rescheduled, we are guaranteed to
      run on an online cpu so we can easily just get the cpu id in
      can_use_console().
      
      We can lose a bit of performance when we enable interrupts in
      vprintk_emit() and then disable them again in console_unlock() but OTOH
      it can somewhat reduce interrupt latency caused by console_unlock()
      especially since later in the patch series we will want to spin on
      console_sem in console_trylock_for_printk().
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      939f04be
    • J
      printk: fix lockdep instrumentation of console_sem · bd8d7cf5
      Jan Kara 提交于
      Printk calls mutex_acquire() / mutex_release() by hand to instrument
      lockdep about console_sem.  However in some corner cases the
      instrumentation is missing.  Fix the problem by creating helper functions
      for locking / unlocking console_sem which take care of lockdep
      instrumentation as well.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Reported-by: NFabio Estevam <festevam@gmail.com>
      Reported-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
      Tested-By: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bd8d7cf5
    • J
      printk: release lockbuf_lock before calling console_trylock_for_printk() · 608873ca
      Jan Kara 提交于
      There's no reason to hold lockbuf_lock when entering
      console_trylock_for_printk().
      
      The first thing this function does is to call down_trylock(console_sem)
      and if that fails it immediately unlocks lockbuf_lock.  So lockbuf_lock
      isn't needed for that branch.  When down_trylock() succeeds, the rest of
      console_trylock() is OK without lockbuf_lock (it is called without it
      from other places), and the only remaining thing in
      console_trylock_for_printk() is can_use_console() call.  For that call
      console_sem is enough (it iterates all consoles and checks CON_ANYTIME
      flag).
      
      So we drop logbuf_lock before entering console_trylock_for_printk() which
      simplifies the code.
      
      [akpm@linux-foundation.org: fix have_callable_console() comment]
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      608873ca
    • J
      printk: remove outdated comment · ca1d432a
      Jan Kara 提交于
      Comment about interesting interlocking between lockbuf_lock and
      console_sem is outdated.
      
      It was added in 2002 by commit a880f45a48be during conversion of
      console_lock to console_sem + lockbuf_lock.
      
      At that time release_console_sem() (today's equivalent is
      console_unlock()) was indeed using lockbuf_lock to avoid races between
      trylock on console_sem in printk() and unlock of console_sem.  However
      these days the interlocking is gone and the races are avoided by
      rechecking logbuf state after releasing console_sem.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ca1d432a
    • P
      printk: return really stored message length · 034633cc
      Petr Mladek 提交于
      I wonder if anyone uses printk return value but it is there and should be
      counted correctly.
      
      This patch modifies log_store() to return the number of really stored
      bytes from the 'text' part.  Also it handles the return value in
      vprintk_emit().
      
      Note that log_store() is used also in cont_flush() but we could ignore the
      return value there.  The function works with characters that were already
      counted earlier.  In addition, the store could newer fail here because the
      length of the printed text is limited by the "cont" buffer and "dict" is
      NULL.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      034633cc
    • P
      printk: shrink too long messages · 55bd53a4
      Petr Mladek 提交于
      We might want to print at least part of too long messages and add some
      warning for debugging purpose.
      
      The question is how long the shrunken message should be.  If we use the
      whole buffer, it might get rotated too soon.  Let's try to use only 1/4 of
      the buffer for now.
      
      Also shrink the whole dictionary.  We do not want to parse it or break it
      in the middle of some pair of values.  It would not cause any real harm
      but still.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      55bd53a4
    • P
      printk: split message size computation · 85c87043
      Petr Mladek 提交于
      We will want to recompute the message size when shrinking too long
      messages.  Let's put the code into separate function.
      
      The side effect of setting "pad_len" is not nice but it is worth removing
      the code duplication.  Note that I will probably have one more usage for
      this function when handling messages safe way in NMI context.
      
      This patch does not change the existing behavior.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      85c87043
    • P
      printk: ignore too long messages · f40e4b9f
      Petr Mladek 提交于
      There was no check for too long messages.  The check for free space always
      passed when first_seq and next_seq were equal.  Enough free space was not
      guaranteed, though.
      
      log_store() might be called to store messages up to 64kB + 64kB + 16B.
      This is sum of maximal text_len, dict_len values, and the size of the
      structure printk_log.
      
      On the other hand, the minimal size for the main log buffer currently is
      4kB and it is enforced only by Kconfig.
      
      The good news is that the usage looks safe right now.  log_store() is
      called only from vprintk_emit() and cont_flush().  Here the "text" part is
      always passed via a static buffer and the length is limited to
      LOG_LINE_MAX which is 1024.  The "dict" part is NULL in most cases.  The
      only exceptions is when vprintk_emit() is called from printk_emit() and
      dev_vprintk_emit().  But printk_emit() is currently used only in
      devkmsg_writev() and here "dict" is NULL as well.  In dev_vprintk_emit(),
      "dict" is limited by the static buffer "hdr" of the size 128 bytes.  It
      meas that the current maximal printed text is 1024B + 128B + 16B and it
      always fit the log buffer.
      
      But it is only matter of time when someone calls printk_emit() with unsafe
      parameters, especially the "dict" one.
      
      This patch adds a check for the free space when the buffer is empty.  It
      reuses the already existing log_has_space() function but it has to add an
      extra parameter.  It defines whether the buffer is empty.  Note that the
      same values of "first_idx" and "next_idx" might also mean that the buffer
      is full.
      
      If the buffer is empty, we must respect the current position of the
      indexes.  We cannot reset them to the beginning of the buffer.  Otherwise,
      the functions reading the buffer would get crazy.
      
      The question is what to do when the message is too long.  This patch uses
      the easiest solution and just ignores the problematic message.  Let's do
      something better in a followup patch.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f40e4b9f
    • P
      printk: split code for making free space in the log buffer · 0a581694
      Petr Mladek 提交于
      The check for free space in the log buffer always passes when "first_seq"
      and "next_seq" are equal.  In theory, it might cause writing outside of
      the log buffer.
      
      Fortunately, the current usage looks safe because the used "text" and
      "dict" buffers are quite limited.  See the second patch for more details.
      
      Anyway, it is better to be on the safe side and add a check.  An easy
      solution is done in the 2nd patch and it is improved in the 4th patch.
      
      5th patch fixes the computation of the printed message length.
      
      1st and 3rd patches just do some code refactoring to make the other
      patches easier.
      
      This patch (of 5):
      
      There will be needed some fixes in the check for free space.  They will be
      easier if the code is moved outside of the quite long log_store()
      function.
      
      This patch does not change the existing behavior.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0a581694
  5. 29 5月, 2014 1 次提交
    • S
      printk/of_serial: fix serial console cessation part way through boot. · 7fa21dd8
      Stephen Chivers 提交于
      Commit 5f5c9ae5
      "serial_core: Unregister console in uart_remove_one_port()"
      fixed a crash where a serial port was removed but
      not deregistered as a console.
      
      There is a side effect of that commit for platforms having serial consoles
      and of_serial configured (CONFIG_SERIAL_OF_PLATFORM). The serial console
      is disabled midway through the boot process.
      
      This cessation of the serial console affects PowerPC computers
      such as the MVME5100 and SAM440EP.
      
      The sequence is:
      
      	bootconsole [udbg0] enabled
      	....
      	serial8250/16550 driver initialises and registers its UARTS,
      	one of these is the serial console.
      	console [ttyS0] enabled
      	....
      	of_serial probes "platform" devices, registering them as it goes.
      	One of these is the serial console.
      	console [ttyS0] disabled.
      
      The disabling of the serial console is due to:
      
      	a.  unregister_console in printk not clearing the
      	    CONS_ENABLED bit in the console flags,
      	    even though it has announced that the console is disabled; and
      
      	b.  of_platform_serial_probe in of_serial not setting the port type
      	    before it registers with serial8250_register_8250_port.
      
      This patch ensures that the serial console is re-enabled when of_serial
      registers a serial port that corresponds to the designated console.
      Signed-off-by: NStephen Chivers <schivers@csc.com>
      Tested-by: NStephen Chivers <schivers@csc.com>
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [unregister_console]
      Cc: stable <stable@vger.kernel.org> # 3.15
      
      ===
      The above failure was identified in Linux-3.15-rc2.
      
      Tested using MVME5100 and SAM440EP PowerPC computers with
      kernels built from Linux-3.15-rc5 and tty-next.
      
      The continued operation of the serial console is vital for computers
      such as the MVME5100 as that Single Board Computer does not
      have any grapical/display hardware.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7fa21dd8
  6. 06 5月, 2014 1 次提交
  7. 04 4月, 2014 5 次提交
    • J
      printk: fix one circular lockdep warning about console_lock · 72581487
      Jane Li 提交于
      Fix a warning about possible circular locking dependency.
      
      If do in following sequence:
      
          enter suspend ->  resume ->  plug-out CPUx (echo 0 > cpux/online)
      
      lockdep will show warning as following:
      
        ======================================================
        [ INFO: possible circular locking dependency detected ]
        3.10.0 #2 Tainted: G           O
        -------------------------------------------------------
        sh/1271 is trying to acquire lock:
        (console_lock){+.+.+.}, at: console_cpu_notify+0x20/0x2c
        but task is already holding lock:
        (cpu_hotplug.lock){+.+.+.}, at: cpu_hotplug_begin+0x2c/0x58
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
        -> #2 (cpu_hotplug.lock){+.+.+.}:
          lock_acquire+0x98/0x12c
          mutex_lock_nested+0x50/0x3d8
          cpu_hotplug_begin+0x2c/0x58
          _cpu_up+0x24/0x154
          cpu_up+0x64/0x84
          smp_init+0x9c/0xd4
          kernel_init_freeable+0x78/0x1c8
          kernel_init+0x8/0xe4
          ret_from_fork+0x14/0x2c
      
        -> #1 (cpu_add_remove_lock){+.+.+.}:
          lock_acquire+0x98/0x12c
          mutex_lock_nested+0x50/0x3d8
          disable_nonboot_cpus+0x8/0xe8
          suspend_devices_and_enter+0x214/0x448
          pm_suspend+0x1e4/0x284
          try_to_suspend+0xa4/0xbc
          process_one_work+0x1c4/0x4fc
          worker_thread+0x138/0x37c
          kthread+0xa4/0xb0
          ret_from_fork+0x14/0x2c
      
        -> #0 (console_lock){+.+.+.}:
          __lock_acquire+0x1b38/0x1b80
          lock_acquire+0x98/0x12c
          console_lock+0x54/0x68
          console_cpu_notify+0x20/0x2c
          notifier_call_chain+0x44/0x84
          __cpu_notify+0x2c/0x48
          cpu_notify_nofail+0x8/0x14
          _cpu_down+0xf4/0x258
          cpu_down+0x24/0x40
          store_online+0x30/0x74
          dev_attr_store+0x18/0x24
          sysfs_write_file+0x16c/0x19c
          vfs_write+0xb4/0x190
          SyS_write+0x3c/0x70
          ret_fast_syscall+0x0/0x48
      
        Chain exists of:
           console_lock --> cpu_add_remove_lock --> cpu_hotplug.lock
      
        Possible unsafe locking scenario:
               CPU0                    CPU1
               ----                    ----
        lock(cpu_hotplug.lock);
                                       lock(cpu_add_remove_lock);
                                       lock(cpu_hotplug.lock);
        lock(console_lock);
          *** DEADLOCK ***
      
      There are three locks involved in two sequence:
      a) pm suspend:
      	console_lock (@suspend_console())
      	cpu_add_remove_lock (@disable_nonboot_cpus())
      	cpu_hotplug.lock (@_cpu_down())
      b) Plug-out CPUx:
      	cpu_add_remove_lock (@(cpu_down())
      	cpu_hotplug.lock (@_cpu_down())
      	console_lock (@console_cpu_notify()) => Lockdeps prints warning log.
      
      There should be not real deadlock, as flag of console_suspended can
      protect this.
      
      Although console_suspend() releases console_sem, it doesn't tell lockdep
      about it.  That results in the lockdep warning about circular locking
      when doing the following: enter suspend -> resume -> plug-out CPUx (echo
      0 > cpux/online)
      
      Fix the problem by telling lockdep we actually released the semaphore in
      console_suspend() and acquired it again in console_resume().
      Signed-off-by: NJane Li <jiel@marvell.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72581487
    • P
      printk: do not compute the size of the message twice · fce6e033
      Petr Mladek 提交于
      This is just a tiny optimization.  It removes duplicate computation of
      the message size.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fce6e033
    • P
      printk: use also the last bytes in the ring buffer · 39b25109
      Petr Mladek 提交于
      It seems that we have newer used the last byte in the ring buffer.  In
      fact, we have newer used the last 4 bytes because of padding.
      
      First problem is in the check for free space.  The exact number of free
      bytes is enough to store the length of data.
      
      Second problem is in the check where the ring buffer is rotated.  The
      left side counts the first unused index.  It is unused, so it might be
      the same as the size of the buffer.
      
      Note that the first problem has to be fixed together with the second
      one.  Otherwise, the buffer is rotated even when there is enough space
      on the end of the buffer.  Then the beginning of the buffer is rewritten
      and valid entries get corrupted.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      39b25109
    • P
      printk: add comment about tricky check for text buffer size · e8c42d36
      Petr Mladek 提交于
      There is no check for potential "text_len" overflow.  It is not needed
      because only valid level is detected.  It took me some time to
      understand why.  It would deserve a comment ;-)
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e8c42d36
    • P
      printk: remove obsolete check for log level "c" · c64730b2
      Petr Mladek 提交于
      The kernel log level "c" was removed in commit 61e99ab8 ("printk:
      remove the now unnecessary "C" annotation for KERN_CONT").  It is no
      longer detected in printk_get_level().  Hence we do not need to check it
      in vprintk_emit.
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c64730b2
  8. 18 2月, 2014 1 次提交
    • L
      printk: fix syslog() overflowing user buffer · e4178d80
      Linus Torvalds 提交于
      This is not a buffer overflow in the traditional sense: we don't
      overflow any *kernel* buffers, but we do mis-count the amount of data we
      copy back to user space for the SYSLOG_ACTION_READ_ALL case.
      
      In particular, if the user buffer is too small to hold everything, and
      *if* there is a continuation line at just the right place, we can end up
      giving the user more data than he asked for.
      
      The reason is that we first count up the number of bytes all the log
      records contains, then we walk the records again until we've skipped the
      records at the beginning that won't fit, and then we walk the rest of
      the records and copy them to the user space buffer.
      
      And in between that "skip the initial records that won't fit" and the
      "copy the records that *will* fit to user space", we reset the 'prev'
      variable that contained the record information for the last record not
      copied.  That meant that when we started copying to user space, we now
      had a different character count than what we had originally calculated
      in the first record walk-through.
      
      The fix is to simply not clear the 'prev' flags value (in both cases
      where we had the same logic: syslog_print_all and kmsg_dump_get_buffer:
      the latter is used for pstore-like dumping)
      Reported-and-tested-by: NDebabrata Banerjee <dbanerje@akamai.com>
      Acked-by: NKay Sievers <kay@vrfy.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e4178d80
  9. 24 1月, 2014 1 次提交
    • A
      printk: flush conflicting continuation line · 1d3fa370
      Arun KS 提交于
      An earlier newline was missing and current print is from different task.
      In this scenario flush the continuation line and store this line
      seperatly.
      
      This patch fix the below scenario of timestamp interleaving,
         [   28.154370 ] read_word_reg : reg[0x 3], reg[0x 4]  data [0x 642]
         [   28.155428 ] uart disconnect
         [   31.947341 ] dvfs[cpufreq.c<275>]:plug-in cpu<1> done
         [   28.155445 ] UART detached : send switch state 201
         [   32.014112 ] read_reg : reg[0x 3] data[0x21]
      
      [akpm@linux-foundation.org: simplify and condense the code]
      Signed-off-by: NArun KS <getarunks@gmail.com>
      Signed-off-by: NArun KS <arun.ks@broadcom.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d3fa370
  10. 22 1月, 2014 1 次提交
    • S
      kernel/printk/printk.c: use memblock apis for early memory allocations · 9da791df
      Santosh Shilimkar 提交于
      Switch to memblock interfaces for early memory allocator instead of
      bootmem allocator.  No functional change in beahvior than what it is in
      current code from bootmem users points of view.
      
      Archs already converted to NO_BOOTMEM now directly use memblock
      interfaces instead of bootmem wrappers build on top of memblock.  And
      the archs which still uses bootmem, these new apis just fallback to
      exiting bootmem APIs.
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9da791df
  11. 13 11月, 2013 3 次提交