linux-kernel - Re: [PATCH] prepare kconfig inline optimization for all architectures

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: <20080427183252.GB23828@infradead.org>
Date:	Sun, 27 Apr 2008 14:32:52 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Sam Ravnborg <sam@...nborg.org>, Adrian Bunk <bunk@...nel.org>,
	linux arch <linux-arch@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH] prepare kconfig inline optimization for all
	architectures

On Sun, Apr 27, 2008 at 11:24:28AM -0700, Linus Torvalds wrote:
> The thing is, the "inline" vs "always_inline" thing _could_ make sense, 
> but sadly doesn't much.
> 
> Part of it is that gcc imnsho inlines too aggressively anyway in the 
> absense of "inline", so there's no way "inline" can mean "you might 
> inline" this, because gcc will do that anyway even without it. As a 
> result, in _practice_ "inline" and "always_inline" end up being very close 
> to each other - perhaps more so than they should.

Yes, absolutely.   In recent gcc versions it's in fact so bad that xfs
had to add a hack to mark every function not explicitly marker inline
noinline because otherwise gcc would inline gazillions of big functions
which combines with it's horrible liveness analysis led to enormous
stack useage.  (I think the liveness part is getting better these days
to be fair)

> It will take time before we've sorted out all the fall-out, because I bet 
> there is still code out there that _should_ use __always_inline, but 
> doesn't.

Given that __always_inline only shows up in non-x86 arch code in
homeopathic quantity it's a fair bet that there's a lot of breakage
waiting there.  Which was one of the initial complains about the way
it's done..
--
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/