From: Ian Munsie <hidden> Date: 2010-05-13 07:44:04
This patch series implements raw system call tracepoints on PowerPC that can be
used with ftrace and perf. Some problems with the generic ftrace syscall
tracepoint code have also been addressed.
The patches are based upon Ben's powerpc/next tree merged with tip/tracing/core
Patch #1 removes all ftrace syscall events that fail to map the system call
name from the system call metadata with the system call's number, preventing
the events which will not work from showing up in perf list and removing them
from /sys/kernel/debug/tracing/events/syscalls.
Patches #2 and #3 allow for archs with unusual system call tables (#2) or
unusual symbol names (#3) to override the appropriate functions so that they
can still work with ftrace syscalls.
Patch #4 implements the actual raw system call tracepoints that ftrace syscalls
builds upon, allowing all of the system calls to be used with the raw_syscalls
events category and most to be used with the syscalls category.
Not all the raw_syscalls are currently mapped to ftrace syscalls - the syscalls
defined in /arch/powerpc/include/asm/syscalls.h do not use the SYSCALL_DEFINE
class of macros and as such have no meta data, likewise some of the ppc_*
syscalls have assembly wrappers. These are on their way, but I wanted to put
the work I have done so far out first.
Some of those syscalls have different return types than the __SYSCALL_DEFINE
macro uses (unsigned long, int, time_t) and some have different prefixes (ppc,
ppc64) - I didn't particularly want to change them straight over without asking
the list first, and I certainly don't want to change the return types. I see
that Jason Baron ran into similar issues, but his "add compat syscall support"
patches have yet to be merged, and do not tackle the differing return types.
From: Ian Munsie <hidden> Date: 2010-05-13 07:44:10
From: Ian Munsie <redacted>
FTRACE_SYSCALLS would create events for each and every system call, even
if it had failed to map the system call's name with it's number. This
resulted in a number of events being created that would not behave as
expected.
This could happen, for example, on architectures who's symbol names are
unusual and will not match the system call name. It could also happen
with system calls which were mapped to sys_ni_syscall.
This patch changes the default system call number in the metadata to -1.
If the system call name from the metadata is not successfully mapped to
a system call number during boot, than the event initialisation routine
will now return an error, preventing the event from being created.
Signed-off-by: Ian Munsie <redacted>
---
include/linux/syscalls.h | 2 ++
kernel/trace/trace_syscalls.c | 8 ++++++++
2 files changed, 10 insertions(+), 0 deletions(-)
From: Ian Munsie <hidden> Date: 2010-05-13 07:44:13
From: Ian Munsie <redacted>
This patch implements the raw syscall tracepoints on PowerPC required
for ftrace syscalls.
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within the 16 bits of the andi instruction's UI field.
In the case of 64bit PowerPC, arch_syscall_addr and
arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
work given the unusual system call table structure and symbol names that
start with a period.
Signed-off-by: Ian Munsie <redacted>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/syscall.h | 9 +++++++++
arch/powerpc/include/asm/thread_info.h | 7 +++++--
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/ftrace.c | 13 +++++++++++++
arch/powerpc/kernel/ptrace.c | 10 ++++++++++
6 files changed, 39 insertions(+), 2 deletions(-)
@@ -110,7 +110,8 @@ static inline struct thread_info *current_thread_info(void)#define TIF_NOERROR 12 /* Force successful syscall return */#define TIF_NOTIFY_RESUME 13 /* callback before returning to user */#define TIF_FREEZE 14 /* Freezing for suspend */-#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */+#define TIF_SYSCALL_TRACEPOINT 15 /* syscall tracepoint instrumentation */+#define TIF_RUNLATCH 16 /* Is the runlatch enabled? *//* as above, but as bit values */#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
From: Ian Munsie <hidden> Date: 2010-05-13 07:44:37
From: Ian Munsie <redacted>
Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name for the syscall metadata
will fail. For example, symbols on PPC64 start with a period and the
generic code will fail to match them.
This patch splits out the match logic into a standalone weak function
that can be overridden on archs with unusual symbol names.
Signed-off-by: Ian Munsie <redacted>
---
Documentation/trace/ftrace-design.txt | 3 +++
include/linux/ftrace.h | 1 +
kernel/trace/trace_syscalls.c | 19 ++++++++++++-------
3 files changed, 16 insertions(+), 7 deletions(-)
@@ -247,6 +247,9 @@ You need very few things to get the syscalls tracing in an arch. - If the system call table on this arch is more complicated than a simple array of addresses of the system calls, implement an arch_syscall_addr to return the address of a given system call.+- If the symbol names of the system calls do not match the function names on+ this arch, implement an arch_syscall_match_sym_name with the appropriate+ logic to return true if the function name corresponds with the symbol name. - Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
From: Ian Munsie <hidden> Date: 2010-05-13 07:44:47
From: Ian Munsie <redacted>
Some architectures use non-trivial system call tables and will not work
with the generic arch_syscall_addr code. For example, PowerPC64 uses a
table of twin long longs.
This patch makes the generic arch_syscall_addr weak to allow
architectures with non-trivial system call tables to override it.
Signed-off-by: Ian Munsie <redacted>
---
Documentation/trace/ftrace-design.txt | 3 +++
kernel/trace/trace_syscalls.c | 2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
@@ -244,6 +244,9 @@ You need very few things to get the syscalls tracing in an arch. - Support the TIF_SYSCALL_TRACEPOINT thread flags. - Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace in the ptrace syscalls tracing path.+- If the system call table on this arch is more complicated than a simple array+ of addresses of the system calls, implement an arch_syscall_addr to return+ the address of a given system call. - Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
From: Michael Ellerman <hidden> Date: 2010-05-13 12:09:40
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
From: Ian Munsie <redacted>
Hi Ian,
Just a few comments ..
This patch implements the raw syscall tracepoints on PowerPC required
for ftrace syscalls.
OK. It also adds a bunch of code under CONFIG_FTRACE_*, so does it
implement raw syscall tracepoints _and_ hook them up to ftrace?
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within the 16 bits of the andi instruction's UI field.
Which andi instruction? That could use a bit more explaining.
In the case of 64bit PowerPC, arch_syscall_addr and
arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
work given the unusual system call table structure and symbol names that
start with a period.
Not unusual, just different (ie. better) than x86 ;)
You're following the existing pattern there, but it's a little odd.
Seems like those three config options should really all depend on
something common and that should trigger the build of ftrace.c
From: Steven Rostedt <rostedt@goodmis.org> Date: 2010-05-13 16:06:16
Frederic,
I'm fine with these patches, but since you mainly did the syscall work,
I'll let you take them.
The patches that touch the PowerPC code needs an acked-by from Ben or
Paul.
-- Steve
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
This patch series implements raw system call tracepoints on PowerPC that can be
used with ftrace and perf. Some problems with the generic ftrace syscall
tracepoint code have also been addressed.
The patches are based upon Ben's powerpc/next tree merged with tip/tracing/core
Patch #1 removes all ftrace syscall events that fail to map the system call
name from the system call metadata with the system call's number, preventing
the events which will not work from showing up in perf list and removing them
from /sys/kernel/debug/tracing/events/syscalls.
Patches #2 and #3 allow for archs with unusual system call tables (#2) or
unusual symbol names (#3) to override the appropriate functions so that they
can still work with ftrace syscalls.
Patch #4 implements the actual raw system call tracepoints that ftrace syscalls
builds upon, allowing all of the system calls to be used with the raw_syscalls
events category and most to be used with the syscalls category.
Not all the raw_syscalls are currently mapped to ftrace syscalls - the syscalls
defined in /arch/powerpc/include/asm/syscalls.h do not use the SYSCALL_DEFINE
class of macros and as such have no meta data, likewise some of the ppc_*
syscalls have assembly wrappers. These are on their way, but I wanted to put
the work I have done so far out first.
Some of those syscalls have different return types than the __SYSCALL_DEFINE
macro uses (unsigned long, int, time_t) and some have different prefixes (ppc,
ppc64) - I didn't particularly want to change them straight over without asking
the list first, and I certainly don't want to change the return types. I see
that Jason Baron ran into similar issues, but his "add compat syscall support"
patches have yet to be merged, and do not tackle the differing return types.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2010-05-14 00:00:33
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
From: Ian Munsie <redacted>
Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name for the syscall metadata
will fail. For example, symbols on PPC64 start with a period and the
generic code will fail to match them.
This patch splits out the match logic into a standalone weak function
that can be overridden on archs with unusual symbol names.
Signed-off-by: Ian Munsie <redacted>
---
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Ian, I assume you will implement the support for the "special" ppc_*
syscalls via a subsequent patch and not a respin of this one right ?
Cheers,
Ben.
@@ -247,6 +247,9 @@ You need very few things to get the syscalls tracing in an arch. - If the system call table on this arch is more complicated than a simple array of addresses of the system calls, implement an arch_syscall_addr to return the address of a given system call.+- If the symbol names of the system calls do not match the function names on+ this arch, implement an arch_syscall_match_sym_name with the appropriate+ logic to return true if the function name corresponds with the symbol name. - Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2010-05-14 00:20:53
On Thu, 2010-05-13 at 12:06 -0400, Steven Rostedt wrote:
Frederic,
I'm fine with these patches, but since you mainly did the syscall work,
I'll let you take them.
The patches that touch the PowerPC code needs an acked-by from Ben or
Paul.
Done :-)
Cheers,
Ben.
-- Steve
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
quoted
This patch series implements raw system call tracepoints on PowerPC that can be
used with ftrace and perf. Some problems with the generic ftrace syscall
tracepoint code have also been addressed.
The patches are based upon Ben's powerpc/next tree merged with tip/tracing/core
Patch #1 removes all ftrace syscall events that fail to map the system call
name from the system call metadata with the system call's number, preventing
the events which will not work from showing up in perf list and removing them
from /sys/kernel/debug/tracing/events/syscalls.
Patches #2 and #3 allow for archs with unusual system call tables (#2) or
unusual symbol names (#3) to override the appropriate functions so that they
can still work with ftrace syscalls.
Patch #4 implements the actual raw system call tracepoints that ftrace syscalls
builds upon, allowing all of the system calls to be used with the raw_syscalls
events category and most to be used with the syscalls category.
Not all the raw_syscalls are currently mapped to ftrace syscalls - the syscalls
defined in /arch/powerpc/include/asm/syscalls.h do not use the SYSCALL_DEFINE
class of macros and as such have no meta data, likewise some of the ppc_*
syscalls have assembly wrappers. These are on their way, but I wanted to put
the work I have done so far out first.
Some of those syscalls have different return types than the __SYSCALL_DEFINE
macro uses (unsigned long, int, time_t) and some have different prefixes (ppc,
ppc64) - I didn't particularly want to change them straight over without asking
the list first, and I certainly don't want to change the return types. I see
that Jason Baron ran into similar issues, but his "add compat syscall support"
patches have yet to be merged, and do not tackle the differing return types.
From: Ian Munsie <hidden> Date: 2010-05-14 02:03:45
Excerpts from Michael Ellerman's message of Thu May 13 22:09:31 +1000 2010:
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
quoted
From: Ian Munsie <redacted>
Hi Ian,
Just a few comments ..
quoted
This patch implements the raw syscall tracepoints on PowerPC required
for ftrace syscalls.
OK. It also adds a bunch of code under CONFIG_FTRACE_*, so does it
implement raw syscall tracepoints _and_ hook them up to ftrace?
Yes, that's correct. CONFIG_FTRACE_SYSCALLS depends solely on, and is
the primary consumer of, HAVE_SYSCALL_TRACEPOINTS. It makes little sense
to me to provide the raw syscall tracepoints without exporting the
syscall table for ftrace syscalls to use - otherwise they would be
available to select in make config, but broken.
quoted
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within the 16 bits of the andi instruction's UI field.
Which andi instruction? That could use a bit more explaining.
The ones under /arch/powerpc/kernel/entry_{32,64}.S using andi to
and the _TIF_SYSCALL_T_OR_A with the thread flags to see if system call
tracing is enabled.
For instance, from entry_64.S:
ld r10,TI_FLAGS(r11)
andi. r11,r10,_TIF_SYSCALL_T_OR_A <-- that one
bne- syscall_dotrace
.......
syscall_dotrace:
bl .save_nvgprs
addi r3,r1,STACK_FRAME_OVERHEAD
bl .do_syscall_trace_enter
And similarly elsewhere in the same file:
ld r9,TI_FLAGS(r12)
li r11,-_LAST_ERRNO
andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK)
bne- syscall_exit_work
.......
syscall_exit_work:
.......
bl .save_nvgprs
addi r3,r1,STACK_FRAME_OVERHEAD
bl .do_syscall_trace_leave
entry_32.S contains very similar assembly to the above.
The alternative to renumbering the thread flags would be to rework the
assembly to use and. instead of andi. to avoid having to squeeze that
flag into 16 bits.
quoted
In the case of 64bit PowerPC, arch_syscall_addr and
arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
work given the unusual system call table structure and symbol names that
start with a period.
Not unusual, just different (ie. better) than x86 ;)
I'm not sure why this is ULL ? UL and ULL are both 64 bits (on 64bit),
and it would save you this ifdef block and a cast in
arch_syscall_addr().
Good point - I was just following the format from
/arch/powerpc/kernel/systbl.S, which uses pairs of .llong on PPC64 and
single .long on PPC32. Does the assembler treat .llong different from
.long on 64bit?
@@ -110,7 +110,8 @@ static inline struct thread_info *current_thread_info(void)#define TIF_NOERROR 12 /* Force successful syscall return */#define TIF_NOTIFY_RESUME 13 /* callback before returning to user */#define TIF_FREEZE 14 /* Freezing for suspend */-#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */+#define TIF_SYSCALL_TRACEPOINT 15 /* syscall tracepoint instrumentation */+#define TIF_RUNLATCH 16 /* Is the runlatch enabled? */
I don't grok why this is good or safe, not that it isn't but please tell
me why it is :)
Ok - now I could be wrong on this, but AFAICT the flags are only used
internally within the kernel by name and not exported to userspace (ie,
not part of the kernel ABI). That specific flag is only set and cleared
within /arch/powerpc/kernel/process.c so recompiling the kernel should
be sufficient to change those instances of TIF_RUNLATCH from 15 to 16.
You're following the existing pattern there, but it's a little odd.
Seems like those three config options should really all depend on
something common and that should trigger the build of ftrace.c
There isn't anything in the arch specific ftrace.c that depends purely on
ftrace. It's all stuff that depends on the above specific ftrace options
that have some arch specific implementation.
@@ -600,3 +601,15 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr)}}#endif /* CONFIG_FUNCTION_GRAPH_TRACER */++#if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64)
Does 32-bit just work using the existing routines? Or do we not support
it on 32-bit (though that's not what your Kconfig change said).
It should work with the existing routines - I still need to test this on
feugo to make sure, but following from /arch/powerpc/kernel/systbl.S it
seems that the symbol names should match the function names and the
system call table is a trivial lookup table, both of which will work
with the generic implementation.
quoted
+unsigned long __init arch_syscall_addr(int nr)
+{
+ return (unsigned long)sys_call_table[nr*2];
From: Ian Munsie <hidden> Date: 2010-05-14 02:07:14
Excerpts from Benjamin Herrenschmidt's message of Fri May 14 09:54:56 +1000 2010:
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
quoted
From: Ian Munsie <redacted>
Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name for the syscall metadata
will fail. For example, symbols on PPC64 start with a period and the
generic code will fail to match them.
This patch splits out the match logic into a standalone weak function
that can be overridden on archs with unusual symbol names.
Signed-off-by: Ian Munsie <redacted>
---
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Ian, I assume you will implement the support for the "special" ppc_*
syscalls via a subsequent patch and not a respin of this one right ?
Cheers,
Ben.
Yes, that will be in a separate patch or two.
Cheers,
-Ian
From: Ian Munsie <hidden> Date: 2010-05-14 08:42:40
From: Ian Munsie <redacted>
This patch implements the raw syscall tracepoints on PowerPC and exports
them for ftrace syscalls to use.
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within the 16 bits of the andi. instruction's UI field. The instructions
in question are in /arch/powerpc/kernel/entry_{32,64}.S to and the
_TIF_SYSCALL_T_OR_A with the thread flags to see if system call tracing
is enabled.
In the case of 64bit PowerPC, arch_syscall_addr and
arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
work given the unusual system call table structure and symbol names that
start with a period.
Signed-off-by: Ian Munsie <redacted>
---
Changes since v1: No functional changes, just removed the redundant conditional
export of sys_call_table on PPC32 vs PPC64, removed a cast and added an extra
comment to explain the arch_syscall_match_sym_name based on the feedback from
Michael Ellerman.
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/syscall.h | 5 +++++
arch/powerpc/include/asm/thread_info.h | 7 +++++--
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/ftrace.c | 19 +++++++++++++++++++
arch/powerpc/kernel/ptrace.c | 10 ++++++++++
6 files changed, 41 insertions(+), 2 deletions(-)
@@ -110,7 +110,8 @@ static inline struct thread_info *current_thread_info(void)#define TIF_NOERROR 12 /* Force successful syscall return */#define TIF_NOTIFY_RESUME 13 /* callback before returning to user */#define TIF_FREEZE 14 /* Freezing for suspend */-#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */+#define TIF_SYSCALL_TRACEPOINT 15 /* syscall tracepoint instrumentation */+#define TIF_RUNLATCH 16 /* Is the runlatch enabled? *//* as above, but as bit values */#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)