1. 18 Oct, 2011 2 commits
    • Peter Zijlstra's avatar
      cputimer: Cure lock inversion · bcd5cff7
      Peter Zijlstra authored
      There's a lock inversion between the cputimer->lock and rq->lock;
      notably the two callchains involved are:
      
       update_rlimit_cpu()
         sighand->siglock
         set_process_cpu_timer()
           cpu_timer_sample_group()
             thread_group_cputimer()
               cputimer->lock
               thread_group_cputime()
                 task_sched_runtime()
                   ->pi_lock
                   rq->lock
      
       scheduler_tick()
         rq->lock
         task_tick_fair()
           update_curr()
             account_group_exec()
               cputimer->lock
      
      Where the first one is enabling a CLOCK_PROCESS_CPUTIME_ID timer, and
      the second one is keeping up-to-date.
      
      This problem was introduced by e8abccb7 ("posix-cpu-timers: Cure
      SMP accounting oddities").
      
      Cure the problem by removing the cputimer->lock and rq->lock nesting,
      this leaves concurrent enablers doing duplicate work, but the time
      wasted should be on the same order otherwise wasted spinning on the
      lock and the greater-than assignment filter should ensure we preserve
      monotonicity.
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Reported-by: default avatarSimon Kirby <sim@hostway.ca>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: stable@kernel.org
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Link: http://lkml.kernel.org/r/1318928713.21167.4.camel@twinsSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      bcd5cff7
    • Linus Torvalds's avatar
      Linux 3.1-rc10 · 899e3ee4
      Linus Torvalds authored
      899e3ee4
  2. 17 Oct, 2011 1 commit
    • Linus Torvalds's avatar
      Avoid using variable-length arrays in kernel/sys.c · a84a79e4
      Linus Torvalds authored
      The size is always valid, but variable-length arrays generate worse code
      for no good reason (unless the function happens to be inlined and the
      compiler sees the length for the simple constant it is).
      
      Also, there seems to be some code generation problem on POWER, where
      Henrik Bakken reports that register r28 can get corrupted under some
      subtle circumstances (interrupt happening at the wrong time?).  That all
      indicates some seriously broken compiler issues, but since variable
      length arrays are bad regardless, there's little point in trying to
      chase it down.
      
      "Just don't do that, then".
      Reported-by: default avatarHenrik Grindal Bakken <henribak@cisco.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a84a79e4
  3. 16 Oct, 2011 1 commit
  4. 15 Oct, 2011 3 commits
  5. 14 Oct, 2011 6 commits
  6. 13 Oct, 2011 7 commits
  7. 11 Oct, 2011 5 commits
  8. 10 Oct, 2011 11 commits
  9. 08 Oct, 2011 2 commits
  10. 07 Oct, 2011 1 commit
  11. 06 Oct, 2011 1 commit
    • Linus Torvalds's avatar
      Merge git://github.com/davem330/net · 3ee72ca9
      Linus Torvalds authored
      * git://github.com/davem330/net:
        net: fix typos in Documentation/networking/scaling.txt
        bridge: leave carrier on for empty bridge
        netfilter: Use proper rwlock init function
        tcp: properly update lost_cnt_hint during shifting
        tcp: properly handle md5sig_pool references
        macvlan/macvtap: Fix unicast between macvtap interfaces in bridge mode
      3ee72ca9