Re: [PATCH 1/3] stackleak: mark stackleak_track_stack() as notrace
On Wed, Dec 5, 2018 at 7:43 PM Steven Rostedt wrote: > > On Wed, 5 Dec 2018 19:29:11 -0800 > Kees Cook wrote: > > > On Wed, Dec 5, 2018 at 6:29 PM Steven Rostedt wrote: > > > > > > On Wed, 5 Dec 2018 21:26:51 -0500 > > > Steven Rostedt wrote: > > > > > > > On Wed, 5 Dec 2018 17:08:34 -0800 > > > > Kees Cook wrote: > > > > > > > > > > > I'll Ack the Makefile > > > > change in the tracing directory, but the rest belongs to others. > > > > Okay, I wasn't sure. Anders's patch was marked "1/3" so I thought it > > was directed at you. :) > > > > I'll grab this one in the gcc-plugins tree. > > Should I just take patch 2 then? I'm thinking it's independent too. > > I'm collecting patches for the next merge window right now so it wont > really be an issue if I do. Sure! I'm not sure what Anders's intention was, but yeah. :) -- Kees Cook
Re: [PATCH 1/3] stackleak: mark stackleak_track_stack() as notrace
On Wed, 5 Dec 2018 19:29:11 -0800 Kees Cook wrote: > On Wed, Dec 5, 2018 at 6:29 PM Steven Rostedt wrote: > > > > On Wed, 5 Dec 2018 21:26:51 -0500 > > Steven Rostedt wrote: > > > > > On Wed, 5 Dec 2018 17:08:34 -0800 > > > Kees Cook wrote: > > > > > > > > I'll Ack the Makefile > > > change in the tracing directory, but the rest belongs to others. > > Okay, I wasn't sure. Anders's patch was marked "1/3" so I thought it > was directed at you. :) > > I'll grab this one in the gcc-plugins tree. Should I just take patch 2 then? I'm thinking it's independent too. I'm collecting patches for the next merge window right now so it wont really be an issue if I do. -- Steve
Re: [PATCH 1/3] stackleak: mark stackleak_track_stack() as notrace
On Wed, Dec 5, 2018 at 6:29 PM Steven Rostedt wrote: > > On Wed, 5 Dec 2018 21:26:51 -0500 > Steven Rostedt wrote: > > > On Wed, 5 Dec 2018 17:08:34 -0800 > > Kees Cook wrote: > > > > > I'll Ack the Makefile > > change in the tracing directory, but the rest belongs to others. Okay, I wasn't sure. Anders's patch was marked "1/3" so I thought it was directed at you. :) I'll grab this one in the gcc-plugins tree. -Kees -- Kees Cook
Re: [PATCH 1/3] stackleak: mark stackleak_track_stack() as notrace
On Wed, 5 Dec 2018 21:26:51 -0500 Steven Rostedt wrote: > On Wed, 5 Dec 2018 17:08:34 -0800 > Kees Cook wrote: > > I'll Ack the Makefile > change in the tracing directory, but the rest belongs to others. > I see I already acked that patch. BTW, when sending a patch series, you really need a 0/3 patch as a header and the rest be threaded. I had a hard time finding that patch in the sea of my INBOX. If I was the one to pull it in, I wouldn't do it if the series was unthreaded like this. -- Steve
Re: [PATCH 1/3] stackleak: mark stackleak_track_stack() as notrace
On Wed, 5 Dec 2018 17:08:34 -0800
Kees Cook wrote:
> > diff --git a/kernel/stackleak.c b/kernel/stackleak.c
> > index e42892926244..5de3bf596dd7 100644
> > --- a/kernel/stackleak.c
> > +++ b/kernel/stackleak.c
> > @@ -102,7 +102,7 @@ asmlinkage void stackleak_erase(void)
> > current->lowest_stack = current_top_of_stack() - THREAD_SIZE/64;
> > }
> >
> > -void __used stackleak_track_stack(void)
> > +void __used notrace stackleak_track_stack(void)
> > {
> > /*
> > * N.B. stackleak_erase() fills the kernel stack with the poison
> > value,
> > --
> > 2.19.2
> >
>
> Acked-by: Kees Cook
>
> Steven, I assume this series going via your tree?
??
A notrace addition doesn't make it mine.
I added changes for the cond_resched in a different patch series that
I'll pull in (they are independent from this). I'll Ack the Makefile
change in the tracing directory, but the rest belongs to others.
-- Steve
Re: [PATCH 1/3] stackleak: mark stackleak_track_stack() as notrace
On Fri, Nov 30, 2018 at 7:09 AM Anders Roxell wrote:
>
> Function graph tracing recurses into itself when stackleak is enabled,
> causing the ftrace graph selftest to run for up to 90 seconds and
> trigger the softlockup watchdog.
>
> Breakpoint 2, ftrace_graph_caller () at
> ../arch/arm64/kernel/entry-ftrace.S:200
> 200 mcount_get_lr_addrx0// pointer to function's
> saved lr
> (gdb) bt
> \#0 ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200
> \#1 0xff80081d5280 in ftrace_caller () at
> ../arch/arm64/kernel/entry-ftrace.S:153
> \#2 0xff8008555484 in stackleak_track_stack () at
> ../kernel/stackleak.c:106
> \#3 0xff8008421ff8 in ftrace_ops_test (ops=0xff8009eaa840
> , ip=18446743524091297036, regs=) at
> ../kernel/trace/ftrace.c:1507
> \#4 0xff8008428770 in __ftrace_ops_list_func (regs=,
> ignored=, parent_ip=, ip=) at
> ../kernel/trace/ftrace.c:6286
> \#5 ftrace_ops_no_ops (ip=18446743524091297036,
> parent_ip=18446743524091242824) at ../kernel/trace/ftrace.c:6321
> \#6 0xff80081d5280 in ftrace_caller () at
> ../arch/arm64/kernel/entry-ftrace.S:153
> \#7 0xff800832fd10 in irq_find_mapping (domain=0xffc03fc4bc80,
> hwirq=27) at ../kernel/irq/irqdomain.c:876
> \#8 0xff800832294c in __handle_domain_irq (domain=0xffc03fc4bc80,
> hwirq=27, lookup=true, regs=0xff800814b840) at ../kernel/irq/irqdesc.c:650
> \#9 0xff80081d52b4 in ftrace_graph_caller () at
> ../arch/arm64/kernel/entry-ftrace.S:205
>
> Rework so we mark stackleak_track_stack as notrace
>
> Co-developed-by: Arnd Bergmann
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Anders Roxell
> ---
> kernel/stackleak.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/stackleak.c b/kernel/stackleak.c
> index e42892926244..5de3bf596dd7 100644
> --- a/kernel/stackleak.c
> +++ b/kernel/stackleak.c
> @@ -102,7 +102,7 @@ asmlinkage void stackleak_erase(void)
> current->lowest_stack = current_top_of_stack() - THREAD_SIZE/64;
> }
>
> -void __used stackleak_track_stack(void)
> +void __used notrace stackleak_track_stack(void)
> {
> /*
> * N.B. stackleak_erase() fills the kernel stack with the poison
> value,
> --
> 2.19.2
>
Acked-by: Kees Cook
Steven, I assume this series going via your tree?
--
Kees Cook
Re: [PATCH 1/3] stackleak: mark stackleak_track_stack() as notrace
On Fri, 30 Nov 2018 16:08:59 +0100
Anders Roxell wrote:
> Function graph tracing recurses into itself when stackleak is enabled,
> causing the ftrace graph selftest to run for up to 90 seconds and
> trigger the softlockup watchdog.
>
> Breakpoint 2, ftrace_graph_caller () at
> ../arch/arm64/kernel/entry-ftrace.S:200
> 200 mcount_get_lr_addrx0// pointer to function's
> saved lr
> (gdb) bt
> \#0 ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200
> \#1 0xff80081d5280 in ftrace_caller () at
> ../arch/arm64/kernel/entry-ftrace.S:153
> \#2 0xff8008555484 in stackleak_track_stack () at
> ../kernel/stackleak.c:106
> \#3 0xff8008421ff8 in ftrace_ops_test (ops=0xff8009eaa840
> , ip=18446743524091297036, regs=) at
> ../kernel/trace/ftrace.c:1507
> \#4 0xff8008428770 in __ftrace_ops_list_func (regs=,
> ignored=, parent_ip=, ip=) at
> ../kernel/trace/ftrace.c:6286
> \#5 ftrace_ops_no_ops (ip=18446743524091297036,
> parent_ip=18446743524091242824) at ../kernel/trace/ftrace.c:6321
> \#6 0xff80081d5280 in ftrace_caller () at
> ../arch/arm64/kernel/entry-ftrace.S:153
> \#7 0xff800832fd10 in irq_find_mapping (domain=0xffc03fc4bc80,
> hwirq=27) at ../kernel/irq/irqdomain.c:876
> \#8 0xff800832294c in __handle_domain_irq (domain=0xffc03fc4bc80,
> hwirq=27, lookup=true, regs=0xff800814b840) at ../kernel/irq/irqdesc.c:650
> \#9 0xff80081d52b4 in ftrace_graph_caller () at
> ../arch/arm64/kernel/entry-ftrace.S:205
>
> Rework so we mark stackleak_track_stack as notrace
>
> Co-developed-by: Arnd Bergmann
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Anders Roxell
Acked-by: Steven Rostedt (VMware)
-- Steve
> ---
> kernel/stackleak.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/stackleak.c b/kernel/stackleak.c
> index e42892926244..5de3bf596dd7 100644
> --- a/kernel/stackleak.c
> +++ b/kernel/stackleak.c
> @@ -102,7 +102,7 @@ asmlinkage void stackleak_erase(void)
> current->lowest_stack = current_top_of_stack() - THREAD_SIZE/64;
> }
>
> -void __used stackleak_track_stack(void)
> +void __used notrace stackleak_track_stack(void)
> {
> /*
>* N.B. stackleak_erase() fills the kernel stack with the poison value,
[PATCH 1/3] stackleak: mark stackleak_track_stack() as notrace
Function graph tracing recurses into itself when stackleak is enabled,
causing the ftrace graph selftest to run for up to 90 seconds and
trigger the softlockup watchdog.
Breakpoint 2, ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200
200 mcount_get_lr_addrx0// pointer to function's
saved lr
(gdb) bt
\#0 ftrace_graph_caller () at ../arch/arm64/kernel/entry-ftrace.S:200
\#1 0xff80081d5280 in ftrace_caller () at
../arch/arm64/kernel/entry-ftrace.S:153
\#2 0xff8008555484 in stackleak_track_stack () at ../kernel/stackleak.c:106
\#3 0xff8008421ff8 in ftrace_ops_test (ops=0xff8009eaa840 ,
ip=18446743524091297036, regs=) at ../kernel/trace/ftrace.c:1507
\#4 0xff8008428770 in __ftrace_ops_list_func (regs=,
ignored=, parent_ip=, ip=) at
../kernel/trace/ftrace.c:6286
\#5 ftrace_ops_no_ops (ip=18446743524091297036,
parent_ip=18446743524091242824) at ../kernel/trace/ftrace.c:6321
\#6 0xff80081d5280 in ftrace_caller () at
../arch/arm64/kernel/entry-ftrace.S:153
\#7 0xff800832fd10 in irq_find_mapping (domain=0xffc03fc4bc80,
hwirq=27) at ../kernel/irq/irqdomain.c:876
\#8 0xff800832294c in __handle_domain_irq (domain=0xffc03fc4bc80,
hwirq=27, lookup=true, regs=0xff800814b840) at ../kernel/irq/irqdesc.c:650
\#9 0xff80081d52b4 in ftrace_graph_caller () at
../arch/arm64/kernel/entry-ftrace.S:205
Rework so we mark stackleak_track_stack as notrace
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Signed-off-by: Anders Roxell
---
kernel/stackleak.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/stackleak.c b/kernel/stackleak.c
index e42892926244..5de3bf596dd7 100644
--- a/kernel/stackleak.c
+++ b/kernel/stackleak.c
@@ -102,7 +102,7 @@ asmlinkage void stackleak_erase(void)
current->lowest_stack = current_top_of_stack() - THREAD_SIZE/64;
}
-void __used stackleak_track_stack(void)
+void __used notrace stackleak_track_stack(void)
{
/*
* N.B. stackleak_erase() fills the kernel stack with the poison value,
--
2.19.2
