From: Anton Arapov <anton@redhat.com>
To: Anton Arapov <anton@redhat.com>, Oleg Nesterov <oleg@redhat.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Josh Stone <jistone@redhat.com>, Frank Eigler <fche@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: [RFC PATCH v4 0/6] uprobes: return probe implementation
Date: Mon, 4 Mar 2013 15:38:07 +0100 [thread overview]
Message-ID: <1362407893-32505-1-git-send-email-anton@redhat.com> (raw)
Hello,
RFC v4 uretprobes implementation. I'd be grateful for review.
/* Oleg, this one is more quirky than previous, don't beat me. */
These patches extending uprobes by enabling tools, such as perf(trace_event),
set a breakpoint on probed function's return address.
v4:
- get rid of area->rp_trampoline_vaddr as it always the same as ->vaddr
- preallocate slot, as the first one in xol_add_vma()
- cleanup ->return_uprobes list in uprobe_free_utask(), because the
task can exit from inside the ret-probe'd function(s).
- in find_active_uprobe(): Once we inserted "int3" we must ensure that
handle_swbp() will be called even if this uprobe goes away. We have
the reference but it only protects uprobe itself, it can't protect
agains delete_uprobe().
IOW, we must ensure that uprobe_pre_sstep_notifier() can't return 0.
- check, whether utask is not NULL in handle_uretprobe()
? do we want a printk() for this case?
- minor handle_uretprobe() fixups
v3 changes:
- removed uretprobe_bypass logic, it will be better to send it as
independent patch
- unified xol_get_trampoline_slot() and xol_get_insn_slot()
- protected uprobe with refcounter in prepare_uretprobe()
- uprobe_register() routine fails now, if neither consumer is set
- enclosed implementation into 1/6, 6/6 patches -ENOSYS bits
v2 changes:
- introduced rp_handler(), get rid of return_consumers
- get rid of uretprobe_[un]register()
- introduced arch_uretprobe_get_sp()
- removed uprobe_task->doomed, kill task immediately
- fix arch_uretprobe_hijack_return_addr()'s returns
- address the v1 minor issues
integrated patchset:
http://github.com/arapov/linux-aa/commits/uretprobes_v3
previous implementations:
RFCv3: https://lkml.org/lkml/2013/2/28/148
RFCv2: https://lkml.org/lkml/2013/1/9/157
RFCv1: https://lkml.org/lkml/2012/12/21/133
thanks,
Anton
Anton Arapov (6):
uretprobes: preparation patch
uretprobes/x86: hijack return address
uretprobes: generalize xol_get_insn_slot()
uretprobes: return probe entry, prepare uretprobe
uretprobes: invoke return probe handlers
uretprobes: implemented, thus remove -ENOSYS
arch/x86/include/asm/uprobes.h | 6 ++
arch/x86/kernel/uprobes.c | 29 +++++++++
include/linux/uprobes.h | 5 ++
kernel/events/uprobes.c | 134 ++++++++++++++++++++++++++++++++++++++---
4 files changed, 166 insertions(+), 8 deletions(-)
--
1.8.1.2
next reply other threads:[~2013-03-04 14:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 14:38 Anton Arapov [this message]
2013-03-04 14:38 ` [RFC PATCH v4 1/6] uretprobes: preparation patch Anton Arapov
2013-03-04 14:38 ` [RFC PATCH v4 2/6] uretprobes/x86: hijack return address Anton Arapov
2013-03-04 14:38 ` [RFC PATCH v4 3/6] uretprobes: generalize xol_get_insn_slot() Anton Arapov
2013-03-04 14:38 ` [RFC PATCH v4 4/6] uretprobes: return probe entry, prepare uretprobe Anton Arapov
2013-03-04 16:47 ` Oleg Nesterov
2013-03-05 13:20 ` Anton Arapov
2013-03-04 14:38 ` [RFC PATCH v4 5/6] uretprobes: invoke return probe handlers Anton Arapov
2013-03-04 16:51 ` Oleg Nesterov
2013-03-05 13:28 ` Anton Arapov
2013-03-05 7:03 ` Ananth N Mavinakayanahalli
2013-03-05 13:18 ` Anton Arapov
2013-03-04 14:38 ` [RFC PATCH v4 6/6] uretprobes: implemented, thus remove -ENOSYS Anton Arapov
2013-03-05 12:04 ` [RFC PATCH v4 0/6] uprobes: return probe implementation Ingo Molnar
2013-03-05 12:22 ` Anton Arapov
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=1362407893-32505-1-git-send-email-anton@redhat.com \
--to=anton@redhat.com \
--cc=ananth@in.ibm.com \
--cc=fche@redhat.com \
--cc=jistone@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=srikar@linux.vnet.ibm.com \
/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