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: <20150421074212.GA25081@gmail.com>
Date:	Tue, 21 Apr 2015 09:42:12 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Hagen Paul Pfeifer <hagen@...u.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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

* Hagen Paul Pfeifer <hagen@...u.net> wrote:

> On 20 April 2015 at 23:56, Borislav Petkov <bp@...en8.de> wrote:
> 
> > Hmm, that must be config-specific as doing
> >
> > objdump -D vmlinux | grep -i "atomic_add"
> >
> > here gives me only "drm_atomic_add_affected_connectors" matches.
> >
> > It probably gets inlined here always...
> 
> Probably, the config is allyesconfig minus trace/kernel adress 
> sanitizer and gcov related options.

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

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.

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.

But I'm not against your patch either. Linus, what's your preference?

Thanks,

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