linux-kernel - Re: [PATCH RFC] x86: enforce inlining for atomics

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: <CAPh34mf_a-Fr3sHJD_h-TBqbD7D0W=HyfToVOqo200wt0MOo-A@mail.gmail.com>
Date:	Tue, 21 Apr 2015 12:56:53 +0200
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Borislav Petkov <bp@...en8.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH RFC] x86: enforce inlining for atomics

On 21 April 2015 at 09:42, Ingo Molnar <mingo@...nel.org> wrote:

Hey Ingo, Peter, Boris,

the environment is Debian with gcc version 4.9.2. I tried to reproduce
the results under Ubuntu 14.04 but their version (4.8.2!) seems fine:
at max one duplicate for each atomic_* function.

> So the thing is that allyesconfig turns on -Os:
>
>    CONFIG_CC_OPTIMIZE_FOR_SIZE=y
>
> which is known to make bad decisions in other areas as well ...

I can recompile with "CONFIG_CC_OPTIMIZE_FOR_SIZE=n" and check the
results again!?

> If -Os does such bad inlining decisions (and the inlining examples you
> cited are horrible!) then I guess a lot of the other 'inline'
> functions are handled by it badly as well.

Assumption is correct - I see duplicates all over the place.

> I'm not sure we should start fighting the compiler: if a compiler does
> not take 'inline' seriously then the solution is to use another
> compiler, or at least to use different compiler flags.
>
> If inlining decisions are bad even with saner compiler options then we
> can use __always_inline, and we actually do that for locking
> primitives and some other low level primitives: which are typically
> larger than atomics, so even reasonable compilers might uninline them.

Probably we should check this on a wider gcc front! If the behavior is an
exception, or is this common behavior?

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