The various functions involved in dumping the stack all do similar
things with regard to getting the stack pointer and the frame pointer
based on the regs and task arguments. Create helper functions to
do that instead.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stacktrace.h | 39
All previous users of dump_trace() have been converted to use the new
unwind interfaces, so we can remove it.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stacktrace.h | 38 +
arch/x86/kernel/dumpstack_32.c| 35
arch/x86/kernel/dumpstack_64
decode it.
Suggested-by: Andy Lutomirski
Signed-off-by: Josh Poimboeuf
---
arch/x86/entry/calling.h | 21
arch/x86/entry/entry_64.S | 7 ++-
arch/x86/include/asm/unwind.h | 11 +++
arch/x86/kernel/unwind_frame.c | 44 +++
Convert save_stack_trace_*() to the new unwinder. dump_trace() has been
deprecated.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/stacktrace.c | 74 +---
1 file changed, 29 insertions(+), 45 deletions(-)
diff --git a/arch/x86/kernel/stacktrace.c b
R13: R14: 88007877 R15: 880079947200
[] ? __clear_user+0x42/0x70
[] ? __clear_user+0x23/0x70
[] clear_user+0x2b/0x40
...
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/dumpstack.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/k
Convert oprofile's x86_backtrace() to the new unwinder. dump_trace()
has been deprecated.
Cc: Robert Richter
Cc: oprofile-l...@lists.sf.net
Signed-off-by: Josh Poimboeuf
---
arch/x86/oprofile/backtrace.c | 42 +++---
1 file changed, 19 insertions(+
Change printk_stack_address() to be useful when called by an unwinder
outside the context of dump_trace().
Specifically:
- printk_stack_address()'s 'data' argument is always used as the log
level string. Make that explicit.
- Call touch_nmi_watchdog().
Signed-off-by:
ack anyway, so it doesn't matter if they're comparing the
stack pointer against the percpu irq stack pointer from this CPU or
another one: either way it won't match.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/dumpstack_32.c | 14 ++
arch/x86/k
Convert perf_callchain_kernel() to the new unwinder. dump_trace() has
been deprecated.
Signed-off-by: Josh Poimboeuf
---
arch/x86/events/core.c | 32 +---
1 file changed, 9 insertions(+), 23 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
vl() don't need
to provide the 'bp' argument. The unwinder already finds the relevant
frame pointer by unwinding until it reaches the first frame after the
provided stack pointer.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stacktrace.h | 10
he empty string (aka KERN_CONT) and replace it with
KERN_DEFAULT.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/dumpstack.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 198dc9e..0eedb01 100644
-
ses.
Suggested-by: Andy Lutomirski
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/unwind.h | 80 +
arch/x86/kernel/Makefile | 6 +++
arch/x86/kernel/unwind_frame.c | 89 ++
arch/x86/kernel/unwind_guess.
When starting the dump of an exception stack, it shows "<>" instead
of "". print_trace_stack() already adds brackets, no need to add
them again.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/dumpstack_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
When calling show_stack_log_lvl() or dump_trace() with a regs argument,
providing a stack pointer or frame pointer is redundant.
Signed-off-by: Josh Poimboeuf d
---
arch/x86/kernel/dumpstack.c| 2 +-
arch/x86/kernel/dumpstack_32.c | 2 +-
arch/x86/kernel/dumpstack_64.c | 5 +
arch/x86
For reasons unknown, the x86_64 irq stack starts at an offset 64 bytes
from the end of the page. At least make that explicit.
FIXME: Can we just remove the 64 byte gap? If not, at least document
why.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/page_64_types.h | 19
in_exception_stack() does some bad, bad things just so the unwinder can
print different values for different areas of the debug exception stack.
There's no need to clarify where exactly on the stack it is. Just print
"#DB" and be done with it.
Signed-off-by: Josh Poimboeuf
---
(type,
size, next stack pointer, description string) are scattered around in
various places throughout the stack dump code.
Encapsulate all that information in a single place with a new stack_info
struct and a get_stack_info() interface.
Signed-off-by: Josh Poimboeuf
---
arch/x86/events/core.c
There are a bewildering array of options for dumping the stack.
Simplify things a little by removing show_trace(), which is unused.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/kdebug.h | 2 --
arch/x86/kernel/dumpstack.c | 6 --
2 files changed, 8 deletions(-)
diff --git a
inder code, console stack dump code, and stack
metadata analysis code are all better separated so that changing one
of them shouldn't have much of an impact on any of the others.
Josh Poimboeuf (19):
x86/dumpstack: remove show_trace()
x86/dumpstack: add get_stack_pointer() and get_fra
In addition to fixing these bugs, convert print_ftrace_graph_addr() to a
more generic function which can be used outside of dump_trace()
callbacks.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stacktrace.h | 13 ++
arch/x86/kernel/dumpstack.c | 50 +--
On Fri, Jul 22, 2016 at 06:49:01AM +0900, Byungchul Park wrote:
> On Thu, Jul 21, 2016 at 04:21:52PM -0500, Josh Poimboeuf wrote:
> > Convert show_trace_log_lvl() to the new unwinder. dump_trace() has been
> > deprecated.
> >
> > show_trace_log_lvl() is special com
On Thu, Jul 21, 2016 at 02:56:52PM -0700, Andy Lutomirski wrote:
> On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> > When calling show_stack_log_lvl() or dump_trace() with a regs argument,
> > providing a stack pointer or frame pointer is redundant.
> >
>
&
On Thu, Jul 21, 2016 at 03:01:10PM -0700, Andy Lutomirski wrote:
> On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> > For reasons unknown, the x86_64 irq stack starts at an offset 64 bytes
> > from the end of the page. At least make that explicit.
>
> This is a chan
On Thu, Jul 21, 2016 at 03:32:32PM -0700, Andy Lutomirski wrote:
> On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> > Now that we can find pt_regs registers in the middle of the stack due to
> > an interrupt or exception, we can print them. Here's wh
On Fri, Jul 22, 2016 at 09:23:02AM +1000, Stephen Rothwell wrote:
> Hi Arnaldo,
>
> On Thu, 21 Jul 2016 10:12:48 -0300 Arnaldo Carvalho de Melo
> wrote:
> >
> > Em Thu, Jul 21, 2016 at 09:29:50AM +1000, Stephen Rothwell escreveu:
> > > Hi Arnaldo,
> > >
> > > On Tue, 19 Jul 2016 23:52:02 -0300
On Thu, Jul 21, 2016 at 10:13:03PM -0700, Andy Lutomirski wrote:
> On Thu, Jul 21, 2016 at 8:30 PM, Josh Poimboeuf wrote:
> > On Thu, Jul 21, 2016 at 03:32:32PM -0700, Andy Lutomirski wrote:
> >> On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf
> >> wrote:
> >
On Thu, Jul 21, 2016 at 11:34:25AM -0700, Kees Cook wrote:
> On Wed, Jul 20, 2016 at 11:52 PM, Michael Ellerman
> wrote:
> > Kees Cook writes:
> >
> >> diff --git a/mm/usercopy.c b/mm/usercopy.c
> >> new file mode 100644
> >> index ..e4bf4e7ccdf6
> >> --- /dev/null
> >> +++ b/mm/user
On Fri, Jul 22, 2016 at 11:37:39AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh Poimboeuf escreveu:
> > On Fri, Jul 22, 2016 at 09:23:02AM +1000, Stephen Rothwell wrote:
> > > It just looks like objtool was not written with cross compila
On Fri, Jul 22, 2016 at 04:36:55PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
> > On Fri, Jul 22, 2016 at 11:37:39AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh
On Fri, Jul 22, 2016 at 02:46:10PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 22, 2016 at 8:57 AM, Josh Poimboeuf wrote:
> > On Thu, Jul 21, 2016 at 10:13:03PM -0700, Andy Lutomirski wrote:
> >> On Thu, Jul 21, 2016 at 8:30 PM, Josh Poimboeuf
> >> wrote:
> >
On Fri, Jul 22, 2016 at 04:18:04PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 22, 2016 at 3:20 PM, Josh Poimboeuf wrote:
> > On Fri, Jul 22, 2016 at 02:46:10PM -0700, Andy Lutomirski wrote:
> >> On Fri, Jul 22, 2016 at 8:57 AM, Josh Poimboeuf
> >> wrote:
> >
On Fri, Jul 22, 2016 at 04:26:46PM -0700, Andy Lutomirski wrote:
> On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> > valid_stack_ptr() is buggy: it assumes that all stacks are of size
> > THREAD_SIZE, which is not true for exception stacks. So the
> > walk_stack() c
On Fri, Jul 22, 2016 at 04:39:00PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 22, 2016 at 4:30 PM, Josh Poimboeuf wrote:
> > On Fri, Jul 22, 2016 at 04:18:04PM -0700, Andy Lutomirski wrote:
> >> On Fri, Jul 22, 2016 at 3:20 PM, Josh Poimboeuf
> >> wrote:
> >
On Fri, Jul 22, 2016 at 05:31:47PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 22, 2016 at 5:22 PM, Linus Torvalds
> wrote:
> >
> > So without having yet looked at the code, I want people to understand
> > that to a very real degree, the stack tracer that the *oopsing* code
> > (ie what all the us
On Sat, Jul 23, 2016 at 02:39:52PM +0900, Linus Torvalds wrote:
> On Sat, Jul 23, 2016 at 2:35 PM, Josh Poimboeuf wrote:
> >
> > While doing the scanning and printing, it does call the frame pointer
> > unwinder in parallel, but like before, that's *only* used to det
On Fri, Jul 22, 2016 at 04:52:10PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 22, 2016 at 4:26 PM, Andy Lutomirski wrote:
> > On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> >> valid_stack_ptr() is buggy: it assumes that all stacks are of size
> >> THREAD_
On Fri, Jul 22, 2016 at 05:15:03PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 22, 2016 at 4:54 PM, Josh Poimboeuf wrote:
> >> > +static bool in_hardirq_stack(unsigned long *stack, struct stack_info
> >> > *info,
> >> > +
On Fri, Sep 16, 2016 at 06:59:22PM -0700, Linus Torvalds wrote:
> On Fri, Sep 16, 2016 at 5:42 PM, Josh Poimboeuf wrote:
> > On Fri, Sep 16, 2016 at 05:09:15PM -0700, Linus Torvalds wrote:
> >> On Fri, Sep 16, 2016 at 2:26 PM, Josh Poimboeuf
> >> wrote:
> >&
On Mon, Sep 19, 2016 at 12:15:42PM -0700, Linus Torvalds wrote:
> On Mon, Sep 19, 2016 at 11:56 AM, Linus Torvalds
> wrote:
> >>
> >> The only working (and fast) approach I could come up with was an ugly
> >> hack. It assumes that start_kernel() is in init/main.c.
> >
> > That sounds entirely rea
On Mon, Sep 19, 2016 at 01:24:03PM -0700, Linus Torvalds wrote:
> On Mon, Sep 19, 2016 at 1:00 PM, Rabin Vincent wrote:
> >
> > Note that addr2line has localized strings, so the regex with the " at "
> > won't match for everyone unless you invoke addr2line with LANG=C.
>
> Ok, I'll make it match
On Mon, Sep 19, 2016 at 02:02:18PM -0700, Linus Torvalds wrote:
> On Mon, Sep 19, 2016 at 1:56 PM, Josh Poimboeuf wrote:
> > On Mon, Sep 19, 2016 at 01:24:03PM -0700, Linus Torvalds wrote:
> >>
> >> because I certainly hope there is always a space there.
> >
>
On Mon, Sep 19, 2016 at 09:58:39PM -0700, Kees Cook wrote:
> Hi,
>
> Al had asked me a couple weeks back what the ratio of const vs dynamic
> usercopying was. With Josh's cleanup and my fix-up to only call the
> hardened usercopy when non-const, I can actually gather these statistics
> on a build.
On Tue, Sep 20, 2016 at 08:01:02AM -0700, tip-bot for Josh Poimboeuf wrote:
> Commit-ID: e18bcccd1a4ecb41e99678e002ef833586185bf1
> Gitweb: http://git.kernel.org/tip/e18bcccd1a4ecb41e99678e002ef833586185bf1
> Author: Josh Poimboeuf
> AuthorDate: Fri, 16 Sep 2016 14
his end of stack convention continues to be followed in
the future).
- Printing all saved pt_regs on the stack during an oops/warning.
- Validating stacks in the livepatch consistency model.
Josh Poimboeuf (9):
x86/entry/head/32: use local labels
x86/entry/32: rename 'error_code'
calling into C.
Make it a real address by using the side effect of a call instruction to
push the instruction pointer on the stack.
Reviewed-by: Andy Lutomirski
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/head_64.S | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch
ectly when unwinding to x86 head code.
Head code is text code too, so mark it as such. This seems to match the
intent of other users of the _stext symbol, and it also seems consistent
with what other architectures are already doing.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/vmlinux.lds.
The 'error_code' label is awkwardly named, especially when it shows up
in a stack trace. Move it to its own local function and rename it to
'common_exception', analagous to the existing 'common_interrupt'.
This also makes related stack traces more sensible.
Signed-off-by: Josh Poimboeuf
---
arch/x86/entry/entry_32.S | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index deef561..f0a7444 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
which can be useful for the unwinder to verify the stack is
sane.
However, the boot CPU's idle "swapper" task doesn't follow that
convention. Fix that by starting its stack at a sizeof(pt_regs) offset
from the end of the stack page.
Signed-off-by: Josh Poimboeuf
---
arch/
There are two different pieces of code for starting a CPU: start_cpu0()
and the end of secondary_startup_64(). They're identical except for the
stack setup. Combine the common parts into a shared start_cpu()
function.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/head_64.S
On 32-bit, the initial idle stack calculation doesn't take into account
the TOP_OF_KERNEL_STACK_PADDING, making the stack end address
inconsistent with other tasks on 32-bit.
Reviewed-by: Andy Lutomirski
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/smpboot.c | 4 +---
1 file chang
is486().
Signed-off-by: Josh Poimboeuf
---
arch/x86/entry/entry_32.S | 55 ---
arch/x86/kernel/head_32.S | 32 +--
2 files changed, 44 insertions(+), 43 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
calling into C.
Fix that by changing the initial code jumps to calls. Also add infinite
loops after the calls to make it clear that the calls don't return, and
to hang if they do.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/head_32.S | 8 +---
1 file changed, 5 insertions(+), 3 dele
On Tue, Sep 20, 2016 at 05:57:16PM -0700, Andy Lutomirski wrote:
> On Sep 20, 2016 10:03 AM, "Josh Poimboeuf" wrote:
> >
> > Add the local label prefix to all non-function named labels in head_32.S
> > and entry_32.S. In addition to decluttering the symbol tab
On Tue, Sep 20, 2016 at 09:10:55PM -0400, Brian Gerst wrote:
> Dropping asmlinkage from schedule_tail() would be a better option if possible.
My understanding is that it's still needed for ia64. AFAICT, ia64
relies on schedule_tail() having the syscall_linkage function attribute.
>From the gcc ma
On Tue, Sep 20, 2016 at 10:25:16PM -0500, Josh Poimboeuf wrote:
> On Tue, Sep 20, 2016 at 09:10:55PM -0400, Brian Gerst wrote:
> > Dropping asmlinkage from schedule_tail() would be a better option if
> > possible.
>
> My understanding is that it's still needed for ia64.
On Tue, Sep 20, 2016 at 11:39:35PM -0700, Andy Lutomirski wrote:
> > And the ia64 entry code has some similar language:
> >
> > /*
> > * Invoke schedule_tail(task) while preserving in0-in7,
> > which may be needed
> > * in case a system call gets r
On Wed, Sep 21, 2016 at 01:47:22PM +0200, Petr Mladek wrote:
> The commit 66cc69e34e86a231 ("Fix: module signature vs tracepoints:
> add new TAINT_UNSIGNED_MODULE") updated module_taint_flags() to
> potentially print one more character. But it did not increase the
> size of the corresponding buffer
The 'error_code' label is awkwardly named, especially when it shows up
in a stack trace. Move it to its own local function and rename it to
'common_exception', analagous to the existing 'common_interrupt'.
This also makes related stack traces more sensible.
which can be useful for the unwinder to verify the stack is
sane.
However, the boot CPU's idle "swapper" task doesn't follow that
convention. Fix that by starting its stack at a sizeof(pt_regs) offset
from the end of the stack page.
Signed-off-by: Josh Poimboeuf
---
arch/
features:
- Detecting corrupt stacks in the unwinder (which will also be a force
for ensuring this end of stack convention continues to be followed in
the future).
- Printing all saved pt_regs on the stack during an oops/warning.
- Validating stacks in the livepatch consistency model.
Josh P
ectly when unwinding to x86 head code.
Head code is text code too, so mark it as such. This seems to match the
intent of other users of the _stext symbol, and it also seems consistent
with what other architectures are already doing.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/vmlinux.lds.
There are two different pieces of code for starting a CPU: start_cpu0()
and the end of secondary_startup_64(). They're identical except for the
stack setup. Combine the common parts into a shared start_cpu()
function.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/head_64.S
calling into C.
Make it a real address by using the side effect of a call instruction to
push the instruction pointer on the stack.
Reviewed-by: Andy Lutomirski
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/head_64.S | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch
calling into C.
Fix that by changing the initial code jumps to calls. Also add infinite
loops after the calls to make it clear that the calls don't return, and
to hang if they do.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/head_32.S | 8 +---
1 file changed, 5 insertions(+), 3 dele
On 32-bit, the initial idle stack calculation doesn't take into account
the TOP_OF_KERNEL_STACK_PADDING, making the stack end address
inconsistent with other tasks on 32-bit.
Reviewed-by: Andy Lutomirski
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/smpboot.c | 4 +---
1 file chang
Signed-off-by: Josh Poimboeuf
---
arch/x86/entry/entry_32.S | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index dae8684..82b55ef 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
is486().
Signed-off-by: Josh Poimboeuf
---
arch/x86/entry/entry_32.S | 43 ++-
arch/x86/kernel/head_32.S | 32
2 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32
On Sat, Jun 18, 2016 at 04:56:15PM -0400, Brian Gerst wrote:
> Add struct inactive_task_frame, which defines the layout of the stack for
> a sleeping process. For now, the only defined field is the BP register
> (frame pointer).
>
> Signed-off-by: Brian Gerst
Reviewed-by:
ernel/sched/core.c since it no longer produces an
objtool warning.
Otherwise it looks great:
Reviewed-by: Josh Poimboeuf
--
Josh
On Sat, Jun 18, 2016 at 04:56:18PM -0400, Brian Gerst wrote:
> thread_saved_pc() was using a completely bogus method to get the return
> address. Since switch_to() was previously inlined, there was no sane way
> to know where on the stack the return address was stored. Now with the
> frame of a s
; const char *prefix __maybe_unused)
> {
> run_syscall_benchmark();
>
> switch (bench_format) {
> case BENCH_FORMAT_DEFAULT:
> printf("print results in human-readable format\n");
> break;
> case BENCH_FORMAT_SIMP
On Mon, Jun 20, 2016 at 12:16:22PM -0700, Andy Lutomirski wrote:
> On Mon, Jun 20, 2016 at 11:00 AM, Josh Poimboeuf wrote:
>
> >
> > From: Josh Poimboeuf
> > Subject: [PATCH] perf: add 'perf bench syscall'
> >
> > Add a basic 'perf bench syscal
(objtool has to know all the global noreturn functions so it can follow
the control flow of any functions which call them. Unfortunately they
need to be hard-coded becuase there's not an automated way to detect
them.)
Reported-by: kbuild test robot
Signed-off-by: Josh Poimboeuf
---
tools/ob
On Fri, Sep 23, 2016 at 01:33:45PM -0700, Linus Torvalds wrote:
> Josh,
>
> the current F24 toolchain causes
>
> kernel/signal.o: warning: objtool: .altinstr_replacement+0x54:
> call without frame pointer save/setup
>
> during a regular allmodconfig build.
>
> Doing an objdump says:
>
> .
On Fri, Sep 23, 2016 at 02:06:03PM -0700, Linus Torvalds wrote:
> On Fri, Sep 23, 2016 at 1:33 PM, Linus Torvalds
> wrote:
> >
> > So this code is clearly missing the magic to tell gcc that the asm
> > needs a frame pointer.
>
> Independently of that, the objtool build seems racy or somehow
> fra
me
pointer setup, which breaks frame pointer convention and can result in a
bad stack trace.
Force a stack frame to be created before the call instruction by listing
the stack pointer as an output operand in the inline asm statement.
Reported-by: Linus Torvalds
Signed-off-by: Josh Poimboeuf
---
plies-current idiom
> entirely,
> these patches ensure that generic code explictly passes current to
> show_stack(), rather than relying on arch code to handle NULL.
This is a good step, though it would be really nice to fix this
tree-wide. Do you have any plans to do so?
Regardl
On Mon, Sep 26, 2016 at 01:49:14PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 23, 2016 at 02:19:04PM -0700, Linus Torvalds escreveu:
> > On Fri, Sep 23, 2016 at 2:16 PM, Josh Poimboeuf wrote:
> > >
> > > I just started seeing this problem today. I suspec
On Wed, Jul 27, 2016 at 01:08:21AM +0200, Rafael J. Wysocki wrote:
> On Wed, Jul 27, 2016 at 12:42 AM, Rafael J. Wysocki
> wrote:
> > On Tuesday, July 26, 2016 04:53:19 PM Josh Poimboeuf wrote:
> >> On Tue, Jul 26, 2016 at 10:15:39PM +0200, Rafael J. Wysocki wrote:
>
On Mon, Jul 25, 2016 at 05:21:36PM -0500, Miguel Bernal Marin wrote:
> When objtool was added in 442f04c34a1a, fixdep was omitted to be
> included in .gitignore file.
>
> fixdep is a binary generated by objtool, and this patch adds it to
> .gitignore file.
>
> Signed-off-by: Miguel Bernal Marin
On Thu, Jul 28, 2016 at 12:12:15AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 27, 2016 12:59:18 PM Josh Poimboeuf wrote:
> > Hm... I have a theory, but I'm not sure about it. I noticed that
> > x86_acpi_enter_sleep_state(),
>
> I think you mean x86_acpi
On Wed, Jul 27, 2016 at 08:21:50PM -0700, Linus Torvalds wrote:
> The remaining ones are mostly objtool warnings (Josh added to cc: I
> get both a "objtool: x86 instruction decoder differs from kernel"
> warning
Ok, this should be an easy fix.
> and several new "sibling call from callable instruc
On Thu, Jul 28, 2016 at 01:29:49AM +0200, Rafael J. Wysocki wrote:
> On Thursday, July 28, 2016 01:20:53 AM Rafael J. Wysocki wrote:
> > On Wednesday, July 27, 2016 05:17:38 PM Josh Poimboeuf wrote:
> > > On Thu, Jul 28, 2016 at 12:12:15AM +0200, Rafael J. Wysocki wrote:
> >
On Thu, Jul 28, 2016 at 10:17:07AM -0500, Josh Poimboeuf wrote:
> On Thu, Jul 28, 2016 at 01:29:49AM +0200, Rafael J. Wysocki wrote:
> > On Thursday, July 28, 2016 01:20:53 AM Rafael J. Wysocki wrote:
> > > On Wednesday, July 27, 2016 05:17:38 PM Josh Poimboeuf wrote:
> >
It can be refined later once objtool starts
reading DWARF CFI.
Reported-by: Linus Torvalds
Signed-off-by: Josh Poimboeuf
---
tools/objtool/builtin-check.c | 140 ++
1 file changed, 88 insertions(+), 52 deletions(-)
diff --git a/tools/objtool/builtin-check
Change "Warning" to "warning" to make it look more like a gcc warning.
Hopefully that will be enough to help the 0-day bot or other automated
tools catch this warning earlier before it ends up in Linus's tree.
Reported-by: Linus Torvalds
Reviewed-by: Josh Poimboeuf
--
Fixes for some objtool-related warnings reported by Linus.
Josh Poimboeuf (3):
objtool: support new gcc 6 switch jump table pattern
objtool: resync x86 instruction decoder with the kernel's
objtool: un-capitalize "Warning" for out-of-sync instruction decoder
tools/o
n the tools
subdir so we'd only have two of them instead of three. In the meantime,
here's another manual sync.
Fixes: c61f4d5ebaf0 ("perf tools: Add AVX-512 support to the instruction
decoder used by Intel PT")
Reported-by: Linus Torvalds
Signed-off-by: Josh Poimboeuf
---
to
On Fri, Jul 29, 2016 at 06:55:21PM -0400, Steven Rostedt wrote:
> On Thu, 21 Jul 2016 16:21:42 -0500
> Josh Poimboeuf wrote:
>
> > When function graph tracing is enabled for a function, its return
> > address on the stack is replaced with the address of an ftrace handler
&
On Fri, Jul 29, 2016 at 10:20:36PM -0400, Steven Rostedt wrote:
> On Fri, 29 Jul 2016 19:50:59 -0500
> Josh Poimboeuf wrote:
>
> > BTW, it would be really nice if ftrace_graph_ret_addr() were idempotent
> > so we could get the "real" return address without having
On Mon, Aug 01, 2016 at 10:28:21AM -0400, Steven Rostedt wrote:
> On Sat, 30 Jul 2016 08:51:25 -0500
> Josh Poimboeuf wrote:
>
> > On Fri, Jul 29, 2016 at 10:20:36PM -0400, Steven Rostedt wrote:
> > > On Fri, 29 Jul 2016 19:50:59 -0500
> > > Josh Poimboeuf wrot
On Mon, Aug 01, 2016 at 12:05:41PM -0400, Steven Rostedt wrote:
> On Mon, 1 Aug 2016 10:59:03 -0500
> Josh Poimboeuf wrote:
>
> > On Fri, Jul 29, 2016 at 06:55:21PM -0400, Steven Rostedt wrote:
> > > Here's my patch that should be applied on top.
> > >
&
On Fri, Jul 29, 2016 at 06:55:21PM -0400, Steven Rostedt wrote:
> > @@ -108,18 +97,23 @@ print_context_stack(struct task_struct *task,
> > stack = (unsigned long *)task_stack_page(task);
> >
> > while (valid_stack_ptr(task, stack, sizeof(*stack), end)) {
> > - unsigned l
On Fri, Jul 29, 2016 at 06:55:21PM -0400, Steven Rostedt wrote:
> Here's my patch that should be applied on top.
>
> Maybe add a Signed-off-by: Steven Rostedt along
> with your SOB. But you should remain Author.
[...]
> @@ -123,13 +124,16 @@ print_context_stack_bp(struct task_struc
>
>
On Thu, Sep 08, 2016 at 09:04:01AM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > arch/x86/kernel/dumpstack_32.c | 14 ++
>
> > --- a/arch/x86/kernel/dumpstack_32.c
> > +++ b/arch/x86/kernel/dumpstack_32.c
>
> > +static void
show_stack_log_lvl() and dump_trace() are already preemption safe:
- If they're running in irq or exception context, preemption is already
disabled and the percpu stack pointers can be trusted.
- If they're running with preemption enabled, they must be running on
the task stack anyway, so it
On Tue, Sep 13, 2016 at 06:45:00PM +0900, Byungchul Park wrote:
> Currently, x86 implementation of save_stack_trace() is walking all stack
> region word by word regardless of what the trace->max_entries is.
> However, it's unnecessary to walk after already fulfilling caller's
> requirement, say, if
On Tue, Sep 13, 2016 at 06:45:01PM +0900, Byungchul Park wrote:
> In non-oops case, it's usually not necessary to check all words of stack
> area to extract backtrace. Instead, we can achieve it by tracking frame
> pointer. So made it possible to save stack trace lightly in normal case.
>
> I meas
On Tue, Sep 13, 2016 at 08:29:57PM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf wrote:
>
> > show_stack_log_lvl() and dump_trace() are already preemption safe:
> >
> > - If they're running in irq or exception context, preemption is already
> > disable
1 - 100 of 4709 matches
Mail list logo
