1. 03 4月, 2009 1 次提交
  2. 17 3月, 2009 1 次提交
    • G
      printk: correct the behavior of printk_timed_ratelimit() · f2d28a2e
      Guillaume Knispel 提交于
      Impact: fix jiffies-comparison sign-wrap behavior
      
      The behavior provided by printk_timed_ratelimit() is, in some
      situations, probably not what a caller would reasonably expect:
      
      bool printk_timed_ratelimit(unsigned long *caller_jiffies,
      			unsigned int interval_msecs)
      {
      	if (*caller_jiffies == 0 || time_after(jiffies, *caller_jiffies)) {
      		*caller_jiffies = jiffies + msecs_to_jiffies(interval_msecs);
      		return true;
      	}
      	return false;
      }
      
      On a 32 bit computer, if printk_timed_ratelimit() is initially called at
      time jiffies == Ja, *caller_jiffies is set to
      Ja + msecs_to_jiffies(interval_msecs): let's say Ja + 42 for this
      example.
      
      If this caller then doesn't call printk_timed_ratelimit() until
      jiffies == Ja + (1 << 31) + 42 (which can happen as soon as ~ 25 days
      later on a 1000 HZ system), printk_timed_ratelimit() will then always
      return false to this caller until jiffies loops completely (1 << 31 more
      ticks).
      
      Ths change makes it only return false if jiffies is in the small
      time window starting at the previous call when true was returned and
      ending interval_msecs later.  Note that if jiffies loops completely
      between two calls to printk_timed_ratelimit(), it will obviously still
      wrongly return false, but this is something with a low probability.
      
      If something completely reliable is needed I guess jiffies_64 must be
      used (which this change does not do).
      Signed-off-by: NGuillaume Knispel <gknispel@proformatique.com>
      Cc: Ulrich Drepper <drepper@redhat.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20090317161842.0059096b@xilun.lan.proformatique.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f2d28a2e
  3. 22 2月, 2009 1 次提交
    • A
      PM: Fix suspend_console and resume_console to use only one semaphore · 403f3075
      Arve Hjønnevåg 提交于
      This fixes a race where a thread acquires the console while the
      console is suspended, and the console is resumed before this
      thread releases it. In this case, the secondary console
      semaphore would be left locked, and the primary semaphore would
      be released twice. This in turn would cause the console switch
      on suspend or resume to hang forever.
      
      Note that suspend_console does not actually lock the console
      for clients that use acquire_console_sem, it only locks it for
      clients that use try_acquire_console_sem. If we change
      suspend_console to fully lock the console, then the kernel
      may deadlock on suspend. One client of try_acquire_console_sem
      is acquire_console_semaphore_for_printk, which uses it to
      prevent printk from using the console while it is suspended.
      Signed-off-by: NArve Hjønnevåg <arve@android.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Greg KH <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      403f3075
  4. 14 1月, 2009 2 次提交
  5. 06 1月, 2009 1 次提交
  6. 20 12月, 2008 1 次提交
  7. 24 10月, 2008 1 次提交
  8. 17 10月, 2008 3 次提交
  9. 14 10月, 2008 1 次提交
  10. 20 8月, 2008 2 次提交
    • J
      printk: robustify printk, update comment · 1fa63a81
      Jiri Kosina 提交于
      Remove the comment describing the possibility of printk() deadlocking on
      runqueue lock.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1fa63a81
    • P
      printk: robustify printk, fix #2 · fa33507a
      Peter Zijlstra 提交于
      Dmitry Adamushko reported:
      
      > [*] btw., with DEBUG being enabled, pr_debug() generates [1] when
      > debug_smp_processor_id() is used (CONFIG_DEBUG_PREEMPT).
      >
      > the problem seems to be caused by the following commit:
      > commit b845b517
      > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      > Date:   Fri Aug 8 21:47:09 2008 +0200
      >
      >     printk: robustify printk
      >
      >
      > wake_up_klogd() -> __get_cpu_var() -> smp_processor_id()
      >
      > and that's being called from release_console_sem() which is, in turn,
      > said to be "may be called from any context" [2]
      >
      > and in this case, it seems to be called from some non-preemptible
      > context (although, it can't be printk()...
      > although, I haven't looked carefully yet).
      >
      > Provided [2], __get_cpu_var() is perhaps not the right solution there.
      >
      >
      > [1]
      >
      > [ 7697.942005] BUG: using smp_processor_id() in preemptible [00000000] code: syslogd/3542
      > [ 7697.942005] caller is wake_up_klogd+0x1b/0x50
      > [ 7697.942005] Pid: 3542, comm: syslogd Not tainted 2.6.27-rc3-tip-git #2
      > [ 7697.942005] Call Trace:
      > [ 7697.942005]  [<ffffffff8036b398>] debug_smp_processor_id+0xe8/0xf0
      > [ 7697.942005]  [<ffffffff80239d3b>] wake_up_klogd+0x1b/0x50
      > [ 7697.942005]  [<ffffffff8023a047>] release_console_sem+0x1e7/0x200
      > [ 7697.942005]  [<ffffffff803c0f17>] do_con_write+0xb7/0x1f30
      > [ 7697.942005]  [<ffffffff8020d920>] ? show_trace+0x10/0x20
      > [ 7697.942005]  [<ffffffff8020dc42>] ? dump_stack+0x72/0x80
      > [ 7697.942005]  [<ffffffff8036392d>] ? __ratelimit+0xbd/0xe0
      > [ 7697.942005]  [<ffffffff8036b398>] ? debug_smp_processor_id+0xe8/0xf0
      > [ 7697.942005]  [<ffffffff80239d3b>] ? wake_up_klogd+0x1b/0x50
      > [ 7697.942005]  [<ffffffff8023a047>] ? release_console_sem+0x1e7/0x200
      > [ 7697.942005]  [<ffffffff803c2de9>] con_write+0x19/0x30
      > [ 7697.942005]  [<ffffffff803b37b6>] write_chan+0x276/0x3c0
      > [ 7697.942005]  [<ffffffff80232b20>] ? default_wake_function+0x0/0x10
      > [ 7697.942005]  [<ffffffff804cb872>] ? _spin_lock_irqsave+0x22/0x50
      > [ 7697.942005]  [<ffffffff803b1334>] tty_write+0x194/0x260
      > [ 7697.942005]  [<ffffffff803b3540>] ? write_chan+0x0/0x3c0
      > [ 7697.942005]  [<ffffffff803b14a4>] redirected_tty_write+0xa4/0xb0
      > [ 7697.942005]  [<ffffffff803b1400>] ? redirected_tty_write+0x0/0xb0
      > [ 7697.942005]  [<ffffffff802a88c2>] do_loop_readv_writev+0x52/0x80
      > [ 7697.942005]  [<ffffffff802a939d>] do_readv_writev+0x1bd/0x1d0
      > [ 7697.942005]  [<ffffffff802a93e9>] vfs_writev+0x39/0x60
      > [ 7697.942005]  [<ffffffff802a9870>] sys_writev+0x50/0x90
      > [ 7697.942005]  [<ffffffff8020bb3b>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Reported-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fa33507a
  11. 11 8月, 2008 1 次提交
  12. 31 7月, 2008 1 次提交
  13. 26 7月, 2008 1 次提交
    • D
      printk ratelimiting rewrite · 717115e1
      Dave Young 提交于
      All ratelimit user use same jiffies and burst params, so some messages
      (callbacks) will be lost.
      
      For example:
      a call printk_ratelimit(5 * HZ, 1)
      b call printk_ratelimit(5 * HZ, 1) before the 5*HZ timeout of a, then b will
      will be supressed.
      
      - rewrite __ratelimit, and use a ratelimit_state as parameter.  Thanks for
        hints from andrew.
      
      - Add WARN_ON_RATELIMIT, update rcupreempt.h
      
      - remove __printk_ratelimit
      
      - use __ratelimit in net_ratelimit
      Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      717115e1
  14. 25 7月, 2008 1 次提交
  15. 09 7月, 2008 1 次提交
  16. 08 7月, 2008 1 次提交
  17. 18 6月, 2008 1 次提交
  18. 16 6月, 2008 1 次提交
  19. 27 5月, 2008 1 次提交
    • M
      xen: Enable console tty by default in domU if it's not a dummy · 9e124fe1
      Markus Armbruster 提交于
      Without console= arguments on the kernel command line, the first
      console to register becomes enabled and the preferred console (the one
      behind /dev/console).  This is normally tty (assuming
      CONFIG_VT_CONSOLE is enabled, which it commonly is).
      
      This is okay as long tty is a useful console.  But unless we have the
      PV framebuffer, and it is enabled for this domain, tty0 in domU is
      merely a dummy.  In that case, we want the preferred console to be the
      Xen console hvc0, and we want it without having to fiddle with the
      kernel command line.  Commit b8c2d3df
      did that for us.
      
      Since we now have the PV framebuffer, we want to enable and prefer tty
      again, but only when PVFB is enabled.  But even then we still want to
      enable the Xen console as well.
      
      Problem: when tty registers, we can't yet know whether the PVFB is
      enabled.  By the time we can know (xenstore is up), the console setup
      game is over.
      
      Solution: enable console tty by default, but keep hvc as the preferred
      console.  Change the preferred console to tty when PVFB probes
      successfully, unless we've been given console kernel parameters.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9e124fe1
  20. 25 5月, 2008 6 次提交
  21. 24 5月, 2008 1 次提交
    • S
      ftrace: trace irq disabled critical timings · 81d68a96
      Steven Rostedt 提交于
      This patch adds latency tracing for critical timings
      (how long interrupts are disabled for).
      
       "irqsoff" is added to /debugfs/tracing/available_tracers
      
      Note:
        tracing_max_latency
          also holds the max latency for irqsoff (in usecs).
         (default to large number so one must start latency tracing)
      
        tracing_thresh
          threshold (in usecs) to always print out if irqs off
          is detected to be longer than stated here.
          If irq_thresh is non-zero, then max_irq_latency
          is ignored.
      
      Here's an example of a trace with ftrace_enabled = 0
      
      =======
      preemption latency trace v1.1.5 on 2.6.24-rc7
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      --------------------------------------------------------------------
       latency: 100 us, #3/3, CPU#1 | (M:rt VP:0, KP:0, SP:0 HP:0 #P:2)
          -----------------
          | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
          -----------------
       => started at: _spin_lock_irqsave+0x2a/0xb7
       => ended at:   _spin_unlock_irqrestore+0x32/0x5f
      
                       _------=> CPU#
                      / _-----=> irqs-off
                     | / _----=> need-resched
                     || / _---=> hardirq/softirq
                     ||| / _--=> preempt-depth
                     |||| /
                     |||||     delay
         cmd     pid ||||| time  |   caller
            \   /    |||||   \   |   /
       swapper-0     1d.s3    0us+: _spin_lock_irqsave+0x2a/0xb7 (e1000_update_stats+0x47/0x64c [e1000])
       swapper-0     1d.s3  100us : _spin_unlock_irqrestore+0x32/0x5f (e1000_update_stats+0x641/0x64c [e1000])
       swapper-0     1d.s3  100us : trace_hardirqs_on_caller+0x75/0x89 (_spin_unlock_irqrestore+0x32/0x5f)
      
      vim:ft=help
      =======
      
      And this is a trace with ftrace_enabled == 1
      
      =======
      preemption latency trace v1.1.5 on 2.6.24-rc7
      --------------------------------------------------------------------
       latency: 102 us, #12/12, CPU#1 | (M:rt VP:0, KP:0, SP:0 HP:0 #P:2)
          -----------------
          | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
          -----------------
       => started at: _spin_lock_irqsave+0x2a/0xb7
       => ended at:   _spin_unlock_irqrestore+0x32/0x5f
      
                       _------=> CPU#
                      / _-----=> irqs-off
                     | / _----=> need-resched
                     || / _---=> hardirq/softirq
                     ||| / _--=> preempt-depth
                     |||| /
                     |||||     delay
         cmd     pid ||||| time  |   caller
            \   /    |||||   \   |   /
       swapper-0     1dNs3    0us+: _spin_lock_irqsave+0x2a/0xb7 (e1000_update_stats+0x47/0x64c [e1000])
       swapper-0     1dNs3   46us : e1000_read_phy_reg+0x16/0x225 [e1000] (e1000_update_stats+0x5e2/0x64c [e1000])
       swapper-0     1dNs3   46us : e1000_swfw_sync_acquire+0x10/0x99 [e1000] (e1000_read_phy_reg+0x49/0x225 [e1000])
       swapper-0     1dNs3   46us : e1000_get_hw_eeprom_semaphore+0x12/0xa6 [e1000] (e1000_swfw_sync_acquire+0x36/0x99 [e1000])
       swapper-0     1dNs3   47us : __const_udelay+0x9/0x47 (e1000_read_phy_reg+0x116/0x225 [e1000])
       swapper-0     1dNs3   47us+: __delay+0x9/0x50 (__const_udelay+0x45/0x47)
       swapper-0     1dNs3   97us : preempt_schedule+0xc/0x84 (__delay+0x4e/0x50)
       swapper-0     1dNs3   98us : e1000_swfw_sync_release+0xc/0x55 [e1000] (e1000_read_phy_reg+0x211/0x225 [e1000])
       swapper-0     1dNs3   99us+: e1000_put_hw_eeprom_semaphore+0x9/0x35 [e1000] (e1000_swfw_sync_release+0x50/0x55 [e1000])
       swapper-0     1dNs3  101us : _spin_unlock_irqrestore+0xe/0x5f (e1000_update_stats+0x641/0x64c [e1000])
       swapper-0     1dNs3  102us : _spin_unlock_irqrestore+0x32/0x5f (e1000_update_stats+0x641/0x64c [e1000])
       swapper-0     1dNs3  102us : trace_hardirqs_on_caller+0x75/0x89 (_spin_unlock_irqrestore+0x32/0x5f)
      
      vim:ft=help
      =======
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      81d68a96
  22. 30 4月, 2008 3 次提交
  23. 29 4月, 2008 1 次提交
  24. 16 4月, 2008 1 次提交
  25. 25 3月, 2008 1 次提交
  26. 26 2月, 2008 1 次提交
  27. 09 2月, 2008 3 次提交