1. 30 Apr, 2013 3 commits
  2. 22 Mar, 2013 1 commit
    • Frederic Weisbecker's avatar
      printk: Provide a wake_up_klogd() off-case · dc72c32e
      Frederic Weisbecker authored
      
      
      wake_up_klogd() is useless when CONFIG_PRINTK=n because neither printk()
      nor printk_sched() are in use and there are actually no waiter on
      log_wait waitqueue.  It should be a stub in this case for users like
      bust_spinlocks().
      
      Otherwise this results in this warning when CONFIG_PRINTK=n and
      CONFIG_IRQ_WORK=n:
      
      	kernel/built-in.o In function `wake_up_klogd':
      	(.text.wake_up_klogd+0xb4): undefined reference to `irq_work_queue'
      
      To fix this, provide an off-case for wake_up_klogd() when
      CONFIG_PRINTK=n.
      
      There is much more from console_unlock() and other console related code
      in printk.c that should be moved under CONFIG_PRINTK.  But for now,
      focus on a minimal fix as we passed the merged window already.
      
      [akpm@linux-foundation.org: include printk.h in bust_spinlocks.c]
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Reported-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dc72c32e
  3. 08 Feb, 2013 1 commit
  4. 31 Jan, 2013 1 commit
  5. 05 Jan, 2013 1 commit
    • Roland Dreier's avatar
      printk: fix incorrect length from print_time() when seconds > 99999 · 35dac27c
      Roland Dreier authored
      print_prefix() passes a NULL buf to print_time() to get the length of
      the time prefix; when printk times are enabled, the current code just
      returns the constant 15, which matches the format "[%5lu.%06lu] " used
      to print the time value.  However, this is obviously incorrect when the
      whole seconds part of the time gets beyond 5 digits (100000 seconds is a
      bit more than a day of uptime).
      
      The simple fix is to use snprintf(NULL, 0, ...) to calculate the actual
      length of the time prefix.  This could be micro-optimized but it seems
      better to have simpler, more readable code here.
      
      The bug leads to the syslog system call miscomputing which messages fit
      into the userspace buffer.  If there are enough messages to fill
      log_buf_len and some have a timestamp >= 100000, dmesg may fail with:
      
          # dmesg
          klogctl: Bad address
      
      When this happens, strace shows that the failure is indeed EFAULT due to
      the kernel mistakenly accessing past the end of dmesg's buffer, since
      dmesg asks the kernel how big a buffer it needs, allocates a bit more,
      and then gets an error when it asks the kernel to fill it:
      
          syslog(0xa, 0, 0)                       = 1048576
          mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa4d25d2000
          syslog(0x3, 0x7fa4d25d2010, 0x100008)   = -1 EFAULT (Bad address)
      
      As far as I can see, the bug has been there as long as print_time(),
      which comes from commit 084681d1
      
       ("printk: flush continuation lines
      immediately to console") in 3.5-rc5.
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Joe Perches <joe@perches.com>
      Cc: Sylvain Munaut <s.munaut@whatever-company.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      35dac27c
  6. 18 Dec, 2012 1 commit
  7. 18 Nov, 2012 1 commit
    • Frederic Weisbecker's avatar
      printk: Wake up klogd using irq_work · 74876a98
      Frederic Weisbecker authored
      
      
      klogd is woken up asynchronously from the tick in order
      to do it safely.
      
      However if printk is called when the tick is stopped, the reader
      won't be woken up until the next interrupt, which might not fire
      for a while. As a result, the user may miss some message.
      
      To fix this, lets implement the printk tick using a lazy irq work.
      This subsystem takes care of the timer tick state and can
      fix up accordingly.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      74876a98
  8. 24 Oct, 2012 1 commit
    • Daniel Vetter's avatar
      console: use might_sleep in console_lock · 6b898c07
      Daniel Vetter authored
      
      
      Instead of BUG_ON(in_interrupt()), since that doesn't check for all
      the newfangled stuff like preempt.
      
      Note that this is valid since the console_sem is essentially used like
      a real mutex with only two twists:
      - we allow trylock from hardirq context
      - across suspend/resume we lock the logical console_lock, but drop the
        semaphore protecting the locking state.
      
      Now that doesn't guarantee that no one is playing tricks in
      single-thread atomic contexts at suspend/resume/boot time, but
      - I couldn't find anything suspicious with some grepping,
      - might_sleep shouldn't die,
      - and I think the upside of catching more potential issues is worth
        the risk of getting a might_sleep backtrace that would have been
        save (and then dealing with that fallout).
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b898c07
  9. 22 Oct, 2012 1 commit
    • Daniel Vetter's avatar
      console: implement lockdep support for console_lock · daee7797
      Daniel Vetter authored
      Dave Airlie recently discovered a locking bug in the fbcon layer,
      where a timer_del_sync (for the blinking cursor) deadlocks with the
      timer itself, since both (want to) hold the console_lock:
      
      https://lkml.org/lkml/2012/8/21/36
      
      
      
      Unfortunately the console_lock isn't a plain mutex and hence has no
      lockdep support. Which resulted in a few days wasted of tracking down
      this bug (complicated by the fact that printk doesn't show anything
      when the console is locked) instead of noticing the bug much earlier
      with the lockdep splat.
      
      Hence I've figured I need to fix that for the next deadlock involving
      console_lock - and with kms/drm growing ever more complex locking
      that'll eventually happen.
      
      Now the console_lock has rather funky semantics, so after a quick irc
      discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
      the original idead of switching to a real mutex (since it won't work)
      and instead opted to annotate the console_lock with lockdep
      information manually.
      
      There are a few special cases:
      - The console_lock state is protected by the console_sem, and usually
        grabbed/dropped at _lock/_unlock time. But the suspend/resume code
        drops the semaphore without dropping the console_lock (see
        suspend_console/resume_console). But since the same thread that did
        the suspend will do the resume, we don't need to fix up anything.
      
      - In the printk code there's a special trylock, only used to kick off
        the logbuffer printk'ing in console_unlock. But all that happens
        while lockdep is disable (since printk does a few other evil
        tricks). So no issue there, either.
      
      - The console_lock can also be acquired form irq context (but only
        with a trylock). lockdep already handles that.
      
      This all leaves us with annotating the normal console_lock, _unlock
      and _trylock functions.
      
      And yes, it works - simply unloading a drm kms driver resulted in
      lockdep complaining about the deadlock in fbcon_deinit:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.6.0-rc2+ #552 Not tainted
      -------------------------------------------------------
      kms-reload/3577 is trying to acquire lock:
       ((&info->queue)){+.+...}, at: [<ffffffff81058c70>] wait_on_work+0x0/0xa7
      
      but task is already holding lock:
       (console_lock){+.+.+.}, at: [<ffffffff81264686>] bind_con_driver+0x38/0x263
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (console_lock){+.+.+.}:
             [<ffffffff81087440>] lock_acquire+0x95/0x105
             [<ffffffff81040190>] console_lock+0x59/0x5b
             [<ffffffff81209cb6>] fb_flashcursor+0x2e/0x12c
             [<ffffffff81057c3e>] process_one_work+0x1d9/0x3b4
             [<ffffffff810584a2>] worker_thread+0x1a7/0x24b
             [<ffffffff8105ca29>] kthread+0x7f/0x87
             [<ffffffff813b1204>] kernel_thread_helper+0x4/0x10
      
      -> #0 ((&info->queue)){+.+...}:
             [<ffffffff81086cb3>] __lock_acquire+0x999/0xcf6
             [<ffffffff81087440>] lock_acquire+0x95/0x105
             [<ffffffff81058cab>] wait_on_work+0x3b/0xa7
             [<ffffffff81058dd6>] __cancel_work_timer+0xbf/0x102
             [<ffffffff81058e33>] cancel_work_sync+0xb/0xd
             [<ffffffff8120a3b3>] fbcon_deinit+0x11c/0x1dc
             [<ffffffff81264793>] bind_con_driver+0x145/0x263
             [<ffffffff81264a45>] unbind_con_driver+0x14f/0x195
             [<ffffffff8126540c>] store_bind+0x1ad/0x1c1
             [<ffffffff8127cbb7>] dev_attr_store+0x13/0x1f
             [<ffffffff8116d884>] sysfs_write_file+0xe9/0x121
             [<ffffffff811145b2>] vfs_write+0x9b/0xfd
             [<ffffffff811147b7>] sys_write+0x3e/0x6b
             [<ffffffff813b0039>] system_call_fastpath+0x16/0x1b
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(console_lock);
                                     lock((&info->queue));
                                     lock(console_lock);
        lock((&info->queue));
      
       *** DEADLOCK ***
      
      v2: Mark the lockdep_map static, noticed by Jani Nikula.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      daee7797
  10. 17 Oct, 2012 1 commit
  11. 12 Aug, 2012 1 commit
    • Jeff Mahoney's avatar
      printk: Fix calculation of length used to discard records · e3756477
      Jeff Mahoney authored
      
      
      While tracking down a weird buffer overflow issue in a program that
      looked to be sane, I started double checking the length returned by
      syslog(SYSLOG_ACTION_READ_ALL, ...) to make sure it wasn't overflowing
      the buffer.
      
      Sure enough, it was.  I saw this in strace:
      
        11339 syslog(SYSLOG_ACTION_READ_ALL, "<5>[244017.708129] REISERFS (dev"..., 8192) = 8279
      
      It turns out that the loops that calculate how much space the entries
      will take when they're copied don't include the newlines and prefixes
      that will be included in the final output since prev flags is passed as
      zero.
      
      This patch properly accounts for it and fixes the overflow.
      
      CC: stable@kernel.org
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e3756477
  12. 31 Jul, 2012 3 commits
  13. 21 Jul, 2012 2 commits
  14. 20 Jul, 2012 1 commit
    • Vivek Goyal's avatar
      printk: Export struct log size and member offsets through vmcoreinfo · 6791457a
      Vivek Goyal authored
      
      
      There are tools like makedumpfile and vmcore-dmesg which can extract
      kernel log buffer from vmcore. Since we introduced structured logging,
      that functionality is broken. Now user space tools need to know about
      "struct log" and offsets of various fields to be able to parse struct
      log data and extract text message or dictonary.
      
      This patch exports some of the fields.
      
      Currently I am not exporting log "level" info as that is a bitfield and
      offsetof() bitfields can't be calculated. But if people start asking for
      log level info in the output then we probably either need to seprate
      out "level" or use bit shift operations for flags and level.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Acked-by: default avatarKay Sievers <kay@vrfy.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6791457a
  15. 17 Jul, 2012 4 commits
  16. 09 Jul, 2012 2 commits
  17. 06 Jul, 2012 5 commits
  18. 30 Jun, 2012 1 commit
  19. 29 Jun, 2012 2 commits
  20. 26 Jun, 2012 2 commits
  21. 25 Jun, 2012 1 commit
  22. 16 Jun, 2012 2 commits
  23. 15 Jun, 2012 1 commit
  24. 12 Jun, 2012 1 commit