Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-13 Thread Masami Hiramatsu
On Mon, 12 Nov 2018 12:21:48 -0500 Steven Rostedt wrote: > On Mon, 12 Nov 2018 19:51:00 +0300 > Alexander Popov wrote: > > > By the way, are there any other tracing/instrumentation mechanisms that > > should > > be disabled? > > ftrace and kprobes are pretty much the only ones that currently

Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-12 Thread Steven Rostedt
On Mon, 12 Nov 2018 19:51:00 +0300 Alexander Popov wrote: > By the way, are there any other tracing/instrumentation mechanisms that should > be disabled? ftrace and kprobes are pretty much the only ones that currently do self modification of code all over the kernel. Kprobes even more so than ft

Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-12 Thread Alexander Popov
Hello Steven and Masami, Thanks for your comments. On 12.11.2018 5:50, Masami Hiramatsu wrote: > Hi Alexander and Steve, > > On Sun, 11 Nov 2018 20:53:51 -0500 > Steven Rostedt wrote: > >> On Sun, 11 Nov 2018 13:19:45 +0300 >> Alexander Popov wrote: >> >>> On 11.11.2018 2:30, Steven Rostedt w

Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-12 Thread Steven Rostedt
On Mon, 12 Nov 2018 09:53:29 -0500 (EST) Mathieu Desnoyers wrote: > Just to clarify: AFAIU you guys are recommending to add _both_ a "notrace" > annotation to stackleak_erase() _and_ a NOKPROBE_SYMBOL(stackleak_erase), > so neither function tracing nor kprobes can hook on that function. Correct

Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-12 Thread Mathieu Desnoyers
- On Nov 11, 2018, at 9:50 PM, Masami Hiramatsu mhira...@kernel.org wrote: > Hi Alexander and Steve, > > On Sun, 11 Nov 2018 20:53:51 -0500 > Steven Rostedt wrote: > >> On Sun, 11 Nov 2018 13:19:45 +0300 >> Alexander Popov wrote: >> >> > On 11.11.2018 2:30, Steven Rostedt wrote: >> > > On

Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-11 Thread Masami Hiramatsu
Hi Alexander and Steve, On Sun, 11 Nov 2018 20:53:51 -0500 Steven Rostedt wrote: > On Sun, 11 Nov 2018 13:19:45 +0300 > Alexander Popov wrote: > > > On 11.11.2018 2:30, Steven Rostedt wrote: > > > On Sun, 11 Nov 2018 01:05:30 +0300 > > > Alexander Popov wrote: > > > > > >> The stackleak_er

Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-11 Thread Steven Rostedt
On Sun, 11 Nov 2018 13:19:45 +0300 Alexander Popov wrote: > On 11.11.2018 2:30, Steven Rostedt wrote: > > On Sun, 11 Nov 2018 01:05:30 +0300 > > Alexander Popov wrote: > > > >> The stackleak_erase() function is called on the trampoline stack at the > >> end of syscall. This stack is not big e

Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-11 Thread Alexander Popov
On 11.11.2018 2:30, Steven Rostedt wrote: > On Sun, 11 Nov 2018 01:05:30 +0300 > Alexander Popov wrote: > >> The stackleak_erase() function is called on the trampoline stack at the >> end of syscall. This stack is not big enough for ftrace operations, >> e.g. it can be overflowed if we enable kpr

Re: [PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-10 Thread Steven Rostedt
On Sun, 11 Nov 2018 01:05:30 +0300 Alexander Popov wrote: > The stackleak_erase() function is called on the trampoline stack at the > end of syscall. This stack is not big enough for ftrace operations, > e.g. it can be overflowed if we enable kprobe_events for stackleak_erase(). Is the issue wit

[PATCH 1/1] stackleak: Disable ftrace for stackleak.c

2018-11-10 Thread Alexander Popov
The stackleak_erase() function is called on the trampoline stack at the end of syscall. This stack is not big enough for ftrace operations, e.g. it can be overflowed if we enable kprobe_events for stackleak_erase(). Let's disable ftrace for stackleak.c to avoid such situations. Reported-by: kerne