linux-kernel - Re: CONFIG_OPTIMIZE

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:	Fri, 14 Nov 2008 13:46:16 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Hugh Dickins <hugh@...itas.com>
cc:	Ingo Molnar <mingo@...e.hu>, Nick Piggin <nickpiggin@...oo.com.au>,
	linux-kernel@...r.kernel.org
Subject: Re: CONFIG_OPTIMIZE_INLINING fun

On Fri, 14 Nov 2008, Hugh Dickins wrote:

> What I was intending anyway, quite independently of the INLINING
> issue, was changing those and some others to VM_BUG_ONs, which are
> intended really for VM testers rather than for distros to turn on.
> (Though perhaps Nick has shifted his position on that.)

Some distros have a bad habit of turning these on for production releases.

> That is indeed the orthodoxy.  I've never been so sold on it as most
> (there are cases when inlines give superior typechecking, but often
> the use of the macro will catch wrong types anyway).  But I suspect
> it's irrelevant, that changing those functions to macros would not
> actually have any effect on the problem - that's what we've often
> been assured, anyway, that the compiler nowadays does inlines as
> efficiently as the preprocessor does macros.  I do wonder though.

Maybe try to compare it with a old kernel that still has the page flags
macros? That way we would have a testcase useful for bringing to the
attention of the gcc people.

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