linux-kernel - Re: [PATCH 4/5] kgdb: Use atomic operators which use barriers

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: <20100403160829.GA1390@n2100.arm.linux.org.uk>
Date:	Sat, 3 Apr 2010 17:08:29 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jason Wessel <jason.wessel@...driver.com>,
	Will Deacon <will.deacon@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	kgdb-bugreport@...ts.sourceforge.net, linux-arm@...r.kernel.org
Subject: Re: [PATCH 4/5] kgdb: Use atomic operators which use barriers

On Fri, Apr 02, 2010 at 04:24:57PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 2 Apr 2010, Russell King - ARM Linux wrote:
> > 
> > Actually, in future threads you end up agreeing with my position...
> 
> I always agreed that it was not a memory barrier.
> 
> In fact, the commit that extended on the "volatile-considered-harmful" 
> patch from you has this quote from me in the commit logs:
> 
>     Linus sayeth:
>     
>     : I don't think it was ever the intention that it would be seen as anything
>     : but a compiler barrier, although it is obviously implied that it might
>     : well perform some per-architecture actions that have "memory barrier-like"
>     : semantics.
>     :
>     : After all, the whole and only point of the "cpu_relax()" thing is to tell
>     : the CPU that we're busy-looping on some event.
>     :
>     : And that "event" might be (and often is) about reading the same memory
>     : location over and over until it changes to what we want it to be.  So it's
>     : quite possible that on various architectures the "cpu_relax()" could be
>     : about making sure that such a tight loop on loads doesn't starve cache
>     : transactions, for example - and as such look a bit like a memory barrier
>     : from a CPU standpoint.
>     :
>     : But it's not meant to have any kind of architectural memory ordering
>     : semantics as far as the kernel is concerned - those must come from other
>     : sources.
> 
> which I think is pretty clear. 
> 
> But that quote seems to be the one where you then think I "agree" with 
> you.

Yet again you read something into what I say that wasn't there.

Wait for me to return from holiday, as I said, and I'll respond further.
--
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/