Re: [RFC,PATCH 0/14] utrace/ptrace
On Tue, Nov 24, 2009 at 09:01:27PM +0100, Oleg Nesterov wrote:
Hello.
This is the new iteration of Roland's utrace patch, this time
with rewrite-ptrace-via-utrace + cleanups in utrace core.
1-7 are already in -mm tree, I am sending them to simplify the
review.
8-12 don not change the behaviour, simple preparations.
13-14 add utrace-ptrace and utrace
Oleg,
I ran the ptrace-tests testsuite [1] on powerpc on the vanilla ptrace
and then with ptrace/utrace. The results for ptrace/utrace look better
:-)
All tests are 'make check xcheck'.
Ananth
[1]
cvs -d :pserver:anoncvs:anon...@sources.redhat.com:/cvs/systemtap co ptrace-tests
-
Vanilla ptrace:
PASS: ptrace-on-job-control-stopped
PASS: attach-wait-on-stopped
PASS: detach-can-signal
PASS: attach-into-signal
PASS: attach-sigcont-wait
PASS: sa-resethand-on-cont-signal
PASS: ptrace_cont-defeats-sigblock
PASS: ptrace-cont-sigstop-detach
PASS: ptrace_event_clone
PASS: tif-syscall-trace-after-detach
PASS: event-exit-proc-maps
PASS: event-exit-proc-environ
SKIP: x86_64-ia32-gs
SKIP: x86_64-gsbase
PASS: powerpc-altivec
PASS: peekpokeusr
PASS: watchpoint
PASS: block-step
PASS: step-jump-cont
SKIP: step-jump-cont-strict
PASS: ppc-dabr-race
PASS: signal-loss
PASS: step-into-handler
SKIP: user-area-access
PASS: user-regs-peekpoke
PASS: erestartsys
SKIP: erestart-debugger
SKIP: step-to-breakpoint
errno 14 (Bad address)
syscall-reset: syscall-reset.c:95: main: Assertion `(*__errno_location ()) ==
38' failed.
unexpected child status 67f
FAIL: syscall-reset
PASS: reparent-zombie
PASS: step-simple
SKIP: step-through-sigret
PASS: stop-attach-then-wait
FAIL: detach-stopped
PASS: detach-stopped-rhel5
PASS: clone-multi-ptrace
PASS: clone-ptrace
PASS: o_tracevfork
PASS: o_tracevforkdone
PASS: detach-parting-signal
PASS: detach-sigkill-race
PASS: waitpid-double-report
PASS: o_tracevfork-parent
PASS: stopped-detach-sleeping
FAIL: stopped-attach-transparency
SKIP: erestartsys-trap
SKIP: highmem-debugger
PASS: sigint-before-syscall-exit
SKIP: syscall-from-clone
step-from-clone: step-from-clone.c:195: main: Assertion `(status 8) == 5'
failed.
step-from-clone: step-from-clone.c:119: handler_fail: Assertion `0' failed.
/bin/sh: line 5: 19825 Aborted ${dir}$tst
FAIL: step-from-clone
step-fork: step-fork.c:56: handler_fail: Assertion `0' failed.
/bin/sh: line 5: 19832 Aborted ${dir}$tst
FAIL: step-fork
5 of 41 tests failed
(10 tests were not run)
Please report to utrace-devel@redhat.com
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/home/ananth/ptrace-tests/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/home/ananth/ptrace-tests/tests'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/ananth/ptrace-tests/tests'
make: *** [check-recursive] Error 1
-
ptrace over utrace:
PASS: ptrace-on-job-control-stopped
PASS: attach-wait-on-stopped
PASS: detach-can-signal
PASS: attach-into-signal
PASS: attach-sigcont-wait
PASS: sa-resethand-on-cont-signal
PASS: ptrace_cont-defeats-sigblock
PASS: ptrace-cont-sigstop-detach
PASS: ptrace_event_clone
PASS: tif-syscall-trace-after-detach
PASS: event-exit-proc-maps
PASS: event-exit-proc-environ
SKIP: x86_64-ia32-gs
SKIP: x86_64-gsbase
PASS: powerpc-altivec
PASS: peekpokeusr
PASS: watchpoint
PASS: block-step
PASS: step-jump-cont
SKIP: step-jump-cont-strict
PASS: ppc-dabr-race
PASS: signal-loss
PASS: step-into-handler
SKIP: user-area-access
PASS: user-regs-peekpoke
PASS: erestartsys
SKIP: erestart-debugger
SKIP: step-to-breakpoint
errno 14 (Bad address)
syscall-reset: syscall-reset.c:95: main: Assertion `(*__errno_location ()) ==
38' failed.
unexpected child status 67f
FAIL: syscall-reset
PASS: reparent-zombie
PASS: step-simple
SKIP: step-through-sigret
PASS: stop-attach-then-wait
PASS: detach-stopped
PASS: detach-stopped-rhel5
PASS: clone-multi-ptrace
PASS: clone-ptrace
PASS: o_tracevfork
PASS: o_tracevforkdone
PASS: detach-parting-signal
PASS: detach-sigkill-race
PASS: waitpid-double-report
PASS: o_tracevfork-parent
PASS: stopped-detach-sleeping
PASS: stopped-attach-transparency
SKIP: erestartsys-trap
SKIP: highmem-debugger
PASS: sigint-before-syscall-exit
SKIP: syscall-from-clone
SKIP: step-from-clone
step-fork: step-fork.c:56: handler_fail: Assertion `0' failed.
/bin/sh: line 5: 24803 Aborted ${dir}$tst
FAIL: step-fork
2 of 40 tests failed
(11 tests were not run)
Please report to utrace-devel@redhat.com
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/home/ananth/ptrace-tests/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/home/ananth/ptrace-tests/tests'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/ananth/ptrace-tests/tests'
make: *** [check-recursive] Error 1
GDB Testsuite Results with CONFIG_UTRACE i686
Hello! Those are the test results on i686 F12 hosts with and without CONFIG_UTRACE. Interesting thing is that the results on quite different on two Intel hosts. gdb.sum is from without CONFIG_UTRACE. Thanks! CAI Qian ProLiant DL360 G4p (Intel) diff -u gdb.sum gdb-utrace.sum --- gdb.sum 2009-11-25 16:11:35.0 +0800 +++ gdb-utrace.sum 2009-11-25 16:10:45.0 +0800 @@ -1,4 +1,4 @@ -Test Run By root on Tue Nov 24 23:58:53 2009 +Test Run By root on Tue Nov 24 23:26:57 2009 Native configuration is i686-pc-linux-gnu === gdb tests === @@ -748,8 +748,8 @@ PASS: gdb.base/bigcore.exp: tbreak 269 PASS: gdb.base/bigcore.exp: continue PASS: gdb.base/bigcore.exp: next -PASS: gdb.base/bigcore.exp: extract next heap (stop at 50) -PASS: gdb.base/bigcore.exp: extract prev heap (stop at 50) +PASS: gdb.base/bigcore.exp: extract next heap +PASS: gdb.base/bigcore.exp: extract prev heap PASS: gdb.base/bigcore.exp: save heap size PASS: gdb.base/bigcore.exp: grab pid PASS: gdb.base/bigcore.exp: signal SIGABRT @@ -3718,7 +3718,7 @@ PASS: gdb.base/foll-fork.exp: set follow parent, cleanup Running ./gdb.base/follow-child.exp ... PASS: gdb.base/follow-child.exp: set follow-fork-mode child -PASS: gdb.base/follow-child.exp: break +FAIL: gdb.base/follow-child.exp: break Running ./gdb.base/foll-vfork.exp ... PASS: gdb.base/foll-vfork.exp: set verbose PASS: gdb.base/foll-vfork.exp: insert first vfork catchpoint @@ -13850,18 +13850,18 @@ PASS: gdb.pie/break.exp: breakpoint at start of multi line if conditional PASS: gdb.pie/break.exp: breakpoint at start of multi line while conditional PASS: gdb.pie/break.exp: breakpoint info -PASS: gdb.pie/break.exp: run until function breakpoint -PASS: gdb.pie/break.exp: run until breakpoint set at a line number -PASS: gdb.pie/break.exp: run until file:function(6) breakpoint -PASS: gdb.pie/break.exp: run until file:function(5) breakpoint -PASS: gdb.pie/break.exp: run until file:function(4) breakpoint -PASS: gdb.pie/break.exp: run until file:function(3) breakpoint -PASS: gdb.pie/break.exp: run until file:function(2) breakpoint -PASS: gdb.pie/break.exp: run until file:function(1) breakpoint -PASS: gdb.pie/break.exp: run until quoted breakpoint -PASS: gdb.pie/break.exp: run until file:linenum breakpoint +FAIL: gdb.pie/break.exp: run until function breakpoint +FAIL: gdb.pie/break.exp: run until breakpoint set at a line number +FAIL: gdb.pie/break.exp: run until file:function(6) breakpoint +FAIL: gdb.pie/break.exp: run until file:function(5) breakpoint +FAIL: gdb.pie/break.exp: run until file:function(4) breakpoint +FAIL: gdb.pie/break.exp: run until file:function(3) breakpoint +FAIL: gdb.pie/break.exp: run until file:function(2) breakpoint +FAIL: gdb.pie/break.exp: run until file:function(1) breakpoint +FAIL: gdb.pie/break.exp: run until quoted breakpoint +FAIL: gdb.pie/break.exp: run until file:linenum breakpoint (the program is no longer running) PASS: gdb.pie/break.exp: breakpoint offset +1 -PASS: gdb.pie/break.exp: step onto breakpoint +FAIL: gdb.pie/break.exp: step onto breakpoint (the program is no longer running) PASS: gdb.pie/break.exp: Temporary breakpoint function PASS: gdb.pie/break.exp: Temporary breakpoint function in file PASS: gdb.pie/break.exp: Temporary breakpoint line number #1 @@ -15465,8 +15465,8 @@ === gdb Summary === -# of expected passes 14562 -# of unexpected failures 115 +# of expected passes 14550 +# of unexpected failures 127 # of expected failures 40 # of untested testcases18 # of unsupported tests 7 HP Workstation XW4200 (Intel) $ diff -u gdb.sum gdb-utrace.sum --- gdb.sum 2009-11-25 16:17:09.0 +0800 +++ gdb-utrace.sum 2009-11-25 16:16:51.0 +0800 @@ -1,4 +1,4 @@ -Test Run By root on Wed Nov 25 01:02:04 2009 +Test Run By root on Wed Nov 25 00:26:48 2009 Native configuration is i686-pc-linux-gnu === gdb tests === @@ -748,8 +748,8 @@ PASS: gdb.base/bigcore.exp: tbreak 269 PASS: gdb.base/bigcore.exp: continue PASS: gdb.base/bigcore.exp: next -PASS: gdb.base/bigcore.exp: extract next heap (stop at 50) -PASS: gdb.base/bigcore.exp: extract prev heap (stop at 50) +PASS: gdb.base/bigcore.exp: extract next heap +PASS: gdb.base/bigcore.exp: extract prev heap PASS: gdb.base/bigcore.exp: save heap size PASS: gdb.base/bigcore.exp: grab pid PASS: gdb.base/bigcore.exp: signal SIGABRT @@ -3718,7 +3718,7 @@ PASS: gdb.base/foll-fork.exp: set follow parent, cleanup Running ./gdb.base/follow-child.exp ... PASS: gdb.base/follow-child.exp: set follow-fork-mode child -FAIL: gdb.base/follow-child.exp: break +PASS: gdb.base/follow-child.exp: break Running ./gdb.base/foll-vfork.exp ... PASS: gdb.base/foll-vfork.exp: set verbose PASS: gdb.base/foll-vfork.exp: insert first vfork catchpoint @@ -13850,18 +13850,18 @@ PASS: gdb.pie/break.exp: breakpoint at start of multi line if conditional PASS:
Re: [RFC,PATCH 14/14] utrace core
This is subjective, but personally I disagree. Contrary, imho it is good that tracehook hides the (simple) details. I do not understand why the reader of, say, do_fork() should see the contents of tracehook_report_clone_complete(). This will complicate the understanding. Someone who has to debug or review fork needs to know what's going on. Yes they can find out by going through inlines, but that just costs more time and distracts from the actual problem. Those people who want to understand/change fork() do not care about utrace/ptrace usually. And please note that it is much, much easier to change this code when it lives in tracehooks.h instead of sched.c/signal.c/etc. The problem is that when you have to trace this code when something goes wrong the extra layer just holds you up. For debugging usually abstraction is a bad idea. My experience is also that in general such extra abstraction layers are frowned upon in Linux kernel code style. For example when new vendor drivers are submitted for hardware like NICs etc, they frequently tend to have all kinds of abstraction layers. Typically the first step to linuxify them is to get rid of those. This makes the code more readable, shorter, better to debug and read. Another classic example is: lock_foo() is frowned upon (Linus tends to always complain about that), rather prefer spin_lock(foo_lock) or mutex_lock(foo_lock) that makes it clear what's going on. I don't see why this should be any different for utrace. Less code obfuscation. When it's a utrace call, call it a utrace call, not something else. Why do you think this is obfuscation? Well, we can rename these helpers, s/tracehook_/utrace_/, but I don't see how this can make the code more readable. Because the inlines do not add anything to functionality and actually hide what the code does, that is obfuscation. For you it might be obvious because you've been hacking that code for quite some time, but for someone who is not in your position that's different. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: GDB Testsuite Results with CONFIG_UTRACE i686
Hi, the gdb.pie/break.exp change would be worth checking more but this is based on the old PIE patch with various known problems and for RHEL-6 there will be a different/new PIE patch implementation. Also the gdb.base/bigcore.exp and gdb.base/follow-child.exp changes would be worth checking if the change is stable across multiple runs of the specific testcase. You can also check gdb.log differences, sometimes it is apparent the change is OK. Otherwise if the change is stable across multiple runs and it is not obvious to you why it did change as you already have the machine ready could you please provide the hostname/password/etc. there? Thanks, Jan
GDB Testsuite Results on POWERPC
Hi, Here is the summary of GDB testsuite runs on a vanilla kernel and one with ptrace over utrace on a powerpc machine: Vanilla ptrace: === gdb Summary === # of expected passes13970 # of unexpected failures52 # of unexpected successes 2 # of expected failures 40 # of untested testcases 8 # of unresolved testcases 125 # of unsupported tests 55 runtest completed at Wed Nov 25 14:02:52 2009 Ptrace over utrace: === gdb Summary === # of expected passes13970 # of unexpected failures52 # of unexpected successes 2 # of expected failures 40 # of untested testcases 8 # of unresolved testcases 125 # of unsupported tests 55 runtest completed at Wed Nov 25 14:21:52 2009 Essentially, there is *no* change in any of the numbers with and without ptrace over utrace. Regards, Ananth
Re: GDB Testsuite Results on POWERPC
On Wed, 25 Nov 2009 09:59:11 +0100, Ananth N Mavinakayanahalli wrote: Essentially, there is *no* change in any of the numbers with and without ptrace over utrace. While it is probable so please rather check diff of the *.sum files as some of the results are fuzzy and - in a rare possibility - two results changing FAIL-PASS and PASS-FAIL will not show in this summary. Thanks, Jan
Re: [RFC,PATCH 0/14] utrace/ptrace
On 11/25, Ananth N Mavinakayanahalli wrote:
I ran the ptrace-tests testsuite [1] on powerpc on the vanilla ptrace
and then with ptrace/utrace. The results for ptrace/utrace look better
:-)
Great! thanks a lot Ananth for doing this.
ptrace-utrace still fails 2 tests,
FAIL: syscall-reset
I'll take a look later. Since unpatched kernel fails this test too
I am not going to worry right now. I think this is ppc specific, x86
passes this test.
step-fork: step-fork.c:56: handler_fail: Assertion `0' failed.
/bin/sh: line 5: 24803 Aborted ${dir}$tst
FAIL: step-fork
This is expected. Should be fixed by
ptrace-copy_process-should-disable-stepping.patch
in -mm tree. (I am attaching this patch below just in case)
I din't mention this patch in this series because this bug
is ortogonal to utrace/ptrace.
Oleg.
--
If the tracee calls fork() after PTRACE_SINGLESTEP, the forked child
starts with TIF_SINGLESTEP/X86_EFLAGS_TF bits copied from ptraced parent.
This is not right, especially when the new child is not auto-attaced: in
this case it is killed by SIGTRAP.
Change copy_process() to call user_disable_single_step(). Tested on x86.
Test-case:
#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;
if (!(pid = fork())) {
assert(ptrace(PTRACE_TRACEME) == 0);
kill(getpid(), SIGSTOP);
if (!fork()) {
/* kernel bug: this child will be killed by
SIGTRAP */
printf(Hello world\n);
return 43;
}
wait(status);
return WEXITSTATUS(status);
}
for (;;) {
assert(pid == wait(status));
if (WIFEXITED(status))
break;
assert(ptrace(PTRACE_SINGLESTEP, pid, 0,0) == 0);
}
assert(WEXITSTATUS(status) == 43);
return 0;
}
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Roland McGrath rol...@redhat.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
diff -puN kernel/fork.c~ptrace-copy_process-should-disable-stepping
kernel/fork.c
--- a/kernel/fork.c~ptrace-copy_process-should-disable-stepping
+++ a/kernel/fork.c
@@ -1203,9 +1203,10 @@ static struct task_struct *copy_process(
p-sas_ss_sp = p-sas_ss_size = 0;
/*
-* Syscall tracing should be turned off in the child regardless
-* of CLONE_PTRACE.
+* Syscall tracing and stepping should be turned off in the
+* child regardless of CLONE_PTRACE.
*/
+ user_disable_single_step(p);
clear_tsk_thread_flag(p, TIF_SYSCALL_TRACE);
#ifdef TIF_SYSCALL_EMU
clear_tsk_thread_flag(p, TIF_SYSCALL_EMU);
Re: [RFC,PATCH 14/14] utrace core
* Oleg Nesterov o...@redhat.com wrote: Much better. But in this case please note that most of tracehooks just do: if (unlikely(task_utrace_flags(current) SOME_EVENT)) utrace_report_some_event(); I really don't understand why we shouldn't have (trivial!) helpers for this. (As for naming - personally I do not care at all ;) We prefer helpers in most such cases - especially when in the normal case the helper has no side effects - as here. Then we want to compress all such reporting/callback as much as possible. Using helpers to abstract away functionality is one of the basic elements of writing clean kernel code. Ingo
utrace-ptrace gdb testsuite tesults
First of all, thanks Ananth and Cai for help! Jan, I need your help ;) looking at different reports I can't understand how to interpret them. To the point, I do not understand if the overall results are good or bad. The first question, are these tests supposed to be stable? For example, Those are the test results on i686 F12 hosts with and without CONFIG_UTRACE. Interesting thing is that the results on quite different on two Intel hosts. Yes! I'd say the results are just reversed. We have some PASS-FAIL changes on ProLiant DL360 G4p, and on HP Workstation XW4200 machine the _same_ tests show FAIL-PASS change. I can't imagine how utrace-ptrace can explain this difference if results are stable. I spent several hours trying to figure out how can I fix the failures, but since I never used gdb this is very much nontrivial to me. Because I just don't understand whats going on and what any particular test actually does. So. Given that the number of test is huge, and (I guess) we can't hope utrace-ptrace can pass 100% of tests, I am asking you to tell me which failures are important. Then I'll try to fix them (most probably I will ask a lot of stupid questions before I will be able to do this ;). IOW. Only you and Roland can say whether utrace-ptrace is ready for use from gdb-testsuite's pov. Please tell me which failures should be fixed to conclude that utrace-ptrace works. Oleg.
[PATCH] utrace: trivial, move CONFIG_UTRACE into General setup
Move CONFIG_UTRACE from the topmost menu into General setup, near Auditing support. (this matches the patch we sent for review) Signed-off-by: Oleg Nesterov o...@redhat.com --- init/Kconfig | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) --- UTRACE-PTRACE/init/Kconfig~MOVE_CONFIG_UTRACE 2009-11-22 17:05:10.0 +0100 +++ UTRACE-PTRACE/init/Kconfig 2009-11-24 20:34:08.0 +0100 @@ -295,6 +295,15 @@ config AUDIT logging of avc messages output). Does not do system-call auditing without CONFIG_AUDITSYSCALL. +config UTRACE + bool Infrastructure for tracing and debugging user processes + depends on EXPERIMENTAL + depends on HAVE_ARCH_TRACEHOOK + help + Enable the utrace process tracing interface. This is an internal + kernel interface exported to kernel modules, to track events in + user threads, extract and change user thread state. + config AUDITSYSCALL bool Enable system-call auditing support depends on AUDIT (X86 || PPC || S390 || IA64 || UML || SPARC64 || SUPERH) @@ -1205,15 +1214,6 @@ config STOP_MACHINE help Need stop_machine() primitive. -config UTRACE - bool Infrastructure for tracing and debugging user processes - depends on EXPERIMENTAL - depends on HAVE_ARCH_TRACEHOOK - help - Enable the utrace process tracing interface. This is an internal - kernel interface exported to kernel modules, to track events in - user threads, extract and change user thread state. - source block/Kconfig config PREEMPT_NOTIFIERS
Re: utrace-ptrace gdb testsuite tesults
In general everything where is a word thread has unstable results and nonstop tests are also a bit unstable. So where exactly is the problem in these cases? Are the tests overly timing-sensitive where there is no actual behavior bug? Or is gdb overly timing-sensitive where there is no actual kernel bug? Or is it just unknown, and might be a kernel bug after all (even an undiagnosed one in vanilla kernels)? There are IMO/hopefully very few cases tested by the gdb testsuite and still not covered by the ptrace-testsuite, I even do not much expect we will see again a new utrace regression caught by the gdb testsuite uncaught by the ptrace-testsuite. That's certainly good to hear. If you are pretty confident about that, then I am quite happy to consider nonregression on all of ptrace-tests the sole gating test for kernel changes. We just don't want to wind up having other upstream reviewers notice a regression using gdb that we didn't notice before we submitted a kernel change. Please point at some built or easily buildable kernel .rpm first. http://kojipkgs.fedoraproject.org/scratch/roland/task_1825649/ Thanks, Roland
Re: [RFC,PATCH 0/14] utrace/ptrace
On Tue, Nov 24, 2009 at 09:01:27PM +0100, Oleg Nesterov wrote: Hello. This is the new iteration of Roland's utrace patch, this time with rewrite-ptrace-via-utrace + cleanups in utrace core. 1-7 are already in -mm tree, I am sending them to simplify the review. 8-12 don not change the behaviour, simple preparations. 13-14 add utrace-ptrace and utrace Skipped over it very, very briefly. One thing I really hate about this is that it introduces two ptrace implementation by adding the new one without removing the old one. Given that's it's pretty much too later for the 2.6.33 cycle anyway I'd suggest you make sure the remaining two major architectures (arm and mips) get converted, and if the remaining minor architectures don't manage to get their homework done they're left without ptrace. 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?
Re: utrace-ptrace gdb testsuite tesults
On Wed, 25 Nov 2009 22:17:15 +0100, Roland McGrath wrote: In general everything where is a word thread has unstable results and nonstop tests are also a bit unstable. So where exactly is the problem in these cases? Are the tests overly timing-sensitive where there is no actual behavior bug? Or is gdb overly timing-sensitive where there is no actual kernel bug? Or is it just unknown, and might be a kernel bug after all (even an undiagnosed one in vanilla kernels)? gdb.server/server-run.exp: gdbserver contains data overflow/corruption, occasionally it crashes, occasionally passes. gdb.mi/mi-nonstop-exit.exp: Some race in GDB non-stop code. gdb.threads/attach-stopped.exp: Race in the testcase (I think so). etc. But in most cases I do not know, gdb.log is commonly not enough to find the problem and when it is not reproducible on the 2nd..nth run... But I+upstream already caught many races but still a lot of them remains. There are IMO/hopefully very few cases tested by the gdb testsuite and still not covered by the ptrace-testsuite, I even do not much expect we will see again a new utrace regression caught by the gdb testsuite uncaught by the ptrace-testsuite. That's certainly good to hear. If you are pretty confident about that, then I am quite happy to consider nonregression on all of ptrace-tests the sole gating test for kernel changes. We just don't want to wind up having other upstream reviewers notice a regression using gdb that we didn't notice before we submitted a kernel change. I did not verify the GDB codebase for all the ptrace calls in any way. If it is a kernel patch submit after long development period it is probably still worth checking it against GDB. Please point at some built or easily buildable kernel .rpm first. http://kojipkgs.fedoraproject.org/scratch/roland/task_1825649/ OK, taken for reverification. Regards, Jan
Re: [RFC,PATCH 0/14] utrace/ptrace
On 11/25, Christoph Hellwig wrote: On Tue, Nov 24, 2009 at 09:01:27PM +0100, Oleg Nesterov wrote: Hello. This is the new iteration of Roland's utrace patch, this time with rewrite-ptrace-via-utrace + cleanups in utrace core. 1-7 are already in -mm tree, I am sending them to simplify the review. 8-12 don not change the behaviour, simple preparations. 13-14 add utrace-ptrace and utrace Skipped over it very, very briefly. One thing I really hate about this is that it introduces two ptrace implementation by adding the new one without removing the old one. Yes, we obviously need the old one when CONFIG_UTRACE is not enabled. So, I'd like to try to restate: one thing we all really hate is that CONFIG_UTRACE exists. Given that's it's pretty much too later for the 2.6.33 cycle anyway I'd suggest you make sure the remaining two major architectures (arm and mips) get converted, and if the remaining minor architectures don't manage to get their homework done they're left without ptrace. Well, I can't comment this. I mean, I can't judge. 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. This should be clarified. I don't think ptrace-utrace adds a lot more code compared to the old ptrace. Note that we can kill a lot of old code once CONFIG_UTRACE goes away. ptrace_signal(), ptrace_notify(), even task_struct-almost_all_ptrace_related can go away. kernel/utrace.c does add 12280 bytes (on my machine), yes. What about all those other utrace killer features that have been promised for a long time? It is not clear how we can expect the new killer modules/applications which use utrace before we merge it. We already have some users, say, systemtap. But I don not know what can be counted as a really killer application of utrace. Oleg.
Re: [PATCH 1-13] utrace-ptrace V1, for internal review
On Tue, 24 Nov 2009 12:31:41 +0100, Srikar Dronamraju wrote: When I get the latest set of ptrace-tests by using. cvs -d :pserver:anoncvs:anon...@sources.redhat.com:/cvs/systemtap co ptrace-tests 1. Am I using the right source of ptrace-tests or has its location changed. It is right, webpage at: http://sourceware.org/systemtap/wiki/utrace/tests 2. Are these new testcases x86 architecture specific? step-from-clone + syscall-from-clone Fixed/checked-in, now they SKIP (rc 77) on unsupported arches. New support for ppc/ppc64 PASSes. New support for s390/s390x FAILs (kernel-2.6.18-164.6.1.el5.s390x). orig_gpr2 seems to be errorneously set to the retval (gprs[2]). 3. Shouldn't arch/powerpc/include/asm/user.h not define user_regs_struct? Not sure why but ppc uses `struct pt_regs'. Thanks, Jan
GDB Testsuite Results for CONFIG_UTRACE with biarch
Hello! Please find biarch testing results with or without CONFIG_UTRACE below from 2 Intel and 1 AMD CPU F12 x86_64 systems. gdb-32.sum was for 32-bit run with 32-bit GDB; while gdb-64.sum was for 32-bit run with 64-bit GDB. All logs can be found at, http://people.redhat.com/qcai/kratochvil/ Thanks! CAI Qian Dell PowerEdge 2850 (Intel) $ diff -u noutrace/gdb-32.sum utrace/gdb-32.sum --- noutrace/gdb-32.sum 2009-11-26 10:00:51.0 +0800 +++ utrace/gdb-32.sum 2009-11-26 09:58:52.0 +0800 @@ -1,4 +1,4 @@ -Test Run By root on Wed Nov 25 13:25:22 2009 +Test Run By root on Wed Nov 25 12:10:24 2009 Native configuration is i686-redhat-linux-gnu === gdb tests === @@ -5030,7 +5030,7 @@ PASS: gdb.base/foll-fork.exp: set follow parent, cleanup Running /rpmbuild/BUILD/gdb-7.0/gdb/testsuite/gdb.base/follow-child.exp ... PASS: gdb.base/follow-child.exp: set follow-fork-mode child -FAIL: gdb.base/follow-child.exp: break +PASS: gdb.base/follow-child.exp: break Running /rpmbuild/BUILD/gdb-7.0/gdb/testsuite/gdb.base/foll-vfork.exp ... PASS: gdb.base/foll-vfork.exp: set verbose PASS: gdb.base/foll-vfork.exp: insert first vfork catchpoint @@ -13463,7 +13463,7 @@ FAIL: gdb.java/jnpe.exp: run java next-over-throw FAIL: gdb.java/jnpe.exp: check for unwinder hook in java PASS: gdb.java/jnpe.exp: disable SIGSEGV for next-over-NPE -PASS: gdb.java/jnpe.exp: next over NPE +FAIL: gdb.java/jnpe.exp: next over NPE Running /rpmbuild/BUILD/gdb-7.0/gdb/testsuite/gdb.java/jprint.exp ... PASS: gdb.java/jprint.exp: set print sevenbit-strings PASS: gdb.java/jprint.exp: set language to java @@ -16270,8 +16270,8 @@ PASS: gdb.threads/attachstop-mt.exp: attach4 to stopped switch thread PASS: gdb.threads/attachstop-mt.exp: attach4 to stopped bt PASS: gdb.threads/attachstop-mt.exp: continue (attach4 continue) -PASS: gdb.threads/attachstop-mt.exp: attach4 stop by interrupt -PASS: gdb.threads/attachstop-mt.exp: attach4, exit leaves process sleeping +FAIL: gdb.threads/attachstop-mt.exp: attach4 stop by interrupt (timeout) +FAIL: gdb.threads/attachstop-mt.exp: attach4, exit leaves process sleeping Running /rpmbuild/BUILD/gdb-7.0/gdb/testsuite/gdb.threads/attach-stopped.exp ... PASS: gdb.threads/attach-stopped.exp: nonthreaded: set file, before attach1 to stopped process (re-read) PASS: gdb.threads/attach-stopped.exp: nonthreaded: attach1 to stopped, after setting file @@ -16286,7 +16286,7 @@ PASS: gdb.threads/attach-stopped.exp: threaded: set file, before attach1 to stopped process (re-read) PASS: gdb.threads/attach-stopped.exp: threaded: attach1 to stopped, after setting file PASS: gdb.threads/attach-stopped.exp: threaded: attach1 to stopped bt -FAIL: gdb.threads/attach-stopped.exp: threaded: attach1, exit leaves process stopped +PASS: gdb.threads/attach-stopped.exp: threaded: attach1, exit leaves process stopped PASS: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped, after setting file PASS: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt PASS: gdb.threads/attach-stopped.exp: continue (threaded: attach2 continue) @@ -16919,7 +16919,7 @@ PASS: gdb.threads/watchthreads2.exp: all threads started PASS: gdb.threads/watchthreads2.exp: watch x PASS: gdb.threads/watchthreads2.exp: set var test_ready = 1 -KFAIL: gdb.threads/watchthreads2.exp: gdb can drop watchpoints in multithreaded app (PRMS: gdb/10116) +PASS: gdb.threads/watchthreads2.exp: all threads incremented x Running /rpmbuild/BUILD/gdb-7.0/gdb/testsuite/gdb.threads/watchthreads.exp ... PASS: gdb.threads/watchthreads.exp: successfully compiled posix threads test case PASS: gdb.threads/watchthreads.exp: watch args[0] @@ -17139,7 +17139,7 @@ === gdb Summary === # of expected passes 14542 -# of unexpected failures 313 +# of unexpected failures 314 # of expected failures 40 # of untested testcases3 # of unresolved testcases 2 $ diff -u noutrace/gdb-64.sum utrace/gdb-64.sum --- noutrace/gdb-64.sum 2009-11-26 10:00:35.0 +0800 +++ utrace/gdb-64.sum 2009-11-26 09:58:11.0 +0800 @@ -1,4 +1,4 @@ -Test Run By root on Wed Nov 25 12:42:06 2009 +Test Run By root on Wed Nov 25 11:37:04 2009 Native configuration is x86_64-redhat-linux-gnu === gdb tests === @@ -5667,8 +5667,8 @@ UNRESOLVED: gdb.base/interrupt.exp: Send Control-C, second time ERROR: Undefined command signal SIGINT. UNRESOLVED: gdb.base/interrupt.exp: signal SIGINT -FAIL: gdb.base/interrupt.exp: echo more data (timeout) -FAIL: gdb.base/interrupt.exp: send end of file +PASS: gdb.base/interrupt.exp: echo more data +FAIL: gdb.base/interrupt.exp: send end of file (eof) Running /rpmbuild/BUILD/gdb-7.0/gdb/testsuite/gdb.base/jump.exp ... PASS: gdb.base/jump.exp: break before jump to non-call PASS: gdb.base/jump.exp: jump to non-call @@ -13452,7 +13452,7 @@ PASS: gdb.gdb/selftest.exp: Set xgdb prompt PASS: gdb.gdb/selftest.exp: send
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: [RFC,PATCH 0/14] utrace/ptrace
On Wed, Nov 25, 2009 at 04:40:52PM +0100, Oleg Nesterov wrote:
On 11/25, Ananth N Mavinakayanahalli wrote:
I ran the ptrace-tests testsuite [1] on powerpc on the vanilla ptrace
and then with ptrace/utrace. The results for ptrace/utrace look better
:-)
Great! thanks a lot Ananth for doing this.
ptrace-utrace still fails 2 tests,
FAIL: syscall-reset
I'll take a look later. Since unpatched kernel fails this test too
I am not going to worry right now. I think this is ppc specific, x86
passes this test.
step-fork: step-fork.c:56: handler_fail: Assertion `0' failed.
/bin/sh: line 5: 24803 Aborted ${dir}$tst
FAIL: step-fork
This is expected. Should be fixed by
ptrace-copy_process-should-disable-stepping.patch
in -mm tree. (I am attaching this patch below just in case)
I din't mention this patch in this series because this bug
is ortogonal to utrace/ptrace.
Oleg,
The patch doesn't seem to fix the issue on powerpc:
step-fork: step-fork.c:56: handler_fail: Assertion `0' failed.
/bin/sh: line 5: 17325 Aborted ${dir}$tst
FAIL: step-fork
Ananth
