linux-kernel - Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

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: <Pine.LNX.4.64.0612081221180.3516@woody.osdl.org>
Date:	Fri, 8 Dec 2006 12:34:27 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Russell King <rmk+lkml@....linux.org.uk>
cc:	David Howells <dhowells@...hat.com>,
	Christoph Lameter <clameter@....com>,
	Nick Piggin <nickpiggin@...oo.com.au>, akpm@...l.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch
 doesn't support it

On Fri, 8 Dec 2006, Russell King wrote:
>> 
> The only instructions which affect the exclusive access state are the
> exclusive access instructions themselves.

Not according to the docs I found.

The ARM1136 manual explicitly states that any attempt to modify that 
address clears the tag (for shared memory regions, by _any_ CPU, and for 
nonshared regions by _that_ CPU).

And btw, that _has_ to be true, because otherwise the whole ldrex/strex 
sequence would be totally unusable as a way to do atomic bit operations on 
UP in the presense of interrupts (well, you could have a clrex instruction 
in the interrupt handler, but as far as I know you don't, so that seems to 
be a moot point - you only seem to do it in __switch_to).

In other words, I _really_ think you're wrong. 

So the very code sequence you quote MUST NOT WORK the way you claim it 
does. And not only that, since the granularity of the mark is not just for 
the bytes in question, but potentially apparently up to 128 bytes, any 
store even _close_ to the memory you had xclusive access to will break the 
exclusive access.

Really, Russell. Your stance makes no sense. It doesn't make any sense 
from a microarchitectural standpoint (it's not how you'd normally 
implement these things), but it ALSO makes no sense from the way you 
already use those instructions (as a way to protect against other 
processors - including your own - touching that word).

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