linux-kernel - Re: [PATH -mm -v2] Fix a race condtion of oops_in

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: <490F468B.4040602@redhat.com>
Date:	Mon, 03 Nov 2008 13:44:27 -0500
From:	Chris Snook <csnook@...hat.com>
To:	Huang Ying <ying.huang@...el.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATH -mm -v2] Fix a race condtion of oops_in_progress

Huang Ying wrote:
> On Sat, 2008-11-01 at 00:42 +0800, Chris Snook wrote:
>> 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.
> 
> As far as I know, barriers don't cause changes to be visible on other
> CPUs faster too. It just guarantees corresponding operations after will
> not get executed until that before have finished. And, I don't think we
> need make changes to be visible on other CPUs faster.

You're correct that barrier() has no impact on other CPUs.  wmb() and rmb() do. 
  If we don't need to make changes visible any faster, what's the point in using 
atomic_set()?  It's not any less racy.  atomic_inc() and atomic_dec() would be 
less racy, but you're not using those.

-- Chris
--
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/