On Tue, 2012-10-30 at 16:35 +0100, Frederic Weisbecker wrote: > Work claiming semantics require this operation > to be SMP-safe. > > So we want a strict ordering between the data we > want the work to handle and the flags that describe > the work state such that either we claim and we enqueue > the work that will see our data or we fail the claim > but the CPU where the work is still pending will > see the data we prepared when it executes the work: > > CPU 0 CPU 1 > > data = something claim work > smp_mb() smp_mb() > try claim work execute work (data) > > The early check for the pending flag in irq_work_claim() > fails to meet this ordering requirement. As a result, > when we fail to claim a work, it may have been processed > by CPU that were previously owning it already, leaving > our data unprocessed. > > Discussing this with Steven Rostedt, we can use memory > barriers to fix this or we can rely on cmpxchg() that > implies full barrier already. > > 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 does the ordering such that the CPU > where the work is pending handles our data. > > Signed-off-by: Frederic Weisbecker <[email protected]> > Cc: Peter Zijlstra <[email protected]> > Cc: Ingo Molnar <[email protected]> > Cc: Thomas Gleixner <[email protected]> > Cc: Andrew Morton <[email protected]> > Cc: Steven Rostedt <[email protected]> > Cc: Paul Gortmaker <[email protected]>
Acked-by: Steven Rostedt <[email protected]> -- Steve > --- > kernel/irq_work.c | 22 +++++++++++++++++----- > 1 files changed, 17 insertions(+), 5 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
