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]
Date:	Fri, 31 Oct 2008 12:42:28 -0400
From:	Chris Snook <>
To:	Huang Ying <>
CC:	Andrew Morton <>,
	"" <>
Subject: Re: [PATH -mm -v2] Fix a race condtion of oops_in_progress

Huang Ying wrote:
> Hi, Chris,
> On Wed, 2008-10-29 at 08:51 -0600, Chris Snook wrote:
>> Huang Ying wrote:
>>> Fix a race condition accessing oops_in_progress.  Which may be changed on
>>> multiple CPU simultaneously, but it is changed via non-atomic operation
>>> ++/--.  This patch changes the definition of oops_in_process from int to
>>> atomic_t, and accessing method to atomic operations.
>> You also need barriers.  I believe rmb() before atomic_read() and wmb() after 
>> atomic_set() should suffice.
> I don't think that is necessary. I haven't found there is particular
> consistent requirement about oops_in_progress.

atomic_read() and atomic_set() don't inherently cause changes to be visible on 
other CPUs any faster than ++ and -- operators.  Sometimes it happens to work 
out that way as a result of how the compiler and the CPU order operations, but 
there's no semantic guarantee, and it could even take arbitrarily long under 
some circumstances.  If you want to use atomic ops to close the race, you need 
to use barriers.

-- Chris
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists