Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On Mon, Jan 18, 2010 at 02:15:51PM +0100, Peter Zijlstra wrote: On Mon, 2010-01-18 at 14:37 +0200, Avi Kivity wrote: On 01/18/2010 02:14 PM, Peter Zijlstra wrote: Well, the alternatives are very unappealing. Emulation and single-stepping are going to be very slow compared to a couple of jumps. With CPL2 or RPL on user segments the protection issue seems to be manageable for running the instructions from kernel space. CPL2 gives unrestricted access to the kernel address space; and RPL does not affect page level protection. Segment limits don't work on x86-64. But perhaps I missed something - these things are tricky. So setting RPL to 3 on the user segments allows access to kernel pages just fine? How useful.. :/ It should be possible to translate the instruction into an address space check, followed by the action, but that's still slower due to privilege level switches. Well, if you manage to do the address validation you don't need the priv level switch anymore, right? Are the ins encodings sane enough to recognize mem parameters without needing to know the actual ins? How about using a hw-breakpoint to close the gap for the inline single step? You could even re-insert the int3 lazily when you need the hw-breakpoint again. It would consume one hw-breakpoint register for each task/cpu that has probes though.. A very scarce resource that it is, well, sometimes all that we might have is just one hw-breakpoint register (like older PPC64 with 1 IABR) in the system. If one process/thread consumes it, then all other contenders (from both kernel and user-space) are prevented from acquiring it. Also to mention the existence of processors with no support for instruction breakpoints. Thanks, K.Prasad
Re: x86: do_debug PTRACE_SINGLESTEP broken by 08d68323d1f0c34452e614263b212ca556dae47f
On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote: Hi. do_debug() is obviously wrong wrt PTRACE_SINGLESTEP/TIF_SINGLESTEP, no? Afaics this was broken by hw-breakpoints: modifying generic debug exception to use thread-specific debug registers commit 08d68323d1f0c34452e614263b212ca556dae47f To verify, the patch below fixes the stepping for me, not sure what is the proper fix... Oleg. --- arch/x86/kernel/traps.c~ 2009-12-18 00:20:49.0 +0100 +++ arch/x86/kernel/traps.c 2009-12-18 01:44:05.0 +0100 @@ -575,7 +575,7 @@ dotraplinkage void __kprobes do_debug(st regs-flags = ~X86_EFLAGS_TF; } si_code = get_si_code(tsk-thread.debugreg6); - if (tsk-thread.debugreg6 (DR_STEP | DR_TRAP_BITS)) +// if (tsk-thread.debugreg6 (DR_STEP | DR_TRAP_BITS)) send_sigtrap(tsk, regs, error_code, si_code); preempt_conditional_cli(regs); The cause for such a behaviour isn't apparent to me and like others, I'm unable to recreate it (Single-stepping using gdb over a tiny program running on x86, latest -tip works fine). Did you try to narrow down the causative piece of code, among the several hooks in do_debug()? A separate 'dr6' and 'thread.debugreg6' was desired by the community (refer: pine.lnx.4.44l0.0904011216460.3736-100...@iolanthe.rowland.org and pine.lnx.4.44l0.0904091634150.4094-100...@iolanthe.rowland.org) then. 'dr6' and 'thread.deebugreg6' would contain the value of the DR6 status register and every exception handler would reset the bits in them corresponding to which action has been taken. The difference in them being that 'thread.debugreg6' would be eventually processed by code interested in user-space while 'dr6' was restricted to those hooks in do_debug(). Thanks, K.Prasad
Re: x86: do_debug PTRACE_SINGLESTEP broken by 08d68323d1f0c34452e614263b212ca556dae47f
On Fri, Dec 18, 2009 at 06:27:47PM +0100, Oleg Nesterov wrote:
On 12/18, Frederic Weisbecker wrote:
On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
Hi.
snipped
Single stepping works well for me, after a quick check on
gdb. How did you trigger the bug?
Please find the trivial test-case below. It hangs, because
PTRACE_SINGLESTEP doesn't trigger the trap.
aah...my other mail just criss-crossed yours.
I quickly ran on the said x86 box, loaded with -tip (commit
7818b3d0fc68f5c2a85fed86d9fa37131c5a3068) and it runs fine.
[r...@llm05 prasadkr]# cat oleg.c
#include stdio.h
#include unistd.h
#include signal.h
#include sys/ptrace.h
#include sys/wait.h
#include assert.h
int main(void)
{
int pid, status, i;
pid = fork();
if (!pid)
for (;;);
sleep(1);
assert(ptrace(PTRACE_ATTACH, pid, 0,0) == 0);
assert(pid == wait(status));
assert(WIFSTOPPED(status));
for (i = 0; i 10; ++i) {
assert(ptrace(PTRACE_SINGLESTEP, pid, 0,0) == 0);
printf(wait %d ...\n, i);
assert(pid == wait(status));
assert(WIFSTOPPED(status) WSTOPSIG(status) == SIGTRAP);
}
kill(pid, SIGKILL);
return 0;
}
[r...@llm05 prasadkr]# gcc -o oleg oleg.c -g -Wall
[r...@llm05 prasadkr]# ./oleg
wait 0 ...
wait 1 ...
wait 2 ...
wait 3 ...
wait 4 ...
wait 5 ...
wait 6 ...
wait 7 ...
wait 8 ...
wait 9 ...
[r...@llm05 prasadkr]#
Am I missing something here?
Thanks,
K.Prasad
Re: Tests Failures on PPC64
On Fri, Dec 11, 2009 at 04:59:44PM +0100, Oleg Nesterov wrote: On 12/11, K.Prasad wrote: Watchpoints (using DABR) through GDB can fail for many reasonsthey must ideally be set after the program has started execution - to enable GDB know the size of the variable...else they would resort to single-stepping to trap access to the target variable. Yes. I straced gdb to be sure it really does PTRACE_SET_DEBUGREF to use the hardware watchpoint. There is something strange though. gdb does PTRACE_SINGLESTEP and only then PTRACE_CONT after watch xxx. I haven't taken a good look at the testcase...although I suspect that the use of PTRACE_SINGLESTEP vs PTRACE_SET_DEBUGREG during your trials is due to the way watch var is being set. For instance, here are two screenlogs taken from a PPC64 (Power5 box running RHEL 5.3 2.6.18-128.el5). It can be seen that hw-breakpoints are used only during the second-run of GDB vs single-stepping done in the first...wondering if you used it in similar ways. First run --- [r...@p510 ~]# gdb prasad GNU gdb Fedora (6.8-27.el5) 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 ppc64-redhat-linux-gnu... (gdb) watch b Watchpoint 1: b (Watchpoint vs Hardware watchpoint) (gdb) r Starting program: /root/prasad Prasad: sizeof(long): sizeof(b)=4 Watchpoint 1: b Old value = 0 New value = 200 main () at a.c:17 17 i = 300; (gdb) c Second run --- [r...@p510 ~]# gdb prasad GNU gdb Fedora (6.8-27.el5) 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 ppc64-redhat-linux-gnu... (gdb) start Breakpoint 1 at 0x14bc: file a.c, line 14. Starting program: /root/prasad main () at a.c:14 14 printf(\nPrasad: sizeof(long): sizeof(b)=%d\n, sizeof(b)); (gdb) watch b Hardware watchpoint 2: b --(uses DABR unlike the firstrun) (gdb) q The program is running. Exit anyway? (y or n) y
Re: Tests Failures on PPC64
On Thu, Dec 10, 2009 at 08:24:36PM +0100, Oleg Nesterov wrote: On 12/09, CAI Qian wrote: - Oleg Nesterov o...@redhat.com wrote: Thanks, but it doesn't fail for me on this machine... Hmm, it failed for me. # cd /root/ptrace-tests # make check ... FAIL: watchpoint OMG. Yet another test-case fails on powerpc I didn't see this failure in the previous reports or missed it ... I bet it fails without utrace too? (please don't tell it doesn't ;) Did you see it fails on other ppc64 machines? Oh well. I spent this day grepping arch/powerpc to understand how PTRACE_SET_DEBUGREG works and what is the problem. But I am afraid this time I need a help from someone who understands the hardware magic on powerpc. There's relatively less magic with PPC64 (with just one DABR) compared to x86 :-) I hope to offer a little help here (given that I work to tweak ptrace_set_debugreg() in PPC64 to use the hw-breakpoint interfaces) Watchpoints (using DABR) through GDB can fail for many reasonsthey must ideally be set after the program has started execution - to enable GDB know the size of the variable...else they would resort to single-stepping to trap access to the target variable. Cai, Where can one find the relevant piece of testcase? Thanks, K.Prasad
Re: The demise of utracer.
On Tue, Jul 01, 2008 at 03:28:04PM -0400, Chris Moller wrote: K.Prasad wrote: Hi All, Sorry if I have missed out something I need to know before I respond to this email. But the trace infrastructure (lib/trace.c) already provides such a facility which more features such as per-cpu buffer for faster transmission (it is a wrapper over relay which sits on top of debugfs). The interfaces provided by trace are much simpler/functional than setting up a debugfs interface manually (see samples/trace/fork_trace.c) and the directory structure and control files setup by trace are already familiar to the systemtap code. Thanks, K.Prasad P.S.: trace is currently in -mm tree. Thought it might be interesting to check this out--the patched 2.6.26-rc5 kernel built fine but panicked when I tried to boot it. So You might want to directly try out 2.6.26-rc5-mm1 directly. It boots fine on my T60p with default configs. Thanks, K.Prasad
