Re: gdbstub initial code
* Roland McGrath rol...@redhat.com [2010-07-12 22:59:05]: When I had posted a prototype of a gdbstub which Frank and I had worked on. http://lkml.org/lkml/2009/11/30/173, Peter and Ingo showed a preference for a combined gdbstub in kernel, i.e kgdb and the newer stub should use only one stub in kernel. Do we have plans to handle that? Their actual idea there largely represents a misunderstanding of the problem space. But regardless, it's a distraction from the prototype work that Oleg is doing now. The actual possibilities for code sharing between kgdb and something at all like what we're doing now are quite small. It's just not a problem at all to get prototyping progress done with a new implementation of the fairly trivial gdb remote protocol decoder, and contemplate consolidation later on. Agree, my concern was that if they keep repeating it after we have done the prototyping. Yes, that shouldnt stop us from prototyping. -- Thanks and Regards Srikar
Re: gdbstub initial code
Hi Oleg, Hello. Please see the attachment. Don't take this code seriously, this is the early prototype and everything should be rewritten. It barely uses utrace, only to stop the target. (gdb) file /path/to/binary (gdb) target extended-remote /proc/ugdb (gdb) attach PID (gdb) disassemble _start (gdb) bt (gdb) info registers (gdb) info threads (gdb) detach This seems to work, but I had to export access_process_vm(). Currently it only attaches to the single thread. vCont or ^C doesn't work. I still can't understand what utrace_xxx_pid() buys us, and I still think that utrace_prepare_examine() can't protect the task even for regset calls. When I had posted a prototype of a gdbstub which Frank and I had worked on. http://lkml.org/lkml/2009/11/30/173, Peter and Ingo showed a preference for a combined gdbstub in kernel, i.e kgdb and the newer stub should use only one stub in kernel. Do we have plans to handle that? -- Thanks and Regards Srikar
Re: gdbstub initial code
Hello. Please see the attachment. Don't take this code seriously, this is the early prototype and everything should be rewritten. It barely uses utrace, only to stop the target. (gdb) file /path/to/binary (gdb) target extended-remote /proc/ugdb (gdb) attach PID (gdb) disassemble _start What is the reasoning for selecting /proc/ugdb instead of something like /proc/pid/ugdb? We had a discussion sometime back in utrace_devel https://www.redhat.com/archives/utrace-devel/2008-June/msg00070.html where we thought having /proc/utrace was a bad choice. -- Thanks and Regards Srikar
Fw: Re: linux-next: add utrace tree
Hi Roland, Oleg, Would it be a good idea to probably start looking at user space api for utrace? By doing that we would get usecases that maintainers in LKML are looking for and start looking at its usefulness. Currently its probably a egg and chicken case where they look at what end customers are getting that additional benefit from utrace and we are looking at providing the user interface after the bits go in. -- Thanks and Regards Srikar ---BeginMessage--- On Fri, 22 Jan 2010 11:17:47 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: Any thoughts? I'm nearly a week behind again and am trying to avoid thinking. I've had a (n old) version of utrace in -mm for ages and it didn't break anything. I still don't think I've seen a really compelling reason for merging it. At least, I wouldn't be able to explain why we did it. But presumably there _are_ such reasons, because it was a lot of development work. Someone please sell this to us. ---End Message---
Re: [RFC] [PATCH 0/7] UBP, XOL and Uprobes [ Summary of Comments and actions to be taken ]
Here is a summary of the Comments and actions that need to be taken for the current uprobes patchset. Please let me know if I missed or misunderstood any of your comments. 1. Uprobes depends on trap signal. Uprobes depends on trap signal rather than hooking to the global die notifier. It was suggested that we hook to the global die notifier. In the next version of patches, Uprobes will use the global die notifier and look at the per-task count of the probes in use to see if it has to be consumed. However this would reduce the ability of uprobe handlers to sleep. Since we are dealing with userspace, sleeping in handlers would have been a good feature. We are looking at ways to get around this limitation. 2. XOL vma vs Emulation vs Single Stepping Inline vs using Protection Rings. XOL VMA is an additional process address vma. This is opposition to add an additional vma without user actually requesting for the same. XOL vma and single stepping inline are the two architecture independent implementations. While other implementations are more architecture specific. Single stepping inline wouldnt go well with multithreaded process. Even though XOL vma has its own issues, we will go with it since other implementations seem to have more complications. we would look forward to implementing boosters later. Later on, if we come across another techniques with lesser side-effects than the XOL vma, we would switch to using them. 3. Current Uprobes looks at process life times and not vma lifetimes. Also it needs threads to quiesce when inserting and removing breakpoints. Current uprobes was quiesing threads of a process before insertion and deletion. This resulted in uprobes having to track process lifetimes. An alternative method to track vma lifetimes was suggested. Next version would update the copy of the page and flip the pagetables as suggested by Peter. Hence it would no more depend on threads quiescing. However this would need hooks in munmap/rmap so that uprobes can remove breakpoints that are placed in that vma. This would also mean removing the rcu_deference we were using. 4. Move the ftrace plugin to use trace events. Since ftrace plugins are relegated to obsolescence, it was suggested we use trace events which would have much wider scope. Next version will use trace events. 5. rename UBP to user_bkpt 6. updating the authors for all files that are getting added. I shall work towards v2 of uprobes and send across the patches at the earliest. -- Thanks and Regards Srikar
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
* Frederic Weisbecker fweis...@gmail.com [2010-01-19 19:06:12]: On Tue, Jan 19, 2010 at 09:47:45AM -0800, Jim Keniston wrote: What does the code in the jumped-to vma do? Is the instrumentation code that corresponds to the uprobe handlers encoded in an ad hoc .so? Once the instrumentation is requested by a process that is not the instrumented one, this looks impossible to set a uprobe without a minimal voluntary collaboration from the instrumented process (events sent through IPC or whatever). So that looks too limited, this is not anymore a true dynamic uprobe. I dont see a case where the thread being debugged refuses to place a probe unless the process is exiting. The traced process doesnt decide if it wants to be probed or not. There could be a slight delay from the time the tracer requested to the time the probe is placed. But this delay in only affecting the tracer and the tracee. This is in contract to say stop_machine where the threads of other applications are also affected.
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
* Avi Kivity a...@redhat.com [2010-01-18 14:17:10]: On 01/18/2010 02:13 PM, Pekka Enberg wrote: So how big chunks of the address space are we talking here for uprobes? That's for the authors to answer, but at a guess, 32 bytes per probe (largest x86 instruction is 15 bytes), so 32 MB will give you a million probes. That's a piece of cake for x86-64, probably harder to justify for i386. On x86, each probe takes 16 bytes. In the current implementation of XOL, the first hit of a breakpoint, requires us to allocate a page. If that page does get full with active breakpoints, we expand / add a page. There is a bit map that keeps a check to see if a previously used breakpoint is removed and hence that slot can be reused. By active breakpoints, I refer to those that are inserted, and has been trapped atleast once but not yet removed. Jim did try a few other allocation techniques but those that involved slot stealing did end up having locking. People who did look at that code did advise us to reduce the locking and keep the allocation simple (atleast for the first cut). -- Thanks and Regards Srikar -- error compiling committee.c: too many arguments to function
Re: [RFC] [PATCH 4/7] Uprobes Implementation
Hi Peter, My reply in http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/02483.html addresses this. Right, so all that need be done is add the multiple probe stuff to UBP and its a sane interface to use on its own, at which point I'd be inclined to call that uprobes (UBP really is an crap name). I am fine with renaming ubp to a suggested name. The reason for splitting uprobes to two layers was to allow others (currently none) to reuse the current ubp layer. It was felt that there could be multiple clients for ubp who could co-exist. However ubp alone is not enough to provide the userspace tracing. Currently it wouldn't understand synchronization between different threads of a process, process life time issues, context in which the handler has to be run. As pointed out by Jim earlier, we have segregrated that layer which takes care of the above issues into the uprobes layer. For example, while inserting a breakpoint, one of the threads of a process could be running at the same place where we are trying to place a breakpoint. Or there could be two threads that could be racing to insert/delete a breakpoint. These synchronization issues are all handled by the Uprobes layer. Uprobes layer would need to be notified of process life-time events like fork/clone/exec/exit. It also needs to know - when a breakpoint is hit - stop and resume a thread. Uprobes layer uses utrace to be notified of the process life time events and the signal handling part. -- Thanks and Regards Srikar Then we can ditch the whole utrace muck as I see no reason to want to use that, whereas the ubp (given a sane name) looks interesting.
Re: [RFC] [PATCH 3/7] Execution out of line (XOL)
* Peter Zijlstra pet...@infradead.org [2010-01-15 10:07:35]: On Thu, 2010-01-14 at 14:43 -0800, Jim Keniston wrote: Yeah, there's not a lot of context there. I hope it will make more sense if you read section 1.1 of Documentation/uprobes.txt (patch #6). Or look at get_insn_slot() in kprobes, and understand that we're trying to do something similar in uprobes, where the instruction copies have to reside in the user address space of the probed process. That's not the point, changelogs shoulnd not be this cryptic. They should be stand alone and descriptive of what, why and how. If you can't be bothered writing such for something you want reviewed for inclusion then I might not be bothered looking at them at all. Okay shall add to the Changelog with the information providing the context for this patch.
Re: [RFC] [PATCH 4/7] Uprobes Implementation
* Peter Zijlstra pet...@infradead.org [2010-01-15 11:33:27]: Uprobes layer would need to be notified of process life-time events like fork/clone/exec/exit. No so much the process lifetimes as the vma life times are interesting, placing a hook in the vm code to track that isn't too hard, It also needs to know - when a breakpoint is hit - stop and resume a thread. A simple hook in the trap code is done quickly enough, and no reason to stop the thread, its not going anywhere when it traps. Some of the threads could be executing in the vicinity of the breakpoint when it is getting inserted or deleted. Wont we need to stop/quiesce those threads?
[RFC] [PATCH 2/7] x86 support for UBP
x86 support for user breakpoint Infrastructure
This patch provides x86 specific userspace breakpoint assistance
implementation details.
This patch requires x86: instruction decoder API patch.
http://lkml.org/lkml/2009/6/1/459
Signed-off-by: Jim Keniston jkeni...@us.ibm.com
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
arch/x86/Kconfig |1
arch/x86/include/asm/ubp.h | 40 +++
arch/x86/kernel/Makefile |2
arch/x86/kernel/ubp_x86.c | 577 +
4 files changed, 620 insertions(+)
Index: new_uprobes.git/arch/x86/Kconfig
===
--- new_uprobes.git.orig/arch/x86/Kconfig
+++ new_uprobes.git/arch/x86/Kconfig
@@ -50,6 +50,7 @@ config X86
select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_LZMA
select HAVE_HW_BREAKPOINT
+ select HAVE_UBP
select HAVE_ARCH_KMEMCHECK
select HAVE_USER_RETURN_NOTIFIER
Index: new_uprobes.git/arch/x86/include/asm/ubp.h
===
--- /dev/null
+++ new_uprobes.git/arch/x86/include/asm/ubp.h
@@ -0,0 +1,40 @@
+#ifndef _ASM_UBP_H
+#define _ASM_UBP_H
+/*
+ * User-space BreakPoint support (ubp) for x86
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) IBM Corporation, 2008, 2009
+ */
+
+typedef u8 ubp_opcode_t;
+#define MAX_UINSN_BYTES 16
+#define UBP_XOL_SLOT_BYTES (MAX_UINSN_BYTES)
+
+#ifdef CONFIG_X86_64
+struct ubp_bkpt_arch_info {
+ unsigned long rip_target_address;
+ u8 orig_insn[MAX_UINSN_BYTES];
+};
+struct ubp_task_arch_info {
+ unsigned long saved_scratch_register;
+};
+#else
+struct ubp_bkpt_arch_info {};
+struct ubp_task_arch_info {};
+#endif
+
+#endif /* _ASM_UBP_H */
Index: new_uprobes.git/arch/x86/kernel/Makefile
===
--- new_uprobes.git.orig/arch/x86/kernel/Makefile
+++ new_uprobes.git/arch/x86/kernel/Makefile
@@ -116,6 +116,8 @@ obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION)
obj-$(CONFIG_SWIOTLB) += pci-swiotlb.o
+obj-$(CONFIG_UBP) += ubp_x86.o
+
###
# 64 bit specific files
ifeq ($(CONFIG_X86_64),y)
Index: new_uprobes.git/arch/x86/kernel/ubp_x86.c
===
--- /dev/null
+++ new_uprobes.git/arch/x86/kernel/ubp_x86.c
@@ -0,0 +1,577 @@
+/*
+ * User-space BreakPoint support (ubp) for x86
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) IBM Corporation, 2008, 2009
+ */
+
+#define UBP_IMPLEMENTATION 1
+
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/ptrace.h
+#include linux/ubp.h
+#include asm/insn.h
+
+#ifdef CONFIG_X86_32
+#define is_32bit_app(tsk) 1
+#else
+#define is_32bit_app(tsk) (test_tsk_thread_flag(tsk, TIF_IA32))
+#endif
+
+#define UBP_FIX_RIP_AX 0x8000
+#define UBP_FIX_RIP_CX 0x4000
+
+/* Adaptations for mhiramat x86 decoder v14. */
+#define OPCODE1(insn) ((insn)-opcode.bytes[0])
+#define OPCODE2(insn) ((insn)-opcode.bytes[1])
+#define OPCODE3(insn) ((insn)-opcode.bytes[2])
+#define MODRM_REG(insn) X86_MODRM_REG(insn-modrm.value)
+
+static void set_ip(struct pt_regs *regs, unsigned long vaddr)
+{
+ regs-ip = vaddr;
+}
+
+#ifdef CONFIG_X86_64
+static bool is_riprel_insn(struct ubp_bkpt *ubp)
+{
+ return ((ubp-fixups (UBP_FIX_RIP_AX | UBP_FIX_RIP_CX)) != 0);
+}
+
+static void cancel_xol(struct task_struct *tsk, struct ubp_bkpt *ubp)
+{
+ if (is_riprel_insn(ubp)) {
+ /*
+* We rewrote ubp-insn to use indirect
[RFC] [PATCH 3/7] Execution out of line (XOL)
Execution out of line (XOL)
Slot allocation mechanism for Execution Out of Line strategy in User
space breakpointing Inftrastructure. (XOL)
This patch provides slot allocation mechanism for execution out of
line strategy for use with user space breakpoint infrastructure.
This patch requires utrace support in kernel.
This patch provides five functions xol_get_insn_slot(),
xol_free_insn_slot(), xol_put_area(), xol_get_area() and
xol_validate_vaddr().
Current slot allocation mechanism:
1. Allocate one dedicated slot per user breakpoint.
2. If the allocated vma is completely used, expand current vma.
3. If we cant expand the vma, allocate a new vma.
Signed-off-by: Jim Keniston jkeni...@us.ibm.com
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
arch/Kconfig|4
include/linux/ubp_xol.h | 56
kernel/Makefile |1
kernel/ubp_xol.c| 644
4 files changed, 705 insertions(+)
Index: new_uprobes.git/arch/Kconfig
===
--- new_uprobes.git.orig/arch/Kconfig
+++ new_uprobes.git/arch/Kconfig
@@ -102,6 +102,10 @@ config USER_RETURN_NOTIFIER
config HAVE_UBP
def_bool n
+config UBP_XOL
+ def_bool y
+ depends on UBP UTRACE
+
config HAVE_IOREMAP_PROT
bool
Index: new_uprobes.git/include/linux/ubp_xol.h
===
--- /dev/null
+++ new_uprobes.git/include/linux/ubp_xol.h
@@ -0,0 +1,56 @@
+#ifndef _LINUX_XOL_H
+#define _LINUX_XOL_H
+/*
+ * User-space BreakPoint support (ubp) -- Allocation of instruction
+ * slots for execution out of line (XOL)
+ * include/linux/ubp_xol.h
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) IBM Corporation, 2009
+ */
+
+
+#if defined(CONFIG_UBP_XOL)
+extern unsigned long xol_get_insn_slot(struct ubp_bkpt *ubp, void *xol_area);
+extern void xol_free_insn_slot(unsigned long, void *xol_area);
+extern int xol_validate_vaddr(struct pid *pid, unsigned long vaddr,
+ void *xol_area);
+extern void *xol_get_area(struct pid *pid);
+extern void xol_put_area(void *xol_area);
+#else /* CONFIG_UBP_XOL */
+static inline unsigned long xol_get_insn_slot(struct ubp_bkpt *ubp,
+ void *xol_area)
+{
+ return 0;
+}
+static inline void xol_free_insn_slot(unsigned long slot_addr, void *xol_area)
+{
+}
+static inline int xol_validate_vaddr(struct pid *pid, unsigned long vaddr,
+ void *xol_area)
+{
+ return -ENOSYS;
+}
+static inline void *xol_get_area(struct pid *pid)
+{
+ return NULL;
+}
+static inline void xol_put_area(void *xol_area)
+{
+}
+#endif /* CONFIG_UBP_XOL */
+
+#endif /* _LINUX_XOL_H */
Index: new_uprobes.git/kernel/Makefile
===
--- new_uprobes.git.orig/kernel/Makefile
+++ new_uprobes.git/kernel/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_PERF_EVENTS) += perf_event.
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_USER_RETURN_NOTIFIER) += user-return-notifier.o
obj-$(CONFIG_UBP) += ubp_core.o
+obj-$(CONFIG_UBP_XOL) += ubp_xol.o
ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
# According to Alan Modra a...@linuxcare.com.au, the -fno-omit-frame-pointer
is
Index: new_uprobes.git/kernel/ubp_xol.c
===
--- /dev/null
+++ new_uprobes.git/kernel/ubp_xol.c
@@ -0,0 +1,644 @@
+/*
+ * User-space BreakPoint support (ubp) -- Allocation of instruction
+ * slots for execution out of line (XOL)
+ * kernel/ubp_xol.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received
[RFC] [PATCH 6/7] Uprobes Documentation
on the architecture.
+
+Here are sample overhead figures (in usec) for x86 architecture.
+
+x86: Intel Pentium M, 1495 MHz, 2957.31 bogomips
+uprobe = 2.9 usec;
+
+9. TODO
+
+a. Support for other architectures.
+b. Support return probes.
+
+10. Uprobes Team
+
+The following people have made major contributions to Uprobes:
+Jim Keniston - jkeni...@us.ibm.com
+Srikar Dronamraju - sri...@linux.vnet.ibm.com
+Ananth Mavinakayanahalli - ana...@in.ibm.com
+Prasanna Panchamukhi - prasa...@in.ibm.com
+Dave Wilder - dwil...@us.ibm.com
+
+11. Uprobes Example
+
+Here's a sample kernel module showing the use of Uprobes to count the
+number of times an instruction at a particular address is executed,
+and optionally (unless verbose=0) report each time it's executed.
+- cut here -
+/* uprobe_example.c */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/uprobes.h
+
+/*
+ * Usage: insmod uprobe_example.ko pid=pid vaddr=address [verbose=0]
+ * where pid identifies the probed process and address is the virtual
+ * address of the probed instruction.
+ */
+
+static int pid = 0;
+module_param(pid, int, 0);
+MODULE_PARM_DESC(pid, pid);
+
+static int verbose = 1;
+module_param(verbose, int, 0);
+MODULE_PARM_DESC(verbose, verbose);
+
+static long vaddr = 0;
+module_param(vaddr, long, 0);
+MODULE_PARM_DESC(vaddr, vaddr);
+
+static int nhits;
+static struct uprobe usp;
+
+static void uprobe_handler(struct uprobe *u, struct pt_regs *regs)
+{
+ nhits++;
+ if (verbose)
+ printk(KERN_INFO Hit #%d on probepoint at %#lx\n,
+ nhits, u-vaddr);
+}
+
+int __init init_module(void)
+{
+ int ret;
+ usp.pid = pid;
+ usp.vaddr = vaddr;
+ usp.handler = uprobe_handler;
+ printk(KERN_INFO Registering uprobe on pid %d, vaddr %#lx\n,
+ usp.pid, usp.vaddr);
+ ret = register_uprobe(usp);
+ if (ret != 0) {
+ printk(KERN_ERR register_uprobe() failed, returned %d\n, ret);
+ return ret;
+ }
+ return 0;
+}
+
+void __exit cleanup_module(void)
+{
+ printk(KERN_INFO Unregistering uprobe on pid %d, vaddr %#lx\n,
+ usp.pid, usp.vaddr);
+ printk(KERN_INFO Probepoint was hit %d times\n, nhits);
+ unregister_uprobe(usp);
+}
+MODULE_LICENSE(GPL);
+- cut here -
+
+You can build the kernel module, uprobe_example.ko, using the following
+Makefile:
+- cut here -
+obj-m := uprobe_example.o
+KDIR := /lib/modules/$(shell uname -r)/build
+PWD := $(shell pwd)
+default:
+ $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
+clean:
+ rm -f *.mod.c *.ko *.o .*.cmd
+ rm -rf .tmp_versions
+- cut here -
+
+For example, if you want to run myprog and monitor its calls to myfunc(),
+you can do the following:
+
+$ make // Build the uprobe_example module.
+...
+$ nm -p myprog | awk '$3==myfunc'
+080484a8 T myfunc
+$ ./myprog
+$ ps
+ PID TTY TIME CMD
+ 4367 pts/300:00:00 bash
+ 8156 pts/300:00:00 myprog
+ 8157 pts/300:00:00 ps
+$ su -
+...
+# insmod uprobe_example.ko pid=8156 vaddr=0x080484a8
+
+In /var/log/messages and on the console, you will see a message of the
+form kernel: Hit #1 on probepoint at 0x80484a8 each time myfunc()
+is called. To turn off probing, remove the module:
+
+# rmmod uprobe_example
+
+In /var/log/messages and on the console, you will see a message of the
+form Probepoint was hit 5 times.
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
* Peter Zijlstra pet...@infradead.org [2009-11-30 13:09:12]: On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote: This patch implements an in-kernel gdb stub. It provides an interface between gdb and Linux Kernel by implementing the remote serial protocol. This gdbstub uses utrace infrastructure. This patch provides register set access, signal mapping, process event handling, input/output operations. /proc/pid/gdb was chosen as file for gdb to interact with the process through remote serial protocol. Hence users would have to use target remote /proc/pid/gdb command on gdb prompt to start using this infrastructure. For Breakpointing support, gdbstub needs User space breakpointing layer and uprobes layer which will be posted later. How does this compare to kgdb and related efforts? This is a In-kernel gdbstub to debug user space programs. This stub doesnt help in debugging kernel. Hence I am not sure how to compare kgdb gdbstub with this gdbstub. Can you please provide more pointers on what you were referring to? -- Thanks and Regards Srikar
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
* Peter Zijlstra pet...@infradead.org [2009-11-30 13:41:47]: This is a In-kernel gdbstub to debug user space programs. This stub doesnt help in debugging kernel. Hence I am not sure how to compare kgdb gdbstub with this gdbstub. Can you please provide more pointers on what you were referring to? Well, not even that much was clear from your changelog, so I wasn't really sure wtf I was looking at. All it says was an in-kernel gdb stub, what other than to debug the kernel would you need in-kernel stubs for? So now my question is, what do you need an in-kernel stub to debug userspace for? This stub would allow users use features provided by utrace but through a gdb interface. This idea was brought up in this year's Tracing roundtable at the Linux Foundation Collaboration summit, April 8-10 in San Francisco. Here is the link to the minutes of the meeting sent by Christoph Hellwig. http://www.mail-archive.com/utrace-devel@redhat.com/msg00830.html In general, tell me about this patch thing, what does it do, why does it do it, and how does it improve on the current situation. This is suppose to be one of the interfaces to use utrace, i.e Allow gdb to use utrace features without having to change gdb itself. Though there are not enough features in this patch, intentions include support multi-threaded debugging, concurrent debugger support for same process, syscall tracing. For Breakpoint support(not yet submitted to LKML), it would use execution out of line rather than the conventional inline-single stepping. I guess Christoph, Roland and Frank would be able to explain in a better fashion the rational and advantages of this stub over convential gdb. Your changelog doesn't address any of those things, so wth are we supposed to think? Thanks for pointing out. -- Thanks and Regards Srikar
Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.
I guess Christoph, Roland and Frank would be able to explain in a better fashion the rational and advantages of this stub over convential gdb. Hmm,. wouldn't it make much more sense to extend the current kgdb stub to include userspace debugging, providing an all-in-one solution? I see two limitations but I guess there could be ways to get over it. 1. gdb requiring file that needs to be debugged. I always thought it can either be a user program or a vmlinux file. gdb makes most of the information(i.e registers) from the remote protocol to display the backtrace, variable values and the like by reading this file. 2. Also I am not sure if gdb has a way to tell the remote to switch the context and provide information(registers) pertaining to the user mode/ kernel mode. There could be other limitations too that I may not be aware. I think it would be much more powerful to be able to observe the full software stack and not be limited by this user-kernel barrier. (Provided the user has sufficient privileges of course). In this implementation, the current user can debug his/her own processes. May be if we can debug both the context from same gdb then we might have to place restrictions.. -- Thanks and Regards Srikar
Re: [RFC,PATCH 0/14] utrace/ptrace
Hi Christoph, The other thing is that this patchset really doesn't quite justify utrace. It's growing a lot more code without actually growing any useful functionality. What about all those other utrace killer features that have been promised for a long time? We are working on in-kernel gdbstub which was one of the features that you had asked for. gdbstub does pass unit tests; but we are looking at some way to hack the GDB testsuite to run its regression tests. Once we are able to run the GDB testsuite and utrace is part of some upstream tree, we plan to post these patches to LKML for comments. gdbstub uses utrace and uprobes underneath. Uprobes was rewritten to remove issues that LKML developers had opposed. Uprobes also has its own ftrace plugin to use uprobes. Currently in-kernel gdbstub is hosted by Frank Ch. Eigler over here: git://web.elastic.org/~fche/utrace-ext.git branch name utrace-gdbstub-uprobes -- Regards Srikar
Re: [PATCH 1-13] utrace-ptrace V1, for internal review
Hi Oleg, Roland, Ananth When I get the latest set of ptrace-tests by using. cvs -d :pserver:anoncvs:anon...@sources.redhat.com:/cvs/systemtap co ptrace-tests I get errors when I run make syscall-from-clone.c: In function âmainâ: syscall-from-clone.c:127: error: storage size of âregsâ isnât known syscall-from-clone.c:202: error: âPTRACE_GETREGSâ undeclared (first use in this function) syscall-from-clone.c:202: error: (Each undeclared identifier is reported only once syscall-from-clone.c:202: error: for each function it appears in.) cc1: warnings being treated as errors syscall-from-clone.c:127: warning: unused variable âregsâ make[2]: *** [syscall-from-clone.o] Error 1 make[2]: Leaving directory `/home/srikar/work/ptrace-tests/tests' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/srikar/work/ptrace-tests/tests' make: *** [all-recursive] Error 1 I find that the errors are because there is no definition of user_regs_struct for powerpc. Something similar seems to be defined for x86. These errors occur even with upstream kernel. Hence can you confirm 1. Am I using the right source of ptrace-tests or has its location changed. 2. Are these new testcases x86 architecture specific? 3. Shouldn't arch/powerpc/include/asm/user.h not define user_regs_struct? -- Thanks and Regards Srikar
Re: [PATCH 3] ptrace: introduce user_single_step_siginfo() helper
+#ifdef ARCH_HAS_USER_SINGLE_STEP_INFO
+extern void user_single_step_siginfo(struct task_struct *tsk,
+ struct pt_regs *regs, siginfo_t *info);
+#else
+static inline void user_single_step_siginfo(struct task_struct *tsk,
+ struct pt_regs *regs, siginfo_t *info)
+{
+ memset(info, 0, sizeof(*info));
+ info-si_signo = SIGTRAP;
Is it possible to add si_code and si_addr info
info-si_code = TRAP_TRACE;
info-si_addr = instruction_pointer(regs);
+}
+#endif
+
Thanks and Regards
-Srikar
Re: [PATCH 3/7] ptrace_init_task: cleanup the usage of ptrace_link()
* Oleg Nesterov o...@redhat.com [2009-10-26 04:28:46]:
@@ -169,9 +164,9 @@ static inline void ptrace_init_task(stru
INIT_LIST_HEAD(child-ptraced);
child-parent = child-real_parent;
child-ptrace = 0;
- if (unlikely(ptrace)) {
+ if (unlikely(ptrace) (current-ptrace PT_PTRACED)) {
Any reason for directly accessing current-ptrace instead of accessing
thro task_ptrace(current) ?
Also would something like this suffice.
+ if (unlikely(ptrace) (task_ptrace(current)) {
i.e the first patch in this series removes checks to see if ptrace field
is set with PT_TRACED.
task_ptrace() != 0 if and only if PT_PTRACED bit is set, kill
some PT_PTRACED checks in tracehook.h.
Can you please explain how this situation is different from the
situation in tracehook.h?
child-ptrace = current-ptrace;
--
Thanks and Regards
Srikar
[PATCH] For selinux sake allocate a fake unlinked shmem
Hi Frank, Jim, Mark,
This fix is equivalent to commit
a82ac1f413712a375d5e14ef7641ce0abf7a6543 in systemtap tree.
--
We allocate a fake unlinked shmem file because anonymous
memory might not be granted execute permission when the
selinux security hooks have their way.
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
Signed-off-by: Mark Wielaard m...@redhat.com
---
kernel/ubp_xol.c | 38 --
1 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/kernel/ubp_xol.c b/kernel/ubp_xol.c
index 017b3cf..4205ab7 100644
--- a/kernel/ubp_xol.c
+++ b/kernel/ubp_xol.c
@@ -35,6 +35,7 @@
#include linux/ubp.h
#include linux/errno.h
#include linux/mman.h
+#include linux/file.h
#define UINSNS_PER_PAGE(PAGE_SIZE/UBP_XOL_SLOT_BYTES)
@@ -339,6 +340,7 @@ static inline struct ubp_xol_vma *xol_add_vma(struct
ubp_xol_area *area)
struct vm_area_struct *vma;
struct ubp_xol_vma *usv;
struct mm_struct *mm;
+ struct file *file;
unsigned long addr;
mm = get_task_mm(current);
@@ -356,22 +358,31 @@ static inline struct ubp_xol_vma *xol_add_vma(struct
ubp_xol_area *area)
* Find the end of the top mapping and skip a page.
* If there is no space for PAGE_SIZE above
* that, mmap will ignore our address hint.
+*
+* We allocate a fake unlinked shmem file because
+* anonymous memory might not be granted execute
+* permission when the selinux security hooks have
+* their way.
*/
vma = rb_entry(rb_last(mm-mm_rb), struct vm_area_struct, vm_rb);
addr = vma-vm_end + PAGE_SIZE;
- addr = do_mmap_pgoff(NULL, addr, PAGE_SIZE, PROT_EXEC,
- MAP_PRIVATE|MAP_ANONYMOUS, 0);
- if (addr ~PAGE_MASK) {
- up_write(mm-mmap_sem);
- mmput(mm);
- printk(KERN_ERR ubp_xol failed to allocate a vma for
-pid/tgid %d/%d for single-stepping out of line.\n,
+ file = shmem_file_setup(uprobes/ssol, PAGE_SIZE, VM_NORESERVE);
+ if (!file) {
+ printk(KERN_ERR ubp_xol failed to setup shmem_file while
+ allocating vma for pid/tgid %d/%d for
+ single-stepping out of line.\n,
current-pid, current-tgid);
- kfree(usv-bitmap);
- kfree(usv);
- return ERR_PTR(-ENOMEM);
+ goto fail;
}
+ addr = do_mmap_pgoff(file, addr, PAGE_SIZE, PROT_EXEC, MAP_PRIVATE, 0);
+ fput(file);
+ if (addr ~PAGE_MASK) {
+ printk(KERN_ERR ubp_xol failed to allocate a vma for pid/tgid
+%d/%d for single-stepping out of line.\n,
+ current-pid, current-tgid);
+ goto fail;
+ }
vma = find_vma(mm, addr);
BUG_ON(!vma);
@@ -392,6 +403,13 @@ static inline struct ubp_xol_vma *xol_add_vma(struct
ubp_xol_area *area)
list_add_tail(usv-list, area-vmas);
area-last_vma = usv;
return usv;
+
+fail:
+ up_write(mm-mmap_sem);
+ mmput(mm);
+ kfree(usv-bitmap);
+ kfree(usv);
+ return ERR_PTR(-ENOMEM);
}
/* Runs with area-mutex locked */
[PATCH 0/2] Code cleanup patches.
This patchset just does code cleanup and no additional bugfixes or features. After applying this patchset, checkpatch reports: total: 0 errors, 0 warnings, 0 checks, 1560 lines checked Subject: [PATCH 0/2] Code cleanup patches. File: /tmp/gdbstub-patches/4/intro Subject: [PATCH 1/2] Make gdbstub as per coding guidelines. File: /tmp/gdbstub-patches/4/1.patch Subject: [PATCH 2/2] use reusable functions wherever possible. File: /tmp/gdbstub-patches/4/2.patch
[PATCH 2/2] use reusable functions wherever possible.
Remove duplicate code where possible by using reusable functions.
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
kernel/utrace-gdb.c | 272 +++
1 files changed, 123 insertions(+), 149 deletions(-)
diff --git a/kernel/utrace-gdb.c b/kernel/utrace-gdb.c
index f44b3c0..97811c2 100644
--- a/kernel/utrace-gdb.c
+++ b/kernel/utrace-gdb.c
@@ -793,6 +793,84 @@ static int gdb_remote_register_info(struct gdb_connection
*p,
return -ENOENT;
}
+static inline int fetch_remote_register_info(struct gdb_connection *p,
+ struct task_struct *task,
+ int index,
+ unsigned *pos,
+ unsigned *count,
+ unsigned *bytes)
+{
+ int rsn;
+
+ rsn = gdb_remote_register_info(p, task, index, pos, count, bytes);
+ pr_debug(gdb register %u = rsn %d p%u c%u b%u\n, index, rsn,
+ *pos, *count, *bytes);
+ if (rsn 0) {
+ /*
+* If we want to extract register data, make sure we're
+* fetching at least that much.
+*/
+ BUG_ON(*count 0 *count *bytes);
+ /* Assert reg_contents size is right. */
+ BUG_ON(MAX_REG_WIDTH *bytes || MAX_REG_WIDTH *count);
+ }
+ return rsn;
+}
+
+static inline int get_set_regset_view(struct task_struct *task,
+ unsigned pos, unsigned count,
+ unsigned char *reg_contents,
+ int rsn, bool set)
+{
+ int rc;
+ const struct user_regset_view *rsv;
+ const struct user_regset *rs;
+
+ if (!count) {
+ if (!set)
+ memset(reg_contents, 0, MAX_REG_WIDTH);
+ return 0;
+ }
+
+ /* real register */
+ if (set)
+ BUG_ON(count MAX_REG_WIDTH);
+
+ rsv = task_user_regset_view(task);
+ BUG_ON(rsn = rsv-n);
+ rs = rsv-regsets[rsn];
+
+ /* Extract the register values into reg_contents[]. */
+ if (set)
+ rc = (rs-set)(task, rs, pos, count, reg_contents, NULL);
+ else
+ rc = (rs-get)(task, rs, pos, count, reg_contents, NULL);
+
+ return rc;
+}
+
+static inline void prepare_regset_set(struct gdb_connection *p,
+ unsigned char *reg_contents,
+ size_t *start, unsigned bytes)
+{
+ int j;
+
+ /*
+* 0-fill the register copy.
+* XXX initialize it from rs-get() instead?
+*/
+ memset(reg_contents, 0, MAX_REG_WIDTH);
+
+ /*
+* Hex-unconvert all the bytes.
+* XXX: endianness adjust for count != bytes
+*/
+ for (j = 0; j bytes; j++)
+ reg_contents[j] = byteme(p-input_buf[*start + 2 * j],
+ p-input_buf[*start + 2 * j + 1]);
+ *start += 2 * bytes;
+}
+
/*
* Process an entire, checksum-confirmed $command# at the front of
* p-input_buf[]. The input and output mutexes are being held.
@@ -880,50 +958,23 @@ static void handle_gdb_command_packet(struct
gdb_connection *p,
unsigned rs_count;
unsigned rs_pos;
unsigned bytes;
- const struct user_regset_view *rsv;
- const struct user_regset *rs;
+ int rsn;
unsigned char reg_contents[MAX_REG_WIDTH];
- int rsn = gdb_remote_register_info(p, task, i,
- rs_pos, rs_count,
- bytes);
-
+ rsn = fetch_remote_register_info(p, task, i,
+ rs_pos, rs_count, bytes);
if (rsn 0)
break;
- /*
-* If we want to extract register data, make sure
-* we're fetching at least that much.
-*/
- BUG_ON(rs_count 0 rs_count bytes);
- /* Assert reg_contents size is right. */
- BUG_ON(sizeof(reg_contents) bytes ||
- sizeof(reg_contents) rs_count);
-
- if (rs_count) { /* real register */
- rsv = task_user_regset_view(task);
- BUG_ON(rsn = rsv-n);
- rs = rsv-regsets[rsn];
-
- /*
-* Extract the register values into
-* reg_contents
[PATCH 1/3] rework report_signal callback.
Redo report_signal callback().
1. Ensure we dont mistake signal_action just because another engine's
report_signal callback has messed with UTRACE_SIGNAL_REPORT. i.e check
orig_ka.
2. gdbstub works similarly irrespective of the order of the engines
attached. If gdbstub attaches to a process thats already traced with
uprobes then uprobes engine report_* callbacks tend to be called before
gdbstub report_* callbacks.
3. This patch adds a additional field in gdb_connection
current_gdb_uprobe that tracks the gdb_uprobe struct for the active
uprobe.
4. This patch also adds find_gdb_uprobe() and find_gdb_connection
helper functions.
5. No need to lock gdb_connections_mutex when unregistering uprobes.
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
kernel/utrace-gdb.c | 334 +++
1 files changed, 202 insertions(+), 132 deletions(-)
diff --git a/kernel/utrace-gdb.c b/kernel/utrace-gdb.c
index ac653fe..f8a07af 100644
--- a/kernel/utrace-gdb.c
+++ b/kernel/utrace-gdb.c
@@ -34,8 +34,10 @@
#include linux/regset.h
#include linux/utrace.h
#include linux/tracehook.h
+#ifdef CONFIG_HAVE_UPROBES
#include linux/uprobes.h
#include linux/ubp.h
+#endif
/** struct gdb_connection - Tracks one active gdb-process session.
@@ -63,7 +65,18 @@ struct gdb_connection {
int pass_signals;
int stop_signals;
/* XXX: per-thread later */
+
+#ifdef CONFIG_HAVE_UPROBES
+ /*
+* gdb_engine need not always be attached to the process before
+* uprobes_engine. If uprobe's engine report_signal callback is
+* called first, it would change the instruction address. Checking
+* if the corresponding uprobe is disarmed can be easily be done by
+* caching the gdb_uprobe pointer.
+*/
+ struct gdb_uprobe *current_gdb_uprobe; /* XXX: per-thread later */
struct list_head uprobes;
+#endif
char output_buf[GDB_BUFMAX];
size_t output_buf_size;
@@ -228,36 +241,78 @@ static void push_output_packet (struct gdb_connection *p,
const char *s)
push_output_packet_end(p, start);
}
+static inline struct gdb_connection *find_gdb_connection(
+ struct task_struct *task)
+{
+ struct gdb_connection *gc = NULL;
+ mutex_lock(gdb_connections_mutex);
+ list_for_each_entry(gc, gdb_connections, link) {
+ if (gc-target == task_tgid_nr(task))
+ goto out_connection;
+ }
+
+out_connection:
+ mutex_unlock(gdb_connections_mutex);
+ return gc;
+}
/* */
-static bool can_gdb_handle_sigtrap(struct pt_regs *regs,
+#ifdef CONFIG_HAVE_UPROBES
+
+static inline struct gdb_uprobe *find_gdb_uprobe(unsigned long addr,
struct gdb_connection *p)
{
-unsigned long bkpt = ubp_get_bkpt_addr (regs);
-struct task_struct *task = current;
+ struct gdb_uprobe *gup, *gup2;
- if (p-target == task_tgid_nr(task)) {
- struct list_head *l;
- struct list_head *l2;
- struct gdb_uprobe *gup = NULL;
+ list_for_each_entry_safe(gup, gup2, p-uprobes, link) {
+ pr_debug(considering addr=%p %s\n, (void *)gup-up.vaddr,
+ gup-disarmed_p ? disarmed : );
+ if (gup-up.vaddr == addr)
+ return gup;
+ }
+ return NULL;
+}
- list_for_each_safe(l, l2, p-uprobes) {
- gup = list_entry(l, struct gdb_uprobe, link);
- pr_debug(considering addr=%p %s\n,
- (void *)gup-up.vaddr,
- gup-disarmed_p ? disarmed : );
- if (gup-up.vaddr == bkpt !gup-disarmed_p)
- return true;
- }
+/*
+ * If no breakpoint, return false;
+ * If breakpoint and breakpoint is disarmed; return true
+ * If breakpoint and breakpoint is not disarmed; return false
+ */
+static inline bool is_bkpt_disarmed(struct pt_regs *regs,
+ struct gdb_connection *p)
+{
+ struct gdb_uprobe *gup = p-current_gdb_uprobe;
+
+ if (!gup) {
+ unsigned long addr = ubp_get_bkpt_addr(regs);
+
+ /*
+* gup will be non-NULL iff uprobe engine report_signal
+* callback was called before gdbstub engine's report_signal
+* callback. i.e gdb_uprobe_handler was just called before
+* calling this report_signal callback.
+*/
+ gup = find_gdb_uprobe(addr, p);
}
+ if (gup)
+ return gup-disarmed_p;
+
return false;
}
-#ifdef CONFIG_HAVE_UPROBES
/* uprobe callback */
void gdb_uprobe_handler
[PATCH 3/3] Fix a bug in defer registration patch.
This patch fixes the leak in uproc refcount when a tracing thread does
defer_registration.
When threads queue defer_registration, uprobes was leaking uproc
refcount. If a tracing process requested a [un]register operation that
was defered, then subsequent removal of all probes would still keep the
uprobes engine active till the thread dies.
Jim Keniston's observation on uprobes lifetime made me figure out an
error in defer_registration patch that I sent earlier.
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
kernel/uprobes_core.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/uprobes_core.c b/kernel/uprobes_core.c
index d784d4a..27c2977 100644
--- a/kernel/uprobes_core.c
+++ b/kernel/uprobes_core.c
@@ -945,10 +945,8 @@ int register_uprobe(struct uprobe *u)
*/
BUG_ON(utask-state != UPTASK_SSTEP);
if (task_is_stopped_or_traced(utask-tsk)) {
- put_pid(p);
ret = defer_registration(u, 1, utask);
- up_write(uproc-rwsem);
- return ret;
+ goto fail_uproc;
}
}
} else {
@@ -1127,10 +1125,8 @@ void unregister_uprobe(struct uprobe *u)
/* See comment in register_uprobe(). */
BUG_ON(utask-state != UPTASK_SSTEP);
if (task_is_stopped_or_traced(utask-tsk)) {
- put_pid(p);
(void) defer_registration(u, 0, utask);
- up_write(uproc-rwsem);
- return;
+ goto done;
}
}
uk = (struct uprobe_kimg *)u-kdata;
Should SIGNAL_REPORT take preference to queued signal?
Hi Roland, Oleg I hit upon a case where a traced thread steps over a inserted breakpoint instruction, and the tracing engine requests the traced thread to be interrupted. Here the traced thread calls report_signal callback with UTRACE_REPORT_SIGNAL and later does a report_signal callback with UTRACE_SIGNAL_CORE. We do have a comment in utrace_get_signal() which does indicate the behaviour I see. /* * We've been asked for an explicit report before we * even check for pending signals. */ However I was looking if there were reasons why interrupt from a tracing thread would be preferred over a queued signal? I am seeing this situation in Uprobes. A uprobes enabled tracer wanted to remove a breakpoint and hence requested the thread to stop using utrace_control with action being UTRACE_STOP. Since utrace_control returns -EINPROGRESS, and thread state _not_ being in TASK_INTERRUPTIBLE state, the tracer requests for utrace_control with action this time being UTRACE_INTERRUPT. Right at this time, the tracing thread steps over the trap. This causes uprobe_report_signal() to be called with signal_action == UTRACE_SIGNAL_REPORT instead of (say) UTRACE_SIGNAL_CORE. Now tracer is able to remove the breakpoint. However on resuming the thread sees that it has a signal pending and delivers the signal, this time lets say action is UTRACE_SIGNAL_CORE. Since uprobes doesnt see a breakpoint there, it resumes. However resuming after stepping a breakpoint but without fix-ups could lead to disastrous results. Currently we do have a way in uprobes to handle this situation. i.e to check if any threads have stepped on breakpoint instruction related to the breakpoint that we are removing and if there are any such threads then fixup their Instruction Pointers. -- Thanks and Regards Srikar
[PATCH 0/2] Allow deferred registration if thread is stopped.
Hi, This is an attempt to solve the first problem that I talked in the previous patchset. 1. register_uprobe/unregister_uprobe may cause deadlock Currently if uprobes engine were in the midst of singlestepping a breakpoint, it wouldnt allow register/unregister of probes to continue until the singlestep operation completes. However tracing thread that could be registering/unregistering a probe could have already requested the thread that was in the midst of singlestepping to STOP. This leads to a deadlock, - register/unregistering thread waits for reg/unreg to complete before resuming the thread - singlestepping thread waiting for it to be resumed and complete singlestepping before it could quiesce and allow register/unregister to complete. This patch tries to fix this problem by using the existing defer_registration. Once we defer the request, the registering thread would then resume the singlestepping thread which would pick up the deferred registration. Subject: [PATCH 0/2] Fixes to gdbstub. File: /tmp/gdbstub-patches/2/intro Subject: [PATCH 1/2] Defer register/unregister if thread is stopped. File: /tmp/gdbstub-patches/2/uc_make_defer_un_register_uprobe.patch Subject: [PATCH 2/2] Allow deferred register/unregister of uprobes. File: /tmp/gdbstub-patches/2/gs_use_deferred_register_uprobe.patch -- Thanks and Regards Srikar Dronamraju
[PATCH 2/2] Allow deferred register/unregister of uprobes.
commit 20744cb97a3e4aec63ba7b92ce4115170fd468d6
Author: Srikar Dronamraju sri...@linux.vnet.ibm.com
Date: Wed Aug 19 12:26:15 2009 +0530
Use deferred registration facility for register_uprobe
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
---
kernel/utrace-gdb.c | 75 +-
1 files changed, 55 insertions(+), 20 deletions(-)
diff --git a/kernel/utrace-gdb.c b/kernel/utrace-gdb.c
index 29e9c05..ac653fe 100644
--- a/kernel/utrace-gdb.c
+++ b/kernel/utrace-gdb.c
@@ -259,6 +259,37 @@ static bool can_gdb_handle_sigtrap(struct pt_regs *regs,
void gdb_uprobe_handler(struct uprobe *up, struct pt_regs *regs)
{
}
+
+void gdb_register_complete(struct uprobe *up, int regflag, int ret)
+{
+ if (regflag) { /* register_uprobe */
+ struct gdb_uprobe *gup;
+ struct gdb_connection *gp = NULL, *p = NULL;
+
+ mutex_lock(gdb_connections_mutex);
+ list_for_each_entry(p, gdb_connections, link) {
+ if (p-target == task_tgid_nr(current)) {
+ gp = p;
+ break;
+ }
+ }
+ mutex_unlock(gdb_connections_mutex);
+
+ if (!gp)
+ return;
+
+ gup = container_of(up, struct gdb_uprobe, up);
+ if (ret) {
+ /* register_uprobe failed */
+ kfree(gup);
+ return;
+ }
+ /* Dont bother to use a callback for unregister */
+ up-registration_callback = NULL;
+ INIT_LIST_HEAD(gup-link);
+ list_add_tail(gup-link, gp-uprobes);
+ }
+}
#endif /* CONFIG_HAVE_UPROBES */
@@ -1058,26 +1089,30 @@ static void handle_gdb_command_packet (struct
gdb_connection *p, struct task_str
}
}
-if (gup == NULL) {
-gup = kzalloc(sizeof (struct gdb_uprobe),
GFP_KERNEL);
-if (!gup) {
-push_output_packet(p, E04);
-} else {
-gup-up.pid = task-tgid;
-gup-up.vaddr = arg2;
-gup-up.handler = gdb_uprobe_handler;
-rc = register_uprobe ( gup-up);
-if (rc != 0) {
-kfree (gup);
-push_output_packet (p, E06);
-} else {
-INIT_LIST_HEAD( gup-link);
-list_add_tail(gup-link,
p-uprobes);
-push_output_packet(p, OK);
-}
-}
-}
-}
+ if (gup)/* breakpoint already exists */
+ break;
+
+ gup = kzalloc(sizeof(struct gdb_uprobe), GFP_KERNEL);
+ if (!gup) {
+ push_output_packet(p, E04);
+ break;
+ }
+ gup-up.pid = task-tgid;
+ gup-up.vaddr = arg2;
+ gup-up.handler = gdb_uprobe_handler;
+ gup-up.registration_callback = gdb_register_complete;
+ rc = register_uprobe(gup-up);
+ if (rc rc != -EINPROGRESS) {
+ kfree(gup);
+ push_output_packet(p, E06);
+ } else {
+ push_output_packet(p, OK);
+ if (!rc) { /* register_uprobe succeed */
+ INIT_LIST_HEAD(gup-link);
+ list_add_tail(gup-link, p-uprobes);
+ }
+ }
+ }
break;
case 'z': /* TYPE,ADDR,LENGTH */
rc = sscanf( p-input_buf[2], %lu,%lx,%lx, arg1, arg2,
arg3);
[PATCH] Fix missing reference count
Hi Frank, Please review and accept the patch. Missed utrace_engine_put() could lead to engine leaks After reading through https://www.redhat.com/archives/utrace-devel/2009-August/msg00093.html mail and from utrace code, it looks like we are leaking references to engine. Hence this patch. Missed utrace_engine_put() could lead to engine leaks. This patch also partially undoes one of my previous changes to gdbstub. Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com --- kernel/ubp_xol.c |1 + kernel/uprobes_core.c |1 + kernel/utrace-gdb.c |1 + 3 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/ubp_xol.c b/kernel/ubp_xol.c index f0a1a10..017b3cf 100644 --- a/kernel/ubp_xol.c +++ b/kernel/ubp_xol.c @@ -130,6 +130,7 @@ static int xol_create_engine(struct pid *pid, struct ubp_xol_area *area) WARN_ON(result == -EINPROGRESS); kref_get(area-kref); put_pid(pid); + utrace_engine_put(engine); return 0; } diff --git a/kernel/uprobes_core.c b/kernel/uprobes_core.c index f059e3c..74d568b 100644 --- a/kernel/uprobes_core.c +++ b/kernel/uprobes_core.c @@ -640,6 +640,7 @@ static struct uprobe_task *uprobe_add_task(struct pid *p, * with the engine in place, the appropriate report_* callback * should handle it after we release uproc-rwsem. */ + utrace_engine_put(engine); return utask; } diff --git a/kernel/utrace-gdb.c b/kernel/utrace-gdb.c index d7b3b58..21bf995 100644 --- a/kernel/utrace-gdb.c +++ b/kernel/utrace-gdb.c @@ -1200,6 +1200,7 @@ static int proc_gdb_open(struct inode *inode, struct file *filp) if (!ret) ; + utrace_engine_put(p-engine); filp-private_data = p; INIT_LIST_HEAD( p-link);
Re: [PATCH 09] move -ptrace == 0 checks to ptrace_attach_task()
Hi Oleg,
--- PU/kernel/ptrace.c~09_MV_PTRACE_CK2009-08-19 16:49:25.0
+0200
+++ PU/kernel/ptrace.c2009-08-20 20:04:59.0 +0200
@@ -471,35 +471,47 @@ static int ptrace_attach_task(struct tas
{
struct utrace_engine *engine;
unsigned long events;
+ int err = -EPERM;
engine = utrace_attach_task(tracee, UTRACE_ATTACH_CREATE |
UTRACE_ATTACH_EXCLUSIVE |
UTRACE_ATTACH_MATCH_OPS,
ptrace_utrace_ops, NULL);
if (unlikely(IS_ERR(engine))) {
- int err = PTR_ERR(engine);
- if (err != -ESRCH err != -ERESTARTNOINTR)
- err = -EPERM ;
+ if (PTR_ERR(engine) == -ESRCH ||
+ PTR_ERR(engine) == -ERESTARTNOINTR)
+ err = PTR_ERR(engine);
return err;
}
+
/*
- * We need QUIESCE for resume handling, CLONE to check
- * for CLONE_PTRACE, other events are always reported.
- */
- events = UTRACE_EVENT(QUIESCE) | UTRACE_EVENT(CLONE) |
- UTRACE_EVENT(EXEC) | UTRACE_EVENT_SIGNAL_ALL;
- /*
- * It can fail only if the tracee is dead, the caller
- * must notice this before setting PT_PTRACED.
+ * Check -ptrace to make sure we don't race with the previous
+ * tracer which didn't finish detach. If it is clear, nobody
+ * can change it except us due to UTRACE_ATTACH_EXCLUSIVE.
*/
- utrace_set_events(tracee, engine, events);
+ if (unlikely(tracee-ptrace)) {
Any reason why we cant move this check before we do utrace_attach_task?
+ utrace_control(tracee, engine, UTRACE_DETACH);
--
Thanks and Regards
Srikar
Re: [PATCH 09] move -ptrace == 0 checks to ptrace_attach_task()
Hi Oleg, Thanks for the clarification. Please note the comment, this check relies on UTRACE_ATTACH_EXCLUSIVE above. Once we see -ptrace = 0 after utrace_attach_task(), nobody can change -ptrace. However after attaching an engine exclusively, (which would mean the child is not traced or was detached, or is about to be detached,) we may still find -ptrace to be non-NULL and detach the engine. Currently we do ptrace_detach_task() just before __ptrace_unlink(). Is there any specific reason to do ptrace_detach_task() before __ptrace_unlink()? Is it possible to have ptrace_detach_task() which is not immediately followed by __ptrace_unlink()? If there is no such possibility then can we do ptrace_detach_task() after __ptrace_unlink(). This could mean attaching an engine with UTRACE_ATTACH_EXCLUSIVE flag set is enough to say -ptrace = 0 -- Thanks and Regards Srikar
[PATCH 0/4] Fixes to gdbstub.
Hi Frank, Please review the set of patches for gdbstub. These are based on your maintained tree. utrace-next/utrace-gdbstub-uprobes branch. (1afe698c3228e67c43db6343b383a13e27e7f11a) I have explicitly run checkpatch.pl to remove any formatting warnings / errors. However the formatting in these patches may be different from other parts of the code. At this time we have couple of known issues. 1. register_uprobe/unregister_uprobe may cause deadlock( I am looking at this). 2. Even when we havent registered a breakpoint, there is a request for breakpoint. (Not sure why gdbstub is asking for the breakpoint which is never hit). 3. Sometimes entering data when the first breakpoint gets hit results in SIGSTOP being sent to the traced process. 4. Uprobes may do postprocessing even when singlestep hasnt happened. (I am looking at this too). 5. Supporting Multithreaded programs. Also we might have to do cleaning up of code as per checkpatch.pl before submission to LKML. Subject: [PATCH 0/4] Fixes to gdbstub. File: /tmp/gdbstub-patches/1/intro Subject: [PATCH 1/4] Fix report signal callback to work more reliably. File: /tmp/gdbstub-patches/1/gdbstub_signal_callback.patch Subject: [PATCH 2/4] Fix possible double detach of engine File: /tmp/gdbstub-patches/1/fix_double_detach.patch Subject: [PATCH 3/4] Unregister uprobes after detach gdbstub engine File: /tmp/gdbstub-patches/1/unreg_after_detach.patch Subject: [PATCH 4/4] Stop once even for multiple interrupt requests File: /tmp/gdbstub-patches/1/only_stop_once.patch -- Thanks and Regards Srikar Dronamraju
[PATCH 3/4] Unregister uprobes after detach gdbstub engine
commit 90cc0931707c99459aea0f6601d7f5ce2756dbd8
Author: Srikar Dronamraju sri...@linux.vnet.ibm.com
Date: Wed Aug 19 10:26:00 2009 +0530
While releasing, unregister uprobes if any after detach
Currently because of the way uprobes works, (register/unregister may
deadlock if one of the threads of this process is expecting a singlestep
to complete and someother engine as already stopped that thread. [ I am
looking into this issue])
gdb requests register and unregister of all probes when it hits any
breakpoints. However gdb through another engine stops the thread. At this
time uprobes may have initiated singlestep but yet to be completed.
Frank has converted register/unregister of breakpoints to
setting/unsetting a flag.
Hence once registered, unregister of probes occurs at closing of gdb
connection. At that time the deadlock situation may again occur.
This patch moves the unregister of uprobes (which is independent of
the gdbstub engine) to after detach.
This is a simple and harmless workaround for now.
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
diff --git a/kernel/utrace-gdb.c b/kernel/utrace-gdb.c
index 8cf2b0f..7d32264 100644
--- a/kernel/utrace-gdb.c
+++ b/kernel/utrace-gdb.c
@@ -1228,21 +1228,6 @@ static int proc_gdb_release(struct inode *inode, struct
file *filp)
int ret = 0;
mutex_lock ( gdb_connections_mutex);
-
-#ifdef CONFIG_HAVE_UPROBES
-{
-struct list_head *l;
-struct list_head *l2;
-list_for_each_safe(l, l2, p-uprobes) {
-struct gdb_uprobe *gup = list_entry (l, struct
gdb_uprobe, link);
-if (task) /* Not dead yet. */
-unregister_uprobe ( gup-up);
-list_del ( gup-link);
-kfree (gup);
-}
-}
-#endif /* CONFIG_HAVE_UPROBES */
-
if (task == NULL) {
/* The thread is already gone; report_death was already
called. */
pr_debug(gdb %d releasing old\n, p-target);
@@ -1259,6 +1244,20 @@ static int proc_gdb_release(struct inode *inode, struct
file *filp)
ret = utrace_barrier(task, p-engine);
}
+#ifdef CONFIG_HAVE_UPROBES
+ {
+ struct list_head *l, *l2;
+ list_for_each_safe(l, l2, p-uprobes) {
+ struct gdb_uprobe *gup =
+ list_entry(l, struct gdb_uprobe, link);
+ if (task) /* Not dead yet. */
+ unregister_uprobe(gup-up);
+ list_del(gup-link);
+ kfree(gup);
+ }
+ }
+#endif /* CONFIG_HAVE_UPROBES */
+
list_del(p-link);
kfree(p);
[PATCH 4/4] Stop once even for multiple interrupt requests
commit bd86cff51a2f221b6cb10649212e5392aea7bcb7
Author: Srikar Dronamraju sri...@linux.vnet.ibm.com
Date: Wed Aug 19 11:43:53 2009 +0530
We only need to intimate gdb once if we get multiple requests for look
There can be multiple stop requests before gdb gets control. However continue
from gdb can resulting in the process again being stopped because we are just
decrementing the count and not clearing it.
I dont see a reason why gdb should return control after asked to continue unless
there is a new request for stop.
The other way to do this could be to make stop_signals a bool instead of
integer.
Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
diff --git a/kernel/utrace-gdb.c b/kernel/utrace-gdb.c
index 7d32264..5d18759 100644
--- a/kernel/utrace-gdb.c
+++ b/kernel/utrace-gdb.c
@@ -388,7 +388,7 @@ u32 gdb_utrace_report_signal(u32 action,
case UTRACE_SIGNAL_REPORT: /* case 3 */
if (p-stop_signals 0) {
-p-stop_signals --;
+ p-stop_signals = 0;
snprintf (p-stopcode, GDB_BUFMAX, S%02x, 2); /*
SIGINT */
push_output_packet (p, p-stopcode);
p-at_quiesce_do = UTRACE_STOP;
Re: resume from another engine results in loss of singlestep req.
Could you show the code please? I don't really understand how it looks with 1+2 above. I am attaching the code. The module code is in try_utrace/probe5_a.c and try_utrace/probe5_b.c. But, just in case... I think module_b should re-assert SINGLESTEP from either report_quiesce/report_signal. Yes I have re-asserted SINGLESTEP. I also have printk's in report_quiesce/report_signal to see if report_quiesce/report_signal in probe5_b are called after we do utrace_control(.,,UTRACE_RESUME/UTRACE_DETACH). However those callbacks dont seem to be called again. -- Thanks and Regards Srikar trial2.tgz Description: application/tar-gz
Re: resume from another engine results in loss of singlestep req.
Aaahhh. Srikar, I spent 3 hours trying to understand Your code does NOT reassert SINGLESTEP. Of course, -report_signal is not called again, utrace_get_signal() just clears -report when it is called after wakeup. Because you forgot to add QUIESCE to utrace_set_events's mask !!! Oh Sorry for the trouble. Yes setting QUIESCE in utrace_set_events makes it work. -- Thanks and Regards Srikar
resume from another engine results in loss of singlestep req.
Hi Roland, If we have two utrace engines for a thread with first engine requesting UTRACE_STOP and second one requesting UTRACE_SINGLESTEP, utrace correctly gives priority to UTRACE_STOP. However when the first engine detaches(or resumes) the singlestep request from the second engine is not given preference and the traced thread resumes instead of single stepping. The second engine doesnt even get a chance to re-assert singlestep. If this is expected behaviour, Is there a way for singlestep to be re-asserted from the second thread? I am attaching a tar file which has two simple utrace modules which can depict the problem. Please see run.sh for steps to see the problem that I am asking about. Also please refer my mail to utrace-devel here. https://www.redhat.com/archives/utrace-devel/2009-March/msg6.html Then I had reported that on resume, I have noticied that singlestep being ignored. -- Thanks and Regards Srikar trial.tgz Description: application/tar-gz
Re: gdbstub/uprobes problems: uprobe_unregister with halted target
* Jim Keniston jkeni...@us.ibm.com [2009-08-03 11:10:00]: So as per my analysis, gdb_utrace_report_signal was called, followed by uprobe_report_signal. Since gdb_utrace_report_signal requested for UTRACE_STOP as resume action for SIGTRAP, the thread got stopped. uprobes was waiting for either the singlestep to occur (or the process to exit/exec or some other event) before it could signal the process to be quiesced. Uprobes attempts to handle this situation. Before returning (UTRACE_SINGLESTEP | UTRACE_SIGNAL_IGN), uprobe_report_signal() registers to be notified of quiesce events. If report_signal for some other engine (e.g., gdbstub's) requests a UTRACE_STOP, that'll override uprobe_report_signal()'s UTRACE_SINGLESTEP. But uprobe_report_quiesce() should get called as a result and re-assert UTRACE_SINGLESTEP. Assuming gdbstub's report_quiesce callback eventually returns something other than UTRACE_STOP, the UTRACE_SINGLESTEP should take effect. That was my thinking, anyway. I can't guarantee that it actually works that way. If we refer to the discussion between you and Roland https://www.redhat.com/archives/utrace-devel/2008-July/msg00063.html I understand this as: If quiesce event is requested on a stopped thread, then report_quiesce (in this case uprobe_report_quiesce) will only be called when the thread starts to run but before it reaches user space. It also seems quiesce event on stopped threads is only useful, if one or more engines request a UTRACE_REPORT or UTRACE_INTERRUPT. However do correct me if I have misunderstood your discussion. Additionally please refer my mail to utrace-devel here. https://www.redhat.com/archives/utrace-devel/2009-March/msg6.html I had reported that on resume, I have noticied that singlestep being ignored. So even if the program was resumed, there are chances that singlestep will not occur, resulting in the program existing prematurely. -- Thanks and Regards Srikar
Re: gdbstub/uprobes problems: uprobe_unregister with halted target
The target process side is also hung: zsh D 0002 3568 1288 1259 0x0080 880078c57b98 0046 00011d4a 88006d4b8000 880078c57f50 7fff138b0858 88006d4b83b8 f968 88006d4b83b8 001d5740 Call Trace: [81097f6a] ? gdb_uprobe_handler+0x79/0xc2 [81097f6a] ? gdb_uprobe_handler+0x79/0xc2 [81097f6a] ? gdb_uprobe_handler+0x79/0xc2 [814225af] __mutex_lock_common+0x207/0x38a [81097f6a] ? gdb_uprobe_handler+0x79/0xc2 [814227f0] mutex_lock_nested+0x3c/0x41 [81097f6a] gdb_uprobe_handler+0x79/0xc2 [810c8d09] uprobe_report_signal+0x4e5/0x959 [81077e53] ? lock_release_holdtime+0x2c/0x11d [814239a0] ? _spin_unlock+0x2b/0x30 [81097293] utrace_get_signal+0x33d/0x5bd [81061304] ? get_signal_to_deliver+0x4c/0x3b6 [810613ae] get_signal_to_deliver+0xf6/0x3b6 [8102e1f2] ? kvm_clock_read+0x21/0x23 [81010ffa] do_notify_resume+0x89/0x746 [812088de] ? __up_read+0x76/0x7f [8142454a] ? paranoid_userspace+0x39/0x5a [8107963a] ? trace_hardirqs_on_caller+0x126/0x14a [8142455c] paranoid_userspace+0x4b/0x5a and the corresponding function call graph was: 3854 zsh(1350): uprobe_report_signal action=0x0 engine=0x88003ac36078 tsk=0x880037d0a470 regs=0x880059097f58 info 3867 zsh(1350): utrace_attach_pid pid=0x880078e8d680 flags=0x1 ops=0x81443be0 data=0x0 3881 zsh(1350): utrace_attach_task target=0x880037d0a470 flags=0x1 ops=0x81443be0 data=0x0 3890 zsh(1350):matching_engine utrace=0x880037d0aad8 flags=0x1 ops=0x81443be0 data=0x0 3901 zsh(1350):matching_engine return=0x880078d190f0 3907 zsh(1350): utrace_attach_task return=0x880078d190f0 3914 zsh(1350): put_task_struct t=0x880037d0a470 3918 zsh(1350): put_task_struct 3923 zsh(1350): utrace_attach_pid return=0x880078d190f0 I can't think of why utrace_attach_pid() would get called here. utrace_attach_pid is from xol_get_area(). So its clear that this was the first time uprobe_report_signal was called. Also the call to uretprobe_set_trampoline (below) confirms that this was the first time uprobe_report_signal was called. 3931 zsh(1350): uretprobe_set_trampoline uproc=0x880075bc77e0 tsk=0x880037d0a470 3947 zsh(1350): kzalloc).call size=0x40 flags=? 3955 zsh(1350): kzalloc).return return=0x88001ec27ee0 3986 zsh(1350): uretprobe_set_trampoline 3999 zsh(1350): clear_utrace_quiesce utask=0x880078f53290 resume=0x0 4007 zsh(1350): utask_adjust_flags utask=0x880078f53290 set=0x0 flags=0x1 4012 zsh(1350): utask_adjust_flags 4017 zsh(1350): clear_utrace_quiesce 4028 zsh(1350): uprobe_find_probept uproc=0x880075bc77e0 vaddr=0x419dd0 4034 zsh(1350): uprobe_find_probept return=0x8800377a4248 4041 zsh(1350): gdb_uprobe_handler up=0x8800220c1660 regs=0x880059097f58 4060 zsh(1350): gdb_uprobe_handler 4073 zsh(1350): utask_adjust_flags utask=0x880078f53290 set=0x1 flags=0x1 4080 zsh(1350): utrace_set_events_pid pid=0x880078e8d680 engine=0x88003ac36078 eventmask=0x131d 4088 zsh(1350):utrace_set_events target=0x880037d0a470 engine=0x88003ac36078 events=0x131d 4095 zsh(1350): get_utrace_lock target=0x880037d0a470 engine=0x88003ac36078 attached=0x1 4108 zsh(1350): get_utrace_lock return=0x880037d0aad8 4210 zsh(1350):utrace_set_events return=0x0 4215 zsh(1350): utrace_set_events_pid return=0x0 4220 zsh(1350): utask_adjust_flags 4227 zsh(1350): uprobe_put_process uproc=0x880075bc77e0 in_callback=0x1 4232 zsh(1350): uprobe_put_process return=0x0 4237 zsh(1350): uprobe_report_signal return=0x13 return action from uprobes is 0x13 which is UTRACE_SIGNAL_IGN | UTRACE_SINGLESTEP i.e ignore this signal because it was induced by uprobes and do a singlestep. 4242 zsh(1350): finish_callback utrace=0x880037d0aad8 report=0x880059097d98 engine=0x88003ac36078 ret=0x13 4248 zsh(1350): finish_callback return=0x0 4254 zsh(1350): finish_resume_report report=0x880059097d98 task=0x880037d0a470 utrace=0x880037d0aad8 4261 zsh(1350): utrace_reset task=0x880037d0a470 utrace=0x880037d0aad8 action=0x880059097d98 4268 zsh(1350): put_detached_list list=0x880059097cc8 4273 zsh(1350): put_detached_list 4278 zsh(1350): utrace_reset 4284 zsh(1350): utrace_stop task=0x880037d0a470 utrace=0x880037d0aad8 report=0x0 I'm confused here. Is the traced task getting hung in
Re: [RESEND] [PATCH 0/7] Ubp, Ssol and Uprobes
Hi Roland, et al, Did you get a chance to review this patchset? I was planning to post to LKML after addressing comments from you. -- Thanks and Regards Srikar Hi, This patchset implements uprobes over utrace. Please review the patchset and provide your valuable comments. These patches have been tested on the current utrace tree(commit id cf890ad46816982f3b8b5064d2f2bb91968ded43) This patchset requires Roland's utrace implementation + Jim and Masami's x86 instruction analysis layer. Patches 1 to 6 implement uprobes Patch 7 implements ftrace plugin Based on your feedback, I was looking at posting these patches to LKML some time next week. [PATCH 0/7] Ubp, Ssol and Uprobes [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP) [PATCH 2/7] x86 support for UBP [PATCH 3/7] Execution out of line (XOL) [PATCH 4/7] Uprobes Implementation [PATCH 5/7] x86 support for Uprobes [PATCH 6/7] Uprobes documentation. [PATCH 7/7] Ftrace plugin for Uprobes. -- Thanks and Regards Srikar
Re: linux kernel gdb stub for userspace processes, prototype version 3
Hi Frank, Roland
Using UTRACE_STOP as action in report_signal and report_quiesce results
in utrace_stop() being called which causes the thread to be scheduled
out. This results in gdb not getting control/data from the remote and
results in gdb command prompt.
From looking at kgdb-stub, I feel it might be better for
report_signal() to wait on gdb stub for inputs from gdb client.
This is similar to what kgdb stub does currently.
Also when gdb wants control, (i.e pressing ^C in gdb to get gdb prompt)
stub seems to inject SIGTRAP, I think gdb stub should have used
utrace_control(UTRACE_STOP) instead of sending SIGTRAP.
Please let me know if I am missing something.
--
Thanks and Regards
Srikar
PS:
I am attaching the gdb screen and dmesg output.
Please note the sections under NOTE
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-unknown-linux-gnu...
(gdb) target remote /proc/4870/gdb
Remote debugging using /proc/4870/gdb
Reading symbols from /lib64/libtermcap.so.2...done.
Loaded symbols for /lib64/libtermcap.so.2
Reading symbols from /lib64/libdl.so.2...Reading symbols from
/usr/lib/debug/lib64/libdl-2.5.so.debug...done.
done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libc.so.6...Reading symbols from
/usr/lib/debug/lib64/libc-2.5.so.debug...done.
done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from
/usr/lib/debug/lib64/ld-2.5.so.debug...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...Reading symbols from
/usr/lib/debug/lib64/libnss_files-2.5.so.debug...done.
done.
Loaded symbols for /lib64/libnss_files.so.2
0x003b4aec5620 in __read_nocancel () from /lib64/libc.so.6
(gdb) c[Ksource .gdbinit_bash
(gdb) c
Continuing.
Sending packet: $Z0,3b4aa0d9f0,1#01...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m3b4aa0d9f0,1#b8...Ack
Packet received: F3
Sending packet: $X3b4aa0d9f0,0:#dc...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M3b4aa0d9f0,1:cc#98...Ack
Packet received: OK
Sending packet: $vCont?#49...Ack
Packet received:
Packet vCont (verbose-resume) is NOT supported
Sending packet: $Hc0#db...Ack
Packet received:
Sending packet: $c#63...Ack
Packet received: S11
Sending packet: $g#67...Ack
Packet received:
40558F6DFF7F70568F6DFF7F110038558F6DFF7FC0B4A400080046020100D0B3A30080604300460233002B000
E00
Program received signal SIGSTOP, Stopped (signal).
###
NOTE:
Here gdb client was actually trying to get more data from server stub.
However utrace_stop() was called from server stub, resulting in the
thread being scheduled out. Ideally stub has sent a S packet to gdb
client. Stub should wait for comments from gdb client and report
accordingly. When the client finally says detach, continue or single
step, then report_signal() should sent the response accordingly.
(which would be UTRACE_RESUME/_SINGLESTEP but probably not UTRACE_STOP
##
Sending packet: $M3b4aa0d9f0,1:f3#6b...Ack
Packet received: OK
sigchld_handler (sig=17) at jobs.c:2937
2937{
(gdb) c
Continuing.
##
NOTE:
Here again client is not sending us continue or step/detach packets to
stub/server. This is because client is in STOPPED state and not ready to
accept packets. Hence it directly asks the process to be continued..
which shouldnt be the case in a remote debugging.
##
[RESEND] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
User space breakpointing infrastructure(UBP) User space breakpointing Infrastructure provides kernel subsystems with architecture independent interface to establish breakpoints in user applications. This patch provides core implementation of ubp and also wrappers for architecture dependent methods. UBP currently supports both single stepping inline and execution out of line strategies. Two different probepoints in the same process can have two different strategies. You need to follow this up with the UBP patch for your architecture. Signed-off-by: Jim Keniston jkeni...@us.ibm.com Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com --- arch/Kconfig| 12 + include/linux/ubp.h | 282 ++ kernel/Makefile |1 kernel/ubp_core.c | 479 4 files changed, 774 insertions(+) Index: uprobes.git/arch/Kconfig === --- uprobes.git.orig/arch/Kconfig +++ uprobes.git/arch/Kconfig @@ -44,6 +44,15 @@ config KPROBES for kernel debugging, non-intrusive instrumentation and testing. If in doubt, say N. +config UBP + bool User-space breakpoint assistance (EXPERIMENTAL) + depends on MODULES + depends on HAVE_UBP + help + Ubp enables kernel subsystems to establish breakpoints + in user applications. This service is used by components + such as uprobes. If in doubt, say N. + config HAVE_EFFICIENT_UNALIGNED_ACCESS bool help @@ -70,6 +79,9 @@ config KRETPROBES def_bool y depends on KPROBES HAVE_KRETPROBES +config HAVE_UBP + def_bool n + config HAVE_IOREMAP_PROT bool Index: uprobes.git/include/linux/ubp.h === --- /dev/null +++ uprobes.git/include/linux/ubp.h @@ -0,0 +1,282 @@ +#ifndef _LINUX_UBP_H +#define _LINUX_UBP_H +/* + * User-space BreakPoint support (ubp) + * include/linux/ubp.h + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + * Copyright (C) IBM Corporation, 2008, 2009 + */ + +#include asm/ubp.h +struct task_struct; +struct pt_regs; + +/** + * Strategy hints: + * + * %UBP_HNT_INLINE: Specifies that the instruction must + * be single-stepped inline. Can be set by the caller of + * @arch-analyze_insn() -- e.g., if caller is out of XOL slots -- + * or by @arch-analyze_insn() if there's no viable XOL strategy + * for that instruction. Set in arch-strategies if the architecture + * doesn't implement XOL. + * + * %UBP_HNT_PERMSL: Specifies that the instruction slot whose + * address is @ubp-xol_vaddr is assigned to @ubp for the life of + * the process. Can be used by @arch-analyze_insn() to simplify + * XOL in some cases. Ignored in @arch-strategies. + * + * %UBP_HNT_TSKINFO: Set in @arch-strategies if the architecture's + * XOL handling requires the preservation of special + * task-specific info between the calls to @arch-pre_xol() + * and @arch-post_xol(). (E.g., XOL of x86_64 rip-relative + * instructions uses a scratch register, whose value is saved + * by pre_xol() and restored by post_xol().) The caller + * of @arch-analyze_insn() should set %UBP_HNT_TSKINFO in + * @ubp-strategy if it's set in @arch-strategies and the caller + * can maintain a @ubp_task_arch_info object for each probed task. + * @arch-analyze_insn() should leave this flag set in @ubp-strategy + * if it needs to use the per-task @ubp_task_arch_info object. + */ +#define UBP_HNT_INLINE 0x1 /* Single-step this insn inline. */ +#define UBP_HNT_TSKINFO 0x2 /* XOL requires ubp_task_arch_info */ +#define UBP_HNT_PERMSL 0x4 /* XOL slot assignment is permanent */ + +#define UBP_HNT_MASK 0x7 + +/** + * struct ubp_bkpt - user-space breakpoint/probepoint + * + * @vaddr: virtual address of probepoint + * @xol_vaddr: virtual address of XOL slot assigned to this probepoint + * @opcode:copy of opcode at @vaddr + * @insn: typically a copy of the instruction at @vaddr. More + * precisely, this is the instruction (stream) that will be + * executed in place of the original instruction. + * @strategy: hints about how this instruction will be executed + * @fixups:set of fixups to be executed by @arch-post_xol
[RESEND] [PATCH 2/7] x86 support for UBP
x86 support for user breakpoint Infrastructure
This patch provides x86 specific userspace breakpoint assistance
implementation details.
This patch requires x86: instruction decoder API patch.
http://lkml.org/lkml/2009/6/1/459
Signed-off-by: Jim Keniston jkeni...@us.ibm.com
---
arch/x86/Kconfig |1
arch/x86/include/asm/ubp.h | 40 +++
arch/x86/kernel/Makefile |2
arch/x86/kernel/ubp_x86.c | 571 +
4 files changed, 614 insertions(+)
Index: uprobes.git/arch/x86/Kconfig
===
--- uprobes.git.orig/arch/x86/Kconfig
+++ uprobes.git/arch/x86/Kconfig
@@ -46,6 +46,7 @@ config X86
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_LZMA
+ select HAVE_UBP
config ARCH_DEFCONFIG
string
Index: uprobes.git/arch/x86/include/asm/ubp.h
===
--- /dev/null
+++ uprobes.git/arch/x86/include/asm/ubp.h
@@ -0,0 +1,40 @@
+#ifndef _ASM_UBP_H
+#define _ASM_UBP_H
+/*
+ * User-space BreakPoint support (ubp) for x86
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) IBM Corporation, 2008, 2009
+ */
+
+typedef u8 ubp_opcode_t;
+#define MAX_UINSN_BYTES 16
+#define UBP_XOL_SLOT_BYTES (MAX_UINSN_BYTES)
+
+#ifdef CONFIG_X86_64
+struct ubp_bkpt_arch_info {
+ unsigned long rip_target_address;
+ u8 orig_insn[MAX_UINSN_BYTES];
+};
+struct ubp_task_arch_info {
+ unsigned long saved_scratch_register;
+};
+#else
+struct ubp_bkpt_arch_info {};
+struct ubp_task_arch_info {};
+#endif
+
+#endif /* _ASM_UBP_H */
Index: uprobes.git/arch/x86/kernel/Makefile
===
--- uprobes.git.orig/arch/x86/kernel/Makefile
+++ uprobes.git/arch/x86/kernel/Makefile
@@ -109,6 +109,8 @@ obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION)
obj-$(CONFIG_SWIOTLB) += pci-swiotlb.o
+obj-$(CONFIG_UBP) += ubp_x86.o
+
###
# 64 bit specific files
ifeq ($(CONFIG_X86_64),y)
Index: uprobes.git/arch/x86/kernel/ubp_x86.c
===
--- /dev/null
+++ uprobes.git/arch/x86/kernel/ubp_x86.c
@@ -0,0 +1,571 @@
+/*
+ * User-space BreakPoint support (ubp) for x86
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) IBM Corporation, 2008, 2009
+ */
+
+#define UBP_IMPLEMENTATION 1
+
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/ptrace.h
+#include linux/ubp.h
+#include asm/insn.h
+
+#ifdef CONFIG_X86_32
+#define is_32bit_app(tsk) 1
+#else
+#define is_32bit_app(tsk) (test_tsk_thread_flag(tsk, TIF_IA32))
+#endif
+
+#define UBP_FIX_RIP_AX 0x8000
+#define UBP_FIX_RIP_CX 0x4000
+
+static void set_ip(struct pt_regs *regs, unsigned long vaddr)
+{
+ regs-ip = vaddr;
+}
+
+#ifdef CONFIG_X86_64
+static bool is_riprel_insn(struct ubp_bkpt *ubp)
+{
+ return ((ubp-fixups (UBP_FIX_RIP_AX | UBP_FIX_RIP_CX)) != 0);
+}
+
+static void cancel_xol(struct task_struct *tsk, struct ubp_bkpt *ubp)
+{
+ if (is_riprel_insn(ubp)) {
+ /*
+* We rewrote ubp-insn to use indirect addressing rather
+* than rip-relative addressing for XOL. For
+* single-stepping inline, put back the original instruction.
+*/
+ memcpy(ubp-insn, ubp-arch_info.orig_insn, MAX_UINSN_BYTES);
+ ubp-strategy = ~UBP_HNT_TSKINFO;
+ }
+}
+#endif /* CONFIG_X86_64 */
+
+#define W(row, b0, b1, b2, b3, b4, b5, b6,
[RESEND] [PATCH 5/7] x86 support for Uprobes
x86 support for Uprobes Signed-off-by: Jim Keniston jkeni...@us.ibm.com --- arch/x86/Kconfig |1 + arch/x86/include/asm/uprobes.h | 27 +++ 2 files changed, 28 insertions(+) Index: uprobes.git/arch/x86/Kconfig === --- uprobes.git.orig/arch/x86/Kconfig +++ uprobes.git/arch/x86/Kconfig @@ -47,6 +47,7 @@ config X86 select HAVE_KERNEL_BZIP2 select HAVE_KERNEL_LZMA select HAVE_UBP + select HAVE_UPROBES config ARCH_DEFCONFIG string Index: uprobes.git/arch/x86/include/asm/uprobes.h === --- /dev/null +++ uprobes.git/arch/x86/include/asm/uprobes.h @@ -0,0 +1,27 @@ +#ifndef _ASM_UPROBES_H +#define _ASM_UPROBES_H +/* + * Userspace Probes (UProbes) + * uprobes.h + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + * Copyright (C) IBM Corporation, 2008, 2009 + */ +#include asm/signal.h + +#define BREAKPOINT_SIGNAL SIGTRAP +#define SSTEP_SIGNAL SIGTRAP +#endif /* _ASM_UPROBES_H */
[RESEND] [PATCH 6/7] Uprobes documentation.
on the architecture.
+
+Here are sample overhead figures (in usec) for x86 architecture.
+
+x86: Intel Pentium M, 1495 MHz, 2957.31 bogomips
+uprobe = 2.9 usec;
+
+9. TODO
+
+a. Support for other architectures.
+b. Support return probes.
+
+10. Uprobes Team
+
+The following people have made major contributions to Uprobes:
+Jim Keniston - jkeni...@us.ibm.com
+Srikar Dronamraju - sri...@linux.vnet.ibm.com
+Ananth Mavinakayanahalli - ana...@in.ibm.com
+Prasanna Panchamukhi - prasa...@in.ibm.com
+Dave Wilder - dwil...@us.ibm.com
+
+11. Uprobes Example
+
+Here's a sample kernel module showing the use of Uprobes to count the
+number of times an instruction at a particular address is executed,
+and optionally (unless verbose=0) report each time it's executed.
+- cut here -
+/* uprobe_example.c */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/uprobes.h
+
+/*
+ * Usage: insmod uprobe_example.ko pid=pid vaddr=address [verbose=0]
+ * where pid identifies the probed process and address is the virtual
+ * address of the probed instruction.
+ */
+
+static int pid = 0;
+module_param(pid, int, 0);
+MODULE_PARM_DESC(pid, pid);
+
+static int verbose = 1;
+module_param(verbose, int, 0);
+MODULE_PARM_DESC(verbose, verbose);
+
+static long vaddr = 0;
+module_param(vaddr, long, 0);
+MODULE_PARM_DESC(vaddr, vaddr);
+
+static int nhits;
+static struct uprobe usp;
+
+static void uprobe_handler(struct uprobe *u, struct pt_regs *regs)
+{
+ nhits++;
+ if (verbose)
+ printk(KERN_INFO Hit #%d on probepoint at %#lx\n,
+ nhits, u-vaddr);
+}
+
+int __init init_module(void)
+{
+ int ret;
+ usp.pid = pid;
+ usp.vaddr = vaddr;
+ usp.handler = uprobe_handler;
+ printk(KERN_INFO Registering uprobe on pid %d, vaddr %#lx\n,
+ usp.pid, usp.vaddr);
+ ret = register_uprobe(usp);
+ if (ret != 0) {
+ printk(KERN_ERR register_uprobe() failed, returned %d\n, ret);
+ return ret;
+ }
+ return 0;
+}
+
+void __exit cleanup_module(void)
+{
+ printk(KERN_INFO Unregistering uprobe on pid %d, vaddr %#lx\n,
+ usp.pid, usp.vaddr);
+ printk(KERN_INFO Probepoint was hit %d times\n, nhits);
+ unregister_uprobe(usp);
+}
+MODULE_LICENSE(GPL);
+- cut here -
+
+You can build the kernel module, uprobe_example.ko, using the following
+Makefile:
+- cut here -
+obj-m := uprobe_example.o
+KDIR := /lib/modules/$(shell uname -r)/build
+PWD := $(shell pwd)
+default:
+ $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
+clean:
+ rm -f *.mod.c *.ko *.o .*.cmd
+ rm -rf .tmp_versions
+- cut here -
+
+For example, if you want to run myprog and monitor its calls to myfunc(),
+you can do the following:
+
+$ make // Build the uprobe_example module.
+...
+$ nm -p myprog | awk '$3==myfunc'
+080484a8 T myfunc
+$ ./myprog
+$ ps
+ PID TTY TIME CMD
+ 4367 pts/300:00:00 bash
+ 8156 pts/300:00:00 myprog
+ 8157 pts/300:00:00 ps
+$ su -
+...
+# insmod uprobe_example.ko pid=8156 vaddr=0x080484a8
+
+In /var/log/messages and on the console, you will see a message of the
+form kernel: Hit #1 on probepoint at 0x80484a8 each time myfunc()
+is called. To turn off probing, remove the module:
+
+# rmmod uprobe_example
+
+In /var/log/messages and on the console, you will see a message of the
+form Probepoint was hit 5 times.
[RESEND] [PATCH 7/7] Ftrace plugin for Uprobes.
Ftrace Plugin for uprobes This patch implements ftrace plugin for uprobes. Description: Ftrace plugin provides an interface to dump data at a given address, top of the stack and function arguments when a user program calls a specific function. To dump the data at a given address issue echo up pid address to probe D data address size /sys/kernel/tracing/uprobes_events To dump the data from top of stack issue echo up pid address to probe S size /sys/kernel/tracing/uprobes_events To dump the function arguments issue echo up pid address to probe A num-args /sys/kernel/tracing/uprobes_events D = Dump the data at a given address. S = Dump the data from top of stack. A = Dump probed function arguments. Supported only for x86_64 arch. For example: Input: $ echo up 6424 0x4004d8 S 100 /sys/kernel/debug/tracing/uprobe_events $ echo up 6424 0x4004d8 D 0x7fff6bf587d0 35 /sys/kernel/debug/tracing/uprobe_events $ echo up 6424 0x4004d8 A 5 /sys/kernel/debug/tracing/uprobe_events $ cat /sys/kernel/debug/tracing/uprobe_events up 6424 0x4004d8 S 100 up 6424 0x4004d8 D 7fff6bf587d0 35 up 6424 0x4004d8 A 5 Output: $ cat trace # tracer: nop # # TASK-PIDCPU#TIMESTAMP FUNCTION # | | | | | ...-6424 [004] 1156.853343: : 0x4004d8: S 0x7fff6bf587a8: 31 06 40 00 00 00 00 00 1...@. ...-6424 [004] 1156.853348: : 0x4004d8: S 0x7fff6bf587b0: 00 00 00 00 00 00 00 00 ...-6424 [004] 1156.853350: : 0x4004d8: S 0x7fff6bf587b8: c0 bb c1 4a 3b 00 00 00 ...J;... ...-6424 [004] 1156.853352: : 0x4004d8: S 0x7fff6bf587c0: 50 06 40 00 c8 00 00 00 p...@. ...-6424 [004] 1156.853353: : 0x4004d8: S 0x7fff6bf587c8: ed 00 00 ff 00 00 00 00 ...-6424 [004] 1156.853355: : 0x4004d8: S 0x7fff6bf587d0: 54 68 69 73 20 73 74 72 This str ...-6424 [004] 1156.853357: : 0x4004d8: S 0x7fff6bf587d8: 69 6e 67 20 69 73 20 6f ing is o ...-6424 [004] 1156.853359: : 0x4004d8: S 0x7fff6bf587e0: 6e 20 74 68 65 20 73 74 n the st ...-6424 [004] 1156.853361: : 0x4004d8: S 0x7fff6bf587e8: 61 63 6b 20 69 6e 20 6d ack in m ...-6424 [004] 1156.853363: : 0x4004d8: S 0x7fff6bf587f0: 61 69 6e 00 00 00 00 00 ain. ...-6424 [004] 1156.853364: : 0x4004d8: S 0x7fff6bf587f8: 00 00 00 00 04 00 00 00 ...-6424 [004] 1156.853366: : 0x4004d8: S 0x7fff6bf58800: ff ff ff ff ff ff ff ff ...-6424 [004] 1156.853367: : 0x4004d8: S 0x7fff6bf58808: 00 00 00 00 ...-6424 [004] 1156.853388: : 0x4004d8: D 0x7fff6bf587d0: 54 68 69 73 20 73 74 72 This str ...-6424 [004] 1156.853389: : 0x4004d8: D 0x7fff6bf587d8: 69 6e 67 20 69 73 20 6f ing is o ...-6424 [004] 1156.853391: : 0x4004d8: D 0x7fff6bf587e0: 6e 20 74 68 65 20 73 74 n the st ...-6424 [004] 1156.853393: : 0x4004d8: D 0x7fff6bf587e8: 61 63 6b 20 69 6e 20 6d ack in m ...-6424 [004] 1156.853394: : 0x4004d8: D 0x7fff6bf587f0: 61 69 6e ain ...-6424 [004] 1156.853398: : 0x4004d8: A ARG 1: 0004 ...-6424 [004] 1156.853399: : 0x4004d8: A ARG 2: 00c8 ...-6424 [004] 1156.853400: : 0x4004d8: A ARG 3: ffed ...-6424 [004] 1156.853401: : 0x4004d8: A ARG 4: ...-6424 [004] 1156.853402: : 0x4004d8: A ARG 5: 0048 TODO: - use ringbuffer - Allow user to specify Nick Name for probe addresses. - Dump arguments from floating point registers. - Optimize code to use single probe instead of multiple probes for same probe addresses. -- Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com Signed-off-by: Srikar Dronamraju sri...@linux.vnet.ibm.com --- Documentation/trace/uprobes_trace.txt | 197 kernel/trace/Makefile |1 kernel/trace/trace_uprobes.c | 537 ++ 3 files changed, 735 insertions(+) Index: uprobes.git/kernel/trace/Makefile === --- uprobes.git.orig/kernel/trace/Makefile +++ uprobes.git/kernel/trace/Makefile @@ -46,5 +46,6 @@ obj-$(CONFIG_EVENT_TRACER) += trace_expo obj-$(CONFIG_FTRACE_SYSCALLS) += trace_syscalls.o obj-$(CONFIG_EVENT_PROFILE) += trace_event_profile.o obj-$(CONFIG_EVENT_TRACER) += trace_events_filter.o +obj-$(CONFIG_UPROBES) += trace_uprobes.o libftrace-y := ftrace.o Index: uprobes.git/kernel/trace/trace_uprobes.c === --- /dev/null +++ uprobes.git/kernel/trace/trace_uprobes.c @@ -0,0 +1,537 @@ +/* + * Ftrace plugin for Userspace Probes (UProbes) + * kernel/trace/trace_uprobes.c + * + * This program is free software; you can redistribute it and/or modify + * it under
Re: Utrace in -next tree?
* Roland McGrath rol...@redhat.com [2008-10-17 13:09:34]: What are your thoughts of getting utrace git tree into linux-next? That way, utrace will have more extensive visibility and testing. I would certainly like to. I hope that after I next post the latest utrace patch series for more review, it will make sense to put it into linux-next. Roland, How about now getting utrace git tree into linux-next? -- Thanks and Regards Srikar
Re: abt froggy
Hi Chris, Thanks for your quick reply. I have been regularly updating from cvs. So I thought I was always on the latest copy. To confirm I checked out a new copy using cvs -z9 -d :ext:[EMAIL PROTECTED]:/cvs/systemtap co froggy and compared it the copy I update regularly and they seem to be identical. The printf()s in froggy.c:resp_listener() are all temporary diagnostics and will ultimately be removed. I don't know which version of froggy you have, but if you'll look at the latest under the RESP_SYSCALL_ENTRY case you'll see: if (froggy-syscall_fcn) (*froggy-syscall_fcn)(resp.resp_syscall.nr, (pid_t)resp.resp_syscall.pid, regs); I see this: if (froggy-syscall_fcn) (*froggy-syscall_fcn)(resp.resp_syscall.nr, (pid_t)resp.resp_syscall.pid, resp.resp_syscall.args, regs); } In froogy/module/control.c do_process_attach_task() and do_process_attach share lot of code and we could probably use common function for the shared code. do_process_attach_task() has been removed. Originally, I had it set up such that client-thread report_clone wasa used to automatically attach I am not sure what you mean by removed. grep -n do_process_attach_task froggy/froggy/module/control.c shows 65:do_process_attach_task (struct utrace_attached_engine * engine, child processes that were ultimately to be execve()ed as code to be debugged, but I've replaced that with something more explicitly like ptrace(PTRACE_TRACEME,...) and the older code has been #ifdef-ed out. (I'll remove it entirely when I'm sure I don't need it anymore...) Similarly do_shutdown() shares code with do_process_detach and we could probably make do_shutdown() call do_process_detach. It sounds like you don't have the latest snapshot--I did a /lot/ of cleanup in the shutdown/detach code last week and fcns you mention split the work up differently now. I am not sure if we are looking at the version with different viewpoints or we are looking at different version of sources. Do we plan to use report_jctl in the near future. utrace_ops has report_jctl set to NULL however we have defined report_jctl() function which never gets used. Similarly for unsafe_exec and tracer_task. All the report_* callbacks will ultimately be returned to the client for handling as described above--keep in mind froggy is still in its early stages and there's a lot more that's yet to be done. Do you have a document that talks of the features and stuff that you intend to provide other than the README which talks of froggy being a sandbox for utrace. (I haven't read the documents that were updated today. Sorry if its covered in those docs.) Can you explain why you would want to attach with UTRACE_ATTACH_EXCLUSIVE always? So even if I want to trace the same program twice from froggy then I shouldn't be able to do it? To be honest, I had no good reason for using UTRACE_ATTACH_EXCLUSIVE and can certainly experiment with removing it. Ok.
