1. 17 Nov, 2012 2 commits
  2. 14 Nov, 2012 2 commits
    • Frederic Weisbecker's avatar
      irq_work: Fix racy check on work pending flag · e0bbe2d8
      Frederic Weisbecker authored
      Work claiming wants to be SMP-safe.
      
      And by the time we try to claim a work, if it is already executing
      concurrently on another CPU, we want to succeed the claiming and queue
      the work again because the other CPU may have missed the data we wanted
      to handle in our work if it's about to complete there.
      
      This scenario is summarized below:
      
              CPU 1                                   CPU 2
              -----                                   -----
              (flags = 0)
              cmpxchg(flags, 0, IRQ_WORK_FLAGS)
              (flags = 3)
              [...]
              xchg(flags, IRQ_WORK_BUSY)
              (flags = 2)
              func()
                                                      if (flags & IRQ_WORK_PENDING)
                                                              (not true)
                                                      cmpxchg(flags, flags, IRQ_WORK_FLAGS)
                                                      (flags = 3)
                                                      [...]
              cmpxchg(flags, IRQ_WORK_BUSY, 0);
              (fail, pending on CPU 2)
      
      This state machine is synchronized using [cmp]xchg() on the flags.
      As such, the early IRQ_WORK_PENDING check in CPU 2 above is racy.
      By the time we check it, we may be dealing with a stale value because
      we aren't using an atomic accessor. As a result, CPU 2 may "see"
      that the work is still pending on another CPU while it may be
      actually completing the work function exection already, leaving
      our data unprocessed.
      
      To fix this, we start by speculating about the value we wish to be
      in the work->flags but we only make any conclusion after the value
      returned by the cmpxchg() call that either claims the work or let
      the current owner handle the pending work for us.
      Changelog-heavily-inspired-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Anish Kumar <anish198519851985@gmail.com>
      e0bbe2d8
    • Frederic Weisbecker's avatar
      irq_work: Fix racy IRQ_WORK_BUSY flag setting · c8446b75
      Frederic Weisbecker authored
      The IRQ_WORK_BUSY flag is set right before we execute the
      work. Once this flag value is set, the work enters a
      claimable state again.
      
      So if we have specific data to compute in our work, we ensure it's
      either handled by another CPU or locally by enqueuing the work again.
      This state machine is guanranteed by atomic operations on the flags.
      
      So when we set IRQ_WORK_BUSY without using an xchg-like operation,
      we break this guarantee as in the following summarized scenario:
      
              CPU 1                                   CPU 2
              -----                                   -----
                                                      (flags = 0)
                                                      old_flags = flags;
              (flags = 0)
              cmpxchg(flags, old_flags,
                      old_flags | IRQ_WORK_FLAGS)
              (flags = 3)
              [...]
              flags = IRQ_WORK_BUSY
              (flags = 2)
              func()
                                                      (sees flags = 3)
                                                      cmpxchg(flags, old_flags,
                                                              old_flags | IRQ_WORK_FLAGS)
                                                      (give up)
      
              cmpxchg(flags, 2, 0);
              (flags = 0)
      
      CPU 1 claims a work and executes it, so it sets IRQ_WORK_BUSY and
      the work is again in a claimable state. Now CPU 2 has new data to process
      and try to claim that work but it may see a stale value of the flags
      and think the work is still pending somewhere that will handle our data.
      This is because CPU 1 doesn't set IRQ_WORK_BUSY atomically.
      
      As a result, the data expected to be handle by CPU 2 won't get handled.
      
      To fix this, use xchg() to set IRQ_WORK_BUSY, this way we ensure the CPU 2
      will see the correct value with cmpxchg() using the expected ordering.
      Changelog-heavily-inspired-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Anish Kumar <anish198519851985@gmail.com>
      c8446b75
  3. 04 Nov, 2012 1 commit
  4. 03 Nov, 2012 15 commits
  5. 02 Nov, 2012 20 commits