1. 23 7月, 2009 1 次提交
  2. 21 7月, 2009 1 次提交
    • T
      genirq: Delegate irq affinity setting to the irq thread · 591d2fb0
      Thomas Gleixner 提交于
      irq_set_thread_affinity() calls set_cpus_allowed_ptr() which might
      sleep, but irq_set_thread_affinity() is called with desc->lock held
      and can be called from hard interrupt context as well. The code has
      another bug as it does not hold a ref on the task struct as required
      by set_cpus_allowed_ptr().
      
      Just set the IRQTF_AFFINITY bit in action->thread_flags. The next time
      the thread runs it migrates itself. Solves all of the above problems
      nicely.
      
      Add kerneldoc to irq_set_thread_affinity() while at it.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <new-submission>
      591d2fb0
  3. 19 7月, 2009 2 次提交
  4. 18 7月, 2009 3 次提交
  5. 17 7月, 2009 1 次提交
    • X
      tracing/function: Fix the return value of ftrace_trace_onoff_callback() · 04aef32d
      Xiao Guangrong 提交于
      ftrace_trace_onoff_callback() will return an error even if we do the
      right operation, for example:
      
       # echo _spin_*:traceon:10 > set_ftrace_filter
       -bash: echo: write error: Invalid argument
       # cat set_ftrace_filter
       #### all functions enabled ####
       _spin_trylock_bh:traceon:count=10
       _spin_unlock_irq:traceon:count=10
       _spin_unlock_bh:traceon:count=10
       _spin_lock_irq:traceon:count=10
       _spin_unlock:traceon:count=10
       _spin_trylock:traceon:count=10
       _spin_unlock_irqrestore:traceon:count=10
       _spin_lock_irqsave:traceon:count=10
       _spin_lock_bh:traceon:count=10
       _spin_lock:traceon:count=10
      
      We want to set _spin_*:traceon:10 to set_ftrace_filter, it complains
      with "Invalid argument", but the operation is successful.
      
      This is because ftrace_process_regex() returns the number of functions that
      matched the pattern. If the number is not 0, this value is returned
      by ftrace_regex_write() whereas we want to return the number of bytes
      virtually written.
      Also the file offset pointer is not updated in this case.
      
      If the number of matched functions is lower than the number of bytes written
      by the user, this results to a reprocessing of the string given by the user with
      a lower size, leading to a malformed ftrace regex and then a -EINVAL returned.
      
      So, this patch fixes it by returning 0 if no error occured.
      The fix also applies on 2.6.30
      Signed-off-by: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      Reviewed-by: NLi Zefan <lizf@cn.fujitsu.com>
      Cc: stable@kernel.org
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      04aef32d
  6. 13 7月, 2009 2 次提交
  7. 11 7月, 2009 3 次提交
  8. 10 7月, 2009 6 次提交
    • T
      hrtimer: Fix migration expiry check · 6ff7041d
      Thomas Gleixner 提交于
      The timer migration expiry check should prevent the migration of a
      timer to another CPU when the timer expires before the next event is
      scheduled on the other CPU. Migrating the timer might delay it because
      we can not reprogram the clock event device on the other CPU. But the
      code implementing that check has two flaws:
      
      - for !HIGHRES the check compares the expiry value with the clock
        events device expiry value which is wrong for CLOCK_REALTIME based
        timers.
      
      - the check is racy. It holds the hrtimer base lock of the target CPU,
        but the clock event device expiry value can be modified
        nevertheless, e.g. by an timer interrupt firing.
      
      The !HIGHRES case is easy to fix as we can enqueue the timer on the
      cpu which was selected by the load balancer. It runs the idle
      balancing code once per jiffy anyway. So the maximum delay for the
      timer is the same as when we keep the tick on the current cpu going.
      
      In the HIGHRES case we can get the next expiry value from the hrtimer
      cpu_base of the target CPU and serialize the update with the cpu_base
      lock. This moves the lock section in hrtimer_interrupt() so we can set
      next_event to KTIME_MAX while we are handling the expired timers and
      set it to the next expiry value after we handled the timers under the
      base lock. While the expired timers are processed timer migration is
      blocked because the expiry time of the timer is always <= KTIME_MAX.
      
      Also remove the now useless clockevents_get_next_event() function.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6ff7041d
    • T
      hrtimer: migration: do not check expiry time on current CPU · 7e0c5086
      Thomas Gleixner 提交于
      The timer migration code needs to check whether the expiry time of the
      timer is before the programmed clock event expiry time when the timer
      is enqueued on another CPU because we can not reprogram the timer
      device on the other CPU. The current logic checks the expiry time even
      if we enqueue on the current CPU when nohz_get_load_balancer() returns
      current CPU. This might lead to an endless loop in the expiry check
      code when the expiry time of the timer is before the current
      programmed next event.
      
      Check whether nohz_get_load_balancer() returns current CPU and skip
      the expiry check if this is the case.
      
      The bug was triggered from the networking code. The patch fixes the
      regression http://bugzilla.kernel.org/show_bug.cgi?id=13738
      (Soft-Lockup/Race in networking in 2.6.31-rc1+195)
      
      Cc: Arun Bharadwaj <arun@linux.vnet.ibm.com
      Tested-by: NJoao Correia <joaomiguelcorreia@gmail.com>
      Tested-by: NAndres Freund <andres@anarazel.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7e0c5086
    • F
      sched: Fix rt_rq->pushable_tasks initialization in init_rt_rq() · c20b08e3
      Fabio Checconi 提交于
      init_rt_rq() initializes only rq->rt.pushable_tasks, and not the
      pushable_tasks field of the passed rt_rq.  The plist is not used
      uninitialized since the only pushable_tasks plists used are the
      ones of root rt_rqs; anyway reinitializing the list on every group
      creation corrupts the root plist, losing its previous contents.
      Signed-off-by: NFabio Checconi <fabio@gandalf.sssup.it>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <20090615185638.GK21741@gandalf.sssup.it>
      CC: Gregory Haskins <ghaskins@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c20b08e3
    • L
      sched: Reset sched stats on fork() · 7793527b
      Lucas De Marchi 提交于
      The sched_stat fields are currently not reset upon fork.
      Ingo's recent commit 6c594c21
      did reset nr_migrations, but it didn't reset any of the
      others.
      
      This patch resets all sched_stat fields on fork.
      Signed-off-by: NLucas De Marchi <lucas.de.marchi@gmail.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <193b0f820907090457s7a3662f4gcdecdc22fcae857b@mail.gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7793527b
    • P
      sched_rt: Fix overload bug on rt group scheduling · a1ba4d8b
      Peter Zijlstra 提交于
      Fixes an easily triggerable BUG() when setting process affinities.
      
      Make sure to count the number of migratable tasks in the same place:
      the root rt_rq. Otherwise the number doesn't make sense and we'll hit
      the BUG in set_cpus_allowed_rt().
      
      Also, make sure we only count tasks, not groups (this is probably
      already taken care of by the fact that rt_se->nr_cpus_allowed will be 0
      for groups, but be more explicit)
      Tested-by: NThomas Gleixner <tglx@linutronix.de>
      CC: stable@kernel.org
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NGregory Haskins <ghaskins@novell.com>
      LKML-Reference: <1247067476.9777.57.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a1ba4d8b
    • C
      kmemleak: Remove alloc_bootmem annotations introduced in the past · 264ef8a9
      Catalin Marinas 提交于
      kmemleak_alloc() calls were added in some places where alloc_bootmem was
      called. Since now kmemleak tracks bootmem allocations, these explicit
      calls should be run.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Acked-by: NPekka Enberg <penberg@cs.helsinki.fi>
      264ef8a9
  9. 09 7月, 2009 2 次提交
  10. 07 7月, 2009 2 次提交
  11. 02 7月, 2009 1 次提交
  12. 01 7月, 2009 3 次提交
  13. 30 6月, 2009 2 次提交
  14. 29 6月, 2009 1 次提交
  15. 27 6月, 2009 2 次提交
  16. 26 6月, 2009 8 次提交