linux-kernel - Re: [PATCH 1/24] make atomic_read() behave consistently on alpha

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: <f571b4f940ec48e7984c7cdad6ac64f5@kernel.crashing.org>
Date:	Fri, 10 Aug 2007 01:02:13 +0200
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Chris Snook <csnook@...hat.com>
Cc:	paulmck@...ux.vnet.ibm.com, heiko.carstens@...ibm.com,
	horms@...ge.net.au, linux-kernel@...r.kernel.org,
	rpjday@...dspring.com, ak@...e.de, netdev@...r.kernel.org,
	cfriesen@...tel.com, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, jesper.juhl@...il.com,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-arch@...r.kernel.org, zlynx@....org, schwidefsky@...ibm.com,
	davem@...emloft.net, wensong@...ux-vs.org, wjiang@...ilience.com
Subject: Re: [PATCH 1/24] make atomic_read() behave consistently on alpha

>>>> So, why not use the well-defined alternative?
>>> Because we don't need to, and it hurts performance.
>> It hurts performance by implementing 32-bit atomic reads in assembler?
>
> No, I misunderstood the question.  Implementing 32-bit atomic reads in 
> assembler is redundant, because any sane compiler, *particularly* and 
> optimizing compiler (and we're only in this mess because of optimizing 
> compilers)

Oh please, don't tell me you don't want an optimising compiler.
And if you _do_ want one, well you're in this mess because you
chose C as implementation language and C has some pretty strange
rules.  Trying to use not-all-that-well-defined-and-completely-
misunderstood features of the language doesn't make things easier;
trying to use something that isn't even part of the language and
that your particular compiler originally supported by accident,
and that isn't yet an officially supported feature, and that on
top of it all has a track record of problems -- well it makes me
wonder if you're in this game for fun or what.

>  will give us that automatically without the assembler.

No, it does *not* give it to you automatically; you have to do
either the asm() thing, or the not-defined-at-all *(volatile *)&
thing.

> Yes, it is legal for a compiler to violate this assumption.  It is 
> also legal for us to refuse to maintain compatibility with compilers 
> that suck this badly.

So that's rm include/linux/compiler-gcc*.h then.  Good luck with
the intel compiler, maybe it works more to your liking.

Segher

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