On Wed, Feb 24, 2016 at 08:40:54AM +0100, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > Hi Ingo,
> >
> > On Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar wrote:
> > > So I tried out this latest stacktool series and it looks mostly good for
> > > an
> > > upstream merge.
> > >
> >
* Josh Poimboeuf wrote:
> Hi Ingo,
>
> On Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar wrote:
> > So I tried out this latest stacktool series and it looks mostly good for an
> > upstream merge.
> >
> > To help this effort move forward I've applied the preparatory/fix patches
> > that a
Em Tue, Feb 23, 2016 at 09:07:55AM -0600, Josh Poimboeuf escreveu:
> I think 'objtool' is searchable enough. And I also like the fact that
Yeah, agreed, there is even documentation available for it already:
http://docs.bvstools.com/home/objtool
> its name at least gives you an idea of what it d
On Tue, Feb 23, 2016 at 11:27:17AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar escreveu:
> > The fact that 'stacktool' already checks about assembly details like
> > __ex_table[]
> > shows that my review feedback early iterations of this series,
Hi Ingo,
On Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar wrote:
> So I tried out this latest stacktool series and it looks mostly good for an
> upstream merge.
>
> To help this effort move forward I've applied the preparatory/fix patches
> that are
> part of this series to tip:x86/debug
Em Tue, Feb 23, 2016 at 09:14:06AM +0100, Ingo Molnar escreveu:
> The fact that 'stacktool' already checks about assembly details like
> __ex_table[]
> shows that my review feedback early iterations of this series, that the
> 'stacktool' name is too specific, was correct.
>
> We really need to
So I tried out this latest stacktool series and it looks mostly good for an
upstream merge.
To help this effort move forward I've applied the preparatory/fix patches that
are
part of this series to tip:x86/debug - that's 26 out of 31 patches. (I've
propagated all the acks that the latest subm
On Mon, Feb 15, 2016 at 08:56:21AM -0800, Linus Torvalds wrote:
> On Feb 15, 2016 8:31 AM, "Josh Poimboeuf" wrote:
> >
> > So is the goal to optimize for size? If I replace the calls to
> > __preempt_schedule[_notrace]() with real C calls and remove the thunks,
> > it only adds about 2k to vmlinu
> > There are two ways to fix the warnings:
> >
> > 1. get rid of the thunks and call the C functions directly; or
>
> No. Not until gcc learns about per-function callibg conventions (so that it
> can
> be marked as not clobbering registers).
It does already for static functions in 5.x (with -fi
On Mon, Feb 15, 2016 at 10:31:34AM -0600, Josh Poimboeuf wrote:
> On Fri, Feb 12, 2016 at 09:10:11PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 12, 2016 at 12:32:06PM -0600, Josh Poimboeuf wrote:
> > > What I actually see in the listing is:
> > >
> > > decl__percpu_prefix:__preempt_count
>
On Fri, Feb 12, 2016 at 09:10:11PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 12:32:06PM -0600, Josh Poimboeuf wrote:
> > What I actually see in the listing is:
> >
> > decl__percpu_prefix:__preempt_count
> > je 1f:
> >
> > 1:
> > call___preempt_sched
On Fri, Feb 12, 2016 at 12:32:06PM -0600, Josh Poimboeuf wrote:
> What I actually see in the listing is:
>
> decl__percpu_prefix:__preempt_count
> je 1f:
>
> 1:
> call___preempt_schedule
>
> So it puts the "call ___preempt_schedule" in the slow path.
Ah
On Fri, Feb 12, 2016 at 12:32:06PM -0600, Josh Poimboeuf wrote:
> On Fri, Feb 12, 2016 at 06:10:37PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 12, 2016 at 08:45:43AM -0600, Josh Poimboeuf wrote:
> > > On Fri, Feb 12, 2016 at 11:36:24AM +0100, Jiri Slaby wrote:
> > >
> > > This seems like a real
On Fri, Feb 12, 2016 at 06:10:37PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 08:45:43AM -0600, Josh Poimboeuf wrote:
> > On Fri, Feb 12, 2016 at 11:36:24AM +0100, Jiri Slaby wrote:
> >
> > This seems like a real frame pointer bug caused by the following line in
> > arch/x86/include/as
On Fri, Feb 12, 2016 at 08:45:43AM -0600, Josh Poimboeuf wrote:
> On Fri, Feb 12, 2016 at 11:36:24AM +0100, Jiri Slaby wrote:
>
> This seems like a real frame pointer bug caused by the following line in
> arch/x86/include/asm/preempt.h:
>
> # define __preempt_schedule() asm ("call ___preempt_sc
On Fri, Feb 12, 2016 at 11:36:24AM +0100, Jiri Slaby wrote:
> On 01/21/2016, 11:49 PM, Josh Poimboeuf wrote:
> > This is v16 of the compile-time stack metadata validation patch set,
> > along with proposed fixes for most of the warnings it found. It's based
> > on the tip/master branch.
>
> Hi,
>
On 02/12/2016, 11:36 AM, Jiri Slaby wrote:
> It there some compilation flag missing? -f flags when compiling that file are:
> -falign-jumps=1
> -falign-loops=1
> -fconserve-stack
> -fno-asynchronous-unwind-tables
> -fno-common
> -fno-delete-null-pointer-checks
> -fno-inline-functions-called-once
>
On 01/21/2016, 11:49 PM, Josh Poimboeuf wrote:
> This is v16 of the compile-time stack metadata validation patch set,
> along with proposed fixes for most of the warnings it found. It's based
> on the tip/master branch.
Hi,
with this config:
https://github.com/openSUSE/kernel-source/blob/master/
On Fri, Jan 22, 2016 at 02:40:35PM -0600, Chris J Arges wrote:
> On Fri, Jan 22, 2016 at 01:14:47PM -0600, Josh Poimboeuf wrote:
> > On Fri, Jan 22, 2016 at 11:43:48AM -0600, Chris J Arges wrote:
> > > On Thu, Jan 21, 2016 at 04:49:04PM -0600, Josh Poimboeuf wrote:
> > > > This is v16 of the compil
On Fri, Jan 22, 2016 at 01:14:47PM -0600, Josh Poimboeuf wrote:
> On Fri, Jan 22, 2016 at 11:43:48AM -0600, Chris J Arges wrote:
> > On Thu, Jan 21, 2016 at 04:49:04PM -0600, Josh Poimboeuf wrote:
> > > This is v16 of the compile-time stack metadata validation patch set,
> > > along with proposed f
On Fri, Jan 22, 2016 at 11:43:48AM -0600, Chris J Arges wrote:
> On Thu, Jan 21, 2016 at 04:49:04PM -0600, Josh Poimboeuf wrote:
> > This is v16 of the compile-time stack metadata validation patch set,
> > along with proposed fixes for most of the warnings it found. It's based
> > on the tip/maste
On Thu, Jan 21, 2016 at 04:49:04PM -0600, Josh Poimboeuf wrote:
> This is v16 of the compile-time stack metadata validation patch set,
> along with proposed fixes for most of the warnings it found. It's based
> on the tip/master branch.
>
Josh,
Looks good, with my config [1] I do still get a few
This is v16 of the compile-time stack metadata validation patch set,
along with proposed fixes for most of the warnings it found. It's based
on the tip/master branch.
v15 can be found here:
https://lkml.kernel.org/r/cover.1450442274.git.jpoim...@redhat.com
For more information about the motiv
23 matches
Mail list logo
