linux-kernel - Re: [PATCH 2/2]: atomic_t: Remove volatile from atomic

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: <20100521060600.GM2516@laptop>
Date:	Fri, 21 May 2010 16:06:00 +1000
From:	Nick Piggin <npiggin@...e.de>
To:	David Miller <davem@...emloft.net>
Cc:	paulmck@...ux.vnet.ibm.com, torvalds@...ux-foundation.org,
	anton@...ba.org, akpm@...ux-foundation.org, willy@...ux.intel.com,
	benh@...nel.crashing.org, paulus@...ba.org,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2]: atomic_t: Remove volatile from atomic_t definition

On Thu, May 20, 2010 at 10:54:54PM -0700, David Miller wrote:
> From: Nick Piggin <npiggin@...e.de>
> Date: Fri, 21 May 2010 15:27:46 +1000
> 
> > Hmm, I'm missing something. David, back up a second, as far as I can see,
> > with Anton's patches, atomic_read() *is* effectively just ACCESS_ONCE()
> > now. Linus pointed out that header tangle is the reason not to just use
> > the macro.
> 
> My bad, I was under the impression that the proposal was to remove
> volatile usage and also not even do ACCESS_ONCE() in atomic_read().
> 
> And then explicitly annotate call sits that actually need the
> ACCESS_ONCE() semantic.

Ah ok, no. I see ACCESS_ONCE is a fundamental ("obvious") property of
atomic_read, so we definitely should keep it, even if we could audit
everyone.

Actually, I bet we have a lot of bugs there with loading integers and
pointers atomically, where the code assumes the loaded value will not
be reloaded by the compiler, because it is an easy thing to assume.

atomic_read_light could be useful though, for sure.

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