linux-kernel - Re: [PATCH 1/2] irq_work: Fix racy check on work pending flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1351612425.8467.105.camel@gandalf.local.home>
Date:	Tue, 30 Oct 2012 11:53:45 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>
Subject: Re: [PATCH 1/2] irq_work: Fix racy check on work pending flag

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 <fweisbec@...il.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Ingo Molnar <mingo@...nel.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Paul Gortmaker <paul.gortmaker@...driver.com>

Acked-by: Steven Rostedt <rostedt@...dmis.org>

-- 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/