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: <20080427183631.GC23828@infradead.org>
Date:	Sun, 27 Apr 2008 14:36:31 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Adrian Bunk <bunk@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.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 08:31:31PM +0200, Sam Ravnborg wrote:
> The tendency is that gcc inline *more than we whish* - not less.
> Which is why we have noinline - to cover the cases where we do not
> want stuff inlined.

Which is exactly the wrong way around.  noinline should be the default.
But that's probaby no fixable without touching gcc or doing ugly hacks
as in xfs.

> What the patch in question does is to make a difference
> between always_inle and inline.
> Previously they were the same. With the patch applied and
> with a gcc > 4.0 inline is now a hint.
> 
> Did you actually read the patch?

Yes.  As as I said I think having them the same, or rather only
having one of them makes more sense than having a hint in addition to
force.

> If you read the patch you will see that the architectures that
> want to enable this has to do an explicit HAVE_CC_INLINE_HINT
> so powerpc is not impacted by this until they request it.
> Exactly the reason why this was not widely enabled in the
> first place (but implemnted in a too x86 specific way).

Yes, and that part of your patch is a good thing, and makes it at
least sensible unlike ingos.  The patch in this mail is the one
we should probably go for short term, although the right way to
sort it out is the long one, aka goign through all users of inline
and deciding what they really want.

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