From: Peter Zijlstra <peterz@infradead.org>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Masami Hiramatsu <mhiramat@redhat.com>,
Mel Gorman <mel@csn.ul.ie>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Jim Keniston <jkenisto@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 7/10] Uprobes Implementation
Date: Tue, 23 Mar 2010 12:01:55 +0100 [thread overview]
Message-ID: <1269342115.5279.1620.camel@twins> (raw)
In-Reply-To: <20100320142617.11427.23852.sendpatchset@localhost6.localdomain6>
On Sat, 2010-03-20 at 19:56 +0530, Srikar Dronamraju wrote:
> +struct uprobe {
> + /*
> + * The pid of the probed process. Currently, this can be the
> + * thread ID (task->pid) of any active thread in the process.
> + */
> + pid_t pid;
> +
> + /* Location of the probepoint */
> + unsigned long vaddr;
> +
> + /* Handler to run when the probepoint is hit */
> + void (*handler)(struct uprobe*, struct pt_regs*);
> +
> + /* true if handler runs in interrupt context*/
> + bool handler_in_interrupt;
> +};
I would still prefer to see something like:
vma:offset, instead of tid:vaddr
You want to probe a symbol in a DSO, filtering per-task comes after that
if desired.
Also, like we discussed in person, I think we can do away with the
handler_in_interrupt thing by letting the handler have an error return
value and doing something like:
do_int3:
uprobe = find_probe_point(addr);
pagefault_disable();
err = uprobe->handler(uprobe, regs);
pagefault_enable();
if (err == -EFAULT) {
/* set TIF flag and call the handler again from
task context */
}
This should allow the handler to optimistically access memory from the
trap handler, but in case it does need to fault pages in we'll call it
from task context.
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index dad7f66..2d2433a 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1506,6 +1506,9 @@ struct task_struct {
> unsigned long memsw_bytes; /* uncharged mem+swap usage */
> } memcg_batch;
> #endif
> +#ifdef CONFIG_UPROBES
> + struct uprobe_task *utask;
> +#endif
> };
>
> /* Future-safe accessor for struct task_struct's cpus_allowed. */
> diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
> index 10db010..9a91d1e 100644
> --- a/include/linux/tracehook.h
> +++ b/include/linux/tracehook.h
> @@ -49,6 +49,7 @@
> #include <linux/sched.h>
> #include <linux/ptrace.h>
> #include <linux/security.h>
> +#include <linux/uprobes.h>
> struct linux_binprm;
>
> /**
> @@ -204,6 +205,11 @@ static inline void tracehook_report_exec(struct linux_binfmt *fmt,
> if (!ptrace_event(PT_TRACE_EXEC, PTRACE_EVENT_EXEC, 0) &&
> unlikely(task_ptrace(current) & PT_PTRACED))
> send_sig(SIGTRAP, current, 0);
> +
> +#ifdef CONFIG_UPROBES
> + if (unlikely(current->utask))
> + uprobe_free_utask();
> +#endif
> }
>
> /**
> @@ -219,6 +225,10 @@ static inline void tracehook_report_exec(struct linux_binfmt *fmt,
> static inline void tracehook_report_exit(long *exit_code)
> {
> ptrace_event(PT_TRACE_EXIT, PTRACE_EVENT_EXIT, *exit_code);
> +#ifdef CONFIG_UPROBES
> + if (unlikely(current->utask))
> + uprobe_free_utask();
> +#endif
> }
>
> /**
> @@ -293,6 +303,10 @@ static inline void tracehook_report_clone(struct pt_regs *regs,
> sigaddset(&child->pending.signal, SIGSTOP);
> set_tsk_thread_flag(child, TIF_SIGPENDING);
> }
> +#ifdef CONFIG_UPROBES
> + if (unlikely(current->utask))
> + uprobe_handle_clone(clone_flags, child);
> +#endif
> }
>
> /**
> @@ -593,6 +607,10 @@ static inline void set_notify_resume(struct task_struct *task)
> */
> static inline void tracehook_notify_resume(struct pt_regs *regs)
> {
> +#ifdef CONFIG_UPROBES
> + if (current->utask && current->utask->active_ppt)
> + uprobe_notify_resume(regs);
> +#endif
> }
> #endif /* TIF_NOTIFY_RESUME */
Everybody else simply places callbacks in kernel/fork.c and
kernel/exit.c, but as it is I don't think you want per-task state like
this.
One thing I would like to see is a slot per task, that has a number of
advantages over the current patch-set in that it doesn't have one page
limit in number of probe sites, nor do you need to insert vmas into each
and every address space that happens to have your DSO mapped.
Also, I would simply kill the user_bkpt stuff and merge it into uprobes,
we don't have a kernel_bkpt thing either, only kprobes.
next prev parent reply other threads:[~2010-03-23 11:02 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-20 14:24 [PATCH v1 0/10] Uprobes patches Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 1/10] Move Macro W to insn.h Srikar Dronamraju
2010-03-20 15:50 ` Masami Hiramatsu
2010-03-22 6:24 ` Srikar Dronamraju
2010-03-22 14:11 ` Masami Hiramatsu
2010-03-20 14:25 ` [PATCH v1 2/10] Move replace_page() to mm/memory.c Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 3/10] Enhance replace_page() to support pagecache Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 4/10] User Space Breakpoint Assistance Layer Srikar Dronamraju
2010-03-23 1:40 ` Andrew Morton
2010-03-23 4:48 ` Randy Dunlap
2010-03-23 11:26 ` Srikar Dronamraju
2010-03-20 14:25 ` [PATCH v1 5/10] X86 details for user space breakpoint assistance Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 6/10] Slot allocation for Execution out of line Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 7/10] Uprobes Implementation Srikar Dronamraju
2010-03-23 11:01 ` Peter Zijlstra [this message]
2010-03-23 11:04 ` Peter Zijlstra
2010-03-23 12:23 ` Srikar Dronamraju
2010-03-23 13:46 ` Peter Zijlstra
2010-03-23 14:20 ` Masami Hiramatsu
2010-03-23 15:15 ` Peter Zijlstra
2010-03-23 17:36 ` Masami Hiramatsu
2010-03-24 10:22 ` Srikar Dronamraju
2010-03-23 15:05 ` Ananth N Mavinakayanahalli
2010-03-23 15:15 ` Peter Zijlstra
2010-03-23 15:26 ` Frank Ch. Eigler
2010-03-24 5:59 ` Ananth N Mavinakayanahalli
2010-03-24 7:58 ` Srikar Dronamraju
2010-03-24 13:00 ` Peter Zijlstra
2010-03-25 7:56 ` Srikar Dronamraju
2010-03-25 8:41 ` Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 8/10] X86 details for uprobes Srikar Dronamraju
2010-03-20 14:26 ` [PATCH v1 9/10] Uprobes Documentation patch Srikar Dronamraju
2010-03-22 3:00 ` Randy Dunlap
2010-03-22 5:34 ` Srikar Dronamraju
2010-03-22 14:51 ` Randy Dunlap
2010-03-20 14:26 ` [PATCH v1 10/10] Uprobes samples Srikar Dronamraju
2010-03-23 1:38 ` [PATCH v1 0/10] Uprobes patches Andrew Morton
2010-03-23 10:55 ` Srikar Dronamraju
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=1269342115.5279.1620.camel@twins \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=srikar@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.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
Powered by JetHome