From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jason Baron <jbaron@redhat.com>,
linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, rostedt@goodmis.org, peterz@infradead.org,
jiayingz@google.com, bligh@google.com, roland@redhat.com,
fche@redhat.com
Subject: Re: [PATCH 4/7] add syscall tracepoints
Date: Fri, 19 Jun 2009 08:35:04 -0400 [thread overview]
Message-ID: <20090619123504.GB18428@Krystal> (raw)
In-Reply-To: <20090619021237.GB7903@nowhere>
* Frederic Weisbecker (fweisbec@gmail.com) wrote:
> On Fri, Jun 12, 2009 at 05:24:54PM -0400, Jason Baron wrote:
> >
> > add two tracepoints in syscall exit and entry path, conditioned on
> > TIF_SYSCALL_FTRACE. Supports the syscall trace event code.
> >
> >
> > Signed-off-by: Jason Baron <jbaron@redhat.com>
> >
> > ---
> > arch/x86/kernel/ptrace.c | 6 ++++--
> > include/trace/syscall.h | 18 ++++++++++++++++++
> > kernel/tracepoint.c | 38 ++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 60 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
> > index 09ecbde..1c7301a 100644
> > --- a/arch/x86/kernel/ptrace.c
> > +++ b/arch/x86/kernel/ptrace.c
> > @@ -36,6 +36,8 @@
> > #include <asm/ds.h>
> >
> > #include <trace/syscall.h>
> > +DEFINE_TRACE(syscall_enter);
> > +DEFINE_TRACE(syscall_exit);
> >
> > #include "tls.h"
> >
> > @@ -1498,7 +1500,7 @@ asmregparm long syscall_trace_enter(struct pt_regs *regs)
> > ret = -1L;
> >
> > if (unlikely(test_thread_flag(TIF_SYSCALL_FTRACE)))
> > - ftrace_syscall_enter(regs);
> > + trace_syscall_enter(regs, regs->orig_ax);
> >
> > if (unlikely(current->audit_context)) {
> > if (IS_IA32)
> > @@ -1524,7 +1526,7 @@ asmregparm void syscall_trace_leave(struct pt_regs *regs)
> > audit_syscall_exit(AUDITSC_RESULT(regs->ax), regs->ax);
> >
> > if (unlikely(test_thread_flag(TIF_SYSCALL_FTRACE)))
> > - ftrace_syscall_exit(regs);
> > + trace_syscall_exit(regs, regs->ax);
> >
> > if (test_thread_flag(TIF_SYSCALL_TRACE))
> > tracehook_report_syscall_exit(regs, 0);
> > diff --git a/include/trace/syscall.h b/include/trace/syscall.h
> > index 8cfe515..d5d8310 100644
> > --- a/include/trace/syscall.h
> > +++ b/include/trace/syscall.h
> > @@ -2,6 +2,24 @@
> > #define _TRACE_SYSCALL_H
> >
> > #include <asm/ptrace.h>
> > +#include <linux/tracepoint.h>
> > +
> > +extern void syscall_regfunc(void);
> > +extern void syscall_unregfunc(void);
> > +
> > +DECLARE_TRACE_REG(syscall_enter,
> > + TP_PROTO(struct pt_regs *regs, long id),
> > + TP_ARGS(regs, id),
> > + syscall_regfunc,
> > + syscall_unregfunc
> > +);
> > +
> > +DECLARE_TRACE_REG(syscall_exit,
> > + TP_PROTO(struct pt_regs *regs, long ret),
> > + TP_ARGS(regs, ret),
> > + syscall_regfunc,
> > + syscall_unregfunc
> > +);
> >
> > /*
> > * A syscall entry in the ftrace syscalls array.
> > diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
> > index 1ef5d3a..5b34ff9 100644
> > --- a/kernel/tracepoint.c
> > +++ b/kernel/tracepoint.c
>
>
>
> At a first glance I wasn't sure tracepoint.c is the right
> place for these.
> But indeed putting those two callbacks here avoids any
> dependency to the syscall tracer when someone else needs
> the syscall tracepoints.
>
> Well, I guess we can keep them there.
>
>
>
> > @@ -24,6 +24,7 @@
> > #include <linux/tracepoint.h>
> > #include <linux/err.h>
> > #include <linux/slab.h>
> > +#include <linux/sched.h>
> >
> > extern struct tracepoint __start___tracepoints[];
> > extern struct tracepoint __stop___tracepoints[];
> > @@ -577,3 +578,40 @@ static int init_tracepoints(void)
> > __initcall(init_tracepoints);
> >
> > #endif /* CONFIG_MODULES */
> > +
> > +DEFINE_MUTEX(regfunc_mutex);
> > +int sys_tracepoint_refcount;
>
>
> Looks like regfunc_mutex is only there to protect
> sys_tracepoint_refcount. May be you can just make it atomic_t?
>
Nope, regfunc_mutex makes sure there is no disable/enable occuring
concurrently. They only take a tasklist read lock, so they can happen
concurrently if it wasn't for the regfunc_mutex.
Unless I'm missing something totally obvious about the refcount, the
mutex is needed, and there is no need to go for an atomic type in this
case.
Thanks,
Mathieu
> Thanks,
> Frederic.
>
>
> > +
> > +void syscall_regfunc(void)
> > +{
> > + unsigned long flags;
> > + struct task_struct *g, *t;
> > +
> > + mutex_lock(®func_mutex);
> > + if (!sys_tracepoint_refcount) {
> > + read_lock_irqsave(&tasklist_lock, flags);
> > + do_each_thread(g, t) {
> > + set_tsk_thread_flag(t, TIF_SYSCALL_FTRACE);
> > + } while_each_thread(g, t);
> > + read_unlock_irqrestore(&tasklist_lock, flags);
> > + }
> > + sys_tracepoint_refcount++;
> > + mutex_unlock(®func_mutex);
> > +}
> > +
> > +void syscall_unregfunc(void)
> > +{
> > + unsigned long flags;
> > + struct task_struct *g, *t;
> > +
> > + mutex_lock(®func_mutex);
> > + sys_tracepoint_refcount--;
> > + if (!sys_tracepoint_refcount) {
> > + read_lock_irqsave(&tasklist_lock, flags);
> > + do_each_thread(g, t) {
> > + clear_tsk_thread_flag(t, TIF_SYSCALL_FTRACE);
> > + } while_each_thread(g, t);
> > + read_unlock_irqrestore(&tasklist_lock, flags);
> > + }
> > + mutex_unlock(®func_mutex);
> > +}
> > --
> > 1.6.0.6
> >
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2009-06-19 12:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-12 21:24 [PATCH 0/7] add syscall tracepoints Jason Baron
2009-06-12 21:24 ` [PATCH 1/7] " Jason Baron
2009-06-19 8:22 ` Li Zefan
2009-06-12 21:24 ` [PATCH 2/7] " Jason Baron
2009-06-19 3:24 ` Steven Rostedt
2009-06-19 8:26 ` Li Zefan
2009-06-12 21:24 ` [PATCH 3/7] " Jason Baron
2009-06-12 21:57 ` Mathieu Desnoyers
2009-06-15 14:12 ` Jason Baron
2009-06-15 15:24 ` Mathieu Desnoyers
2009-06-15 15:37 ` Frederic Weisbecker
2009-06-15 15:47 ` Mathieu Desnoyers
2009-06-19 1:59 ` Frederic Weisbecker
2009-06-19 3:29 ` Steven Rostedt
2009-06-19 3:40 ` Frederic Weisbecker
2009-06-12 21:24 ` [PATCH 4/7] " Jason Baron
2009-06-19 2:12 ` Frederic Weisbecker
2009-06-19 12:35 ` Mathieu Desnoyers [this message]
2009-06-19 14:56 ` Frederic Weisbecker
2009-06-19 8:31 ` Li Zefan
2009-06-12 21:24 ` [PATCH 5/7] " Jason Baron
2009-06-19 2:14 ` Frederic Weisbecker
2009-06-19 3:14 ` Li Zefan
2009-06-19 3:32 ` Steven Rostedt
2009-06-19 3:33 ` Frederic Weisbecker
2009-06-12 21:25 ` [PATCH 6/7] " Jason Baron
2009-06-19 2:28 ` Frederic Weisbecker
2009-06-19 21:49 ` Jason Baron
2009-06-12 21:25 ` [PATCH 7/7] " Jason Baron
2009-06-16 19:32 ` [PATCH 0/7] " Ingo Molnar
2009-06-18 2:21 ` Frederic Weisbecker
2009-06-19 3:07 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090619123504.GB18428@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=bligh@google.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jbaron@redhat.com \
--cc=jiayingz@google.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox