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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 9 Feb 2016 10:02:36 +0100
From:	Torsten Duwe <duwe@....de>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Petr Mladek <pmladek@...e.com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Jiri Kosina <jkosina@...e.cz>, Miroslav Benes <mbenes@...e.cz>,
	Jessica Yu <jeyu@...hat.com>, linuxppc-dev@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org, live-patching@...r.kernel.org
Subject: Re: [PATCH v7 04/10] ppc64 ftrace_with_regs configuration variables

On Mon, Feb 08, 2016 at 10:49:28AM -0500, Steven Rostedt wrote:
> On Mon, 8 Feb 2016 16:23:06 +0100
> Petr Mladek <pmladek@...e.com> wrote:
> 
> > >From 2b0fcb678d7720d03f9c9f233b61ed9ed4d420b3 Mon Sep 17 00:00:00 2001  
> > From: Petr Mladek <pmladek@...e.com>
> > Date: Mon, 8 Feb 2016 16:03:03 +0100
> > Subject: [PATCH] ftrace: Allow to explicitly disable the build of the dynamic
> >  ftrace with regs
> > 
> > This patch allows to explicitly disable
> > CONFIG_DYNAMIC_FTRACE_WITH_REGS. We will need to do so on
> > PPC with a broken gcc. This situation will be detected at
> > buildtime and could not be handled by Kbuild automatically.
> 
> Wait. Can it be detected at build time? That is, does it cause a build

Yes, I wrote a test to detect it at build time. It is similar to "asm goto"
and part of the v7 patch set.

> error? If so, then you can have Kbuild automatically detect this and
> set the proper value. We do this with 'asm goto'. There's tricks in the
> build system that can change the configs based on if a compiler is
> broken or not.

Please clarify. All I could find is Makefile magic that does it. AFAICS
This runs _after_ Kconfig.

But what I'd like to see is to offer the user the full choice, where possible,
e.g.

Kernel Tracing ...
0) none
1) static FTRACE
2) DYNAMIC_FTRACE
3) DYNAMIC_FTRACE_WITH_REGS

Can such a test be used to simply reduce these options?
With Petr's patch, it comes quite close to the above, and if you select "3"
and your compiler is broken, compilation will fail. For "2", it will just do
the right thing ( fall back to plain "-pg" ).

Without Petr's patch you have *no* choice between "2" and "3".
(That's what I'd call a bug :)

So, the question is, can such a test be used to provide _input_ to
"make config" ? I can see the "env=" mechanism, but it seems not to be used
very heavily. That would then be a prerequisite to all "make *config".
Even if it can provide this input, you can still not choose between 2 and 3
where both are available.

	Torsten

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ