linux-kernel - Re: current_thread_info() not respecting program order with gcc 4.8.x

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]

Date:	Thu, 21 Nov 2013 16:17:12 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alexander Holler <holler@...oftware.de>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Jakub Jelinek <jakub@...hat.com>,
	Richard Henderson <rth@...ddle.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Will Deacon <will.deacon@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	lttng-dev@...ts.lttng.org, Nathan Lynch <Nathan_Lynch@...tor.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Luis Lozano <llozano@...omium.org>,
	Bhaskar Janakiraman <bjanakiraman@...omium.org>,
	Han Shen <shenhan@...omium.org>
Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x

On Thu, Nov 21, 2013 at 3:18 PM, Alexander Holler <holler@...oftware.de> wrote:
>
> Sorry, that I still disagree.

Why? You're wrong.

I mean, anybody who disagrees with me is pretty much wrong just on
pure principles, but I actually mean a deeper kind of wrong than that.
I mean a very objective "you're clearly wrong".

> I try to describe it more clearly why I still think that the problem might
> be because of that const declaration.

.. and then you use a totally bogus example to try to "prove" your point.

The example you use has nothing to do with what the function in case
actually does.

The function we actually talk about RETURNS THE SAME VALUE EVERY TIME
IT IS CALLED, regardless of arguments (which it doesn't happen to
have). Ergo, it is "const".

Your example is pure and utter shit, since you still get confused
about what is actually const and what isn't.

The fact is, "current_thread_info()" returns a constant value (within
that execution context). Always has, always will. It fundamentally HAS
to, since that is - by definition - what that "thread info" is all
about.

The dereference (your "->somewhere_local") happens *outside* that
const function scope. And no, that dereference is not const. But
that's not what we tell gcc, and never has been.

So don't try to confuse things by trying to make
"current_thread_info()" something it isn't.

Basically, your whole argument boils down to "if the function did
something else than what it does, then it wouldn't be const, so we
shouldn't mark it const". But that argument is BULLSHIT, because the
fact is, the function *doesn't* do what you try to claim it does.

               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/