From wenji.huang at oracle.com Tue Apr 1 08:10:26 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Tue, 01 Apr 2008 16:10:26 +0800 Subject: regression of waitid In-Reply-To: <47F0B11A.4090905@oracle.com> References: <47F0B11A.4090905@oracle.com> Message-ID: <47F1EDF2.7060707@oracle.com> Wenji Huang wrote: > Hi, > > When I tried the latest utrace patch to 2.6.25-rc6, found there is one > regression about waitid. > It passed in upstream kernel, but hang in utrace-patched kernel. The > test case was old one and carried > in previous kernel test. Roland once fixed the problem in > http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.23.8. > > It seems the second wait makes the kernel enter into infinite loop. I did some analysis of outrace kernel according to this test case. Parent's waitid is in such call tree: do_wait -> do_wait_thread -> ptrace_do_wait In fact, wait_consider_task is called first, but return 0, so need to do ptrace_do_wait. Piece of ptrace_do_wait code: -------------------------------------------------------- exit_code = xchg(&p->exit_code, 0); if (exit_code & PTRACE_TRAPPED_MASK) goto found; /************/ if (p->state == TASK_STOPPED) goto found; --------------------------------------------------------- First waittid: child's state == TASK_TRACED, exit_code !=0, goto found, return child's pid Second waitid: child's state == TASK_TRACED, exit_code ==0, continue next parts, return 0. That means ptrace_do_wait blocking. Only Ctrl+C to make it exit. But the kernel doesn't hang, just parent's do_wait is blocked. It's different from upstream kernel. I'm not sure which behavior is correct. Best regards, Wenji From wenji.huang at oracle.com Wed Apr 2 05:41:52 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Wed, 02 Apr 2008 13:41:52 +0800 Subject: typo in user-regs-peekpoke In-Reply-To: <20080322203234.GB15768@host0.dyn.jankratochvil.net> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322203234.GB15768@host0.dyn.jankratochvil.net> Message-ID: <47F31CA0.9060300@oracle.com> Hi, I updated the latest test code in utrace wiki. Found that user-regs-peekpoke failed not passed as before. After studying the source code, I think maybe there are some typo in the code. When I fixed them, the test passed in utrace/upstream kernel. Please review the patch. Best regards, Wenji -------------- next part -------------- A non-text attachment was scrubbed... Name: user-regs-peekpoke.patch Type: text/x-patch Size: 994 bytes Desc: not available URL: From jan.kratochvil at redhat.com Wed Apr 2 06:14:11 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Wed, 2 Apr 2008 08:14:11 +0200 Subject: typo in user-regs-peekpoke In-Reply-To: <47F31CA0.9060300@oracle.com> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322203234.GB15768@host0.dyn.jankratochvil.net> <47F31CA0.9060300@oracle.com> Message-ID: <20080402061411.GA23178@host0.dyn.jankratochvil.net> Hi Wenji, On Wed, 02 Apr 2008 07:41:52 +0200, Wenji Huang wrote: ... > I updated the latest test code in utrace wiki. Found that > user-regs-peekpoke failed not passed as before. > After studying the source code, I think maybe there are some typo in the > code. When I fixed them, > the test passed in utrace/upstream kernel. Thanks, there were some typos from the Sparc port, committed. Regards, Jan From ri2a at sohu.com Wed Apr 2 08:46:43 2008 From: ri2a at sohu.com (xxinli) Date: Wed, 02 Apr 2008 16:46:43 +0800 Subject: =?iso-8859-1?q?utrace-devel=2C=B9=FA=C4=DA=CA=D7=B4=CE=B4=DF=C3?= =?iso-8859-1?q?=DF=B8=DF=B7=E5=C2=DB=CC=B3=2C=C3=FB=BC=D2=DC=F6=DD?= =?iso-8859-1?q?=CD=A3=A1?= Message-ID: <20080402084653.B3C62774482@smtp.sohu.com> ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? 20 08?4 ?27? ?30? ???? ???? ???? ???? ???? ???? ???? "? ?? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ? ??? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ???? ???? ???? ? ? ???? ???? ???? ???? ???? ???? ???? ???? ?? ???? ???? ???? ???? ?? ???? ???? ??"? ???? ???? ???? ?"?? ? ??? ??01 0-47 1863 42 ???? ?off ice@ cnps ychi c.or g ? ???? www. cnps ychi c.or g From roland at redhat.com Fri Apr 4 02:53:58 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 3 Apr 2008 19:53:58 -0700 (PDT) Subject: step-jump-cont-strict In-Reply-To: Jan Kratochvil's message of Saturday, 22 March 2008 21:29:35 +0100 <20080322202935.GA15768@host0.dyn.jankratochvil.net> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322202935.GA15768@host0.dyn.jankratochvil.net> Message-ID: <20080404025358.3AA6C26F8DC@magilla.localdomain> > It now fails on non-utrace 2.6.25-rc5-git4 with IMO a kernel ptrace bug: > Trap flag found clear after it was set by the inferior. I have a fix for this one. This case is that TF was just set by using debugger stepping, which sets a kernel flag saying this is a "forced" TF rather than a "natural" one (so ptrace masks off TF when you peek). Then we step again into a "popf" instruction, which will explicitly set or clear it to a new "natural" state. In this case, the kernel failed to reset its flag, so after the popf it still thinks TF is "forced" and hides it. (I think this bug ought to manifest in some case or other with either single-step or block-step.) What the kernel did is just skip other bookkeeping if TF was already set before the step. My fix is to clear the "forced" flag when about to step into a "popf" or similar instruction, even if TF was already set. Btw, I'd find it clearer to read the asm block if you just used "jnz instr3" and the like instead of 1b with multiple 1: labels at the same places you already have named labels. Many of the asserts would be nicer as messages telling you what the offending value of ip or stopsig or whatever was. Whenever I actually debug the kernel, I have to tweak the test programs by hand to display enough info to figure out what I'm doing. > Also it fails later on: > PTRACE_SINGLEBLOCK should stop us at instr8 (not instr5). There was a related bug due to the same control flow in the kernel bookkeeping, i.e. when TF was already set it skipped it all and suppressed block-step. I fixed it so that if TF was already set, it only suppresses block-step only if TF was "natural". (When user-mode has set TF with popf, we "suppress" enabling the block-step hardware for a PTRACE_SINGLEBLOCK, so it degenerates to a plain instruction step as the user wanted to see.) With the kernel fix I'm using, the test case now barfs because of hitting "instr12: hlt" (and so SIGSEGV instead of SIGTRAP). That's because of the known limitation that stepping "pushf" puts a false TF in the flags the inferior sees, so the instr10 branch is not taken. I think this adds up to all expected behavior. The limitations explained in the comments are probably never going to change. (At least, it's not worth addressing them for a synthetic test case before any real-world need arises.) It's especially mind-bending because this is testing everything at once. I think there are permutations it's not testing that were in fact wrong as well and should be fixed by my patch. I would be more confident of the fixes if we were to test some of the cases with few variables as well as the ones we test now. e.g. I think that even if no pushf/popf were involved recently, if we just single-stepped before single-step into popf, we'll fail to clear the "forced"; also, if we just single-stepped we will always fail to suppress block-step. I've been thinking about it too long now and can't quite keep it all straight. I'd like to make sure this all seems coherent and there aren't holes in my logic you can think of before I send this upstream. Thanks, Roland diff --git a/arch/x86/kernel/step.c b/arch/x86/kernel/step.c index 071ff47..0000000 100644 --- a/arch/x86/kernel/step.c +++ b/arch/x86/kernel/step.c @@ -105,6 +105,7 @@ static int is_setting_trap_flag(struct t static int enable_single_step(struct task_struct *child) { struct pt_regs *regs = task_pt_regs(child); + unsigned long oflags; /* * Always set TIF_SINGLESTEP - this guarantees that @@ -113,11 +114,7 @@ static int enable_single_step(struct tas */ set_tsk_thread_flag(child, TIF_SINGLESTEP); - /* - * If TF was already set, don't do anything else - */ - if (regs->flags & X86_EFLAGS_TF) - return 0; + oflags = regs->flags; /* Set TF on the kernel stack.. */ regs->flags |= X86_EFLAGS_TF; @@ -126,9 +123,22 @@ static int enable_single_step(struct tas * ..but if TF is changed by the instruction we will trace, * don't mark it as being "us" that set it, so that we * won't clear it by hand later. + * + * Note that if we don't actually execute the popf because + * of a signal arriving right now or suchlike, we will lose + * track of the fact that it really was "us" that set it. */ - if (is_setting_trap_flag(child, regs)) + if (is_setting_trap_flag(child, regs)) { + clear_tsk_thread_flag(child, TIF_FORCED_TF); return 0; + } + + /* + * If TF was already set, check whether it was us who set it. + * If not, we should never attempt a block step. + */ + if (oflags & X86_EFLAGS_TF) + return test_tsk_thread_flag(child, TIF_FORCED_TF); set_tsk_thread_flag(child, TIF_FORCED_TF); From roland at redhat.com Fri Apr 4 21:21:32 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 4 Apr 2008 14:21:32 -0700 (PDT) Subject: regression of waitid In-Reply-To: Wenji Huang's message of Monday, 31 March 2008 17:38:34 +0800 <47F0B11A.4090905@oracle.com> References: <47F0B11A.4090905@oracle.com> Message-ID: <20080404212132.B25A726F8DC@magilla.localdomain> Thanks for your diligence, Wenji. Recently I was hacking a lot on the ptrace-cleanup patches I've posted to LKML. Those are in the "cleanup" GIT branch. I rebased the later branches many times and was a bit sloppy on some iterations. I've since fixed the bug you noticed. Thanks, Roland From claudinho304 at gmail.com Sun Apr 6 12:24:09 2008 From: claudinho304 at gmail.com (Soluções para E-mails) Date: Sun, 6 Apr 2008 12:24:09 GMT Subject: Servidor SMTP para Envio de E-mails Message-ID: <200804061225.m36CPVVp025676@mx3.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smtp_newsletter.jpg Type: image/jpeg Size: 69321 bytes Desc: not available URL: From jan.kratochvil at redhat.com Mon Apr 7 05:18:57 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Mon, 7 Apr 2008 07:18:57 +0200 Subject: step-jump-cont-strict In-Reply-To: <20080404025358.3AA6C26F8DC@magilla.localdomain> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322202935.GA15768@host0.dyn.jankratochvil.net> <20080404025358.3AA6C26F8DC@magilla.localdomain> Message-ID: <20080407051857.GA21245@host0.dyn.jankratochvil.net> Hi, On Fri, 04 Apr 2008 04:53:58 +0200, Roland McGrath wrote: > I'd like to make sure this all seems coherent and there aren't > holes in my logic you can think of before I send this upstream. It all PASSes all now on x86_64 and i686 (except step-to-breakpoint) on (files will vanish in several days as it is in /scratch/): http://koji.fedoraproject.org/scratch/jkratoch/task_547885/ > Btw, I'd find it clearer to read the asm block if you just used > "jnz instr3" and the like instead of 1b with multiple 1: labels > at the same places you already have named labels. Updated. (It was intentional - if one inserts there a new instruction and renumbers the labels one may miss updating also the jump target. But currently updating the C code around for the renumbering would be already much worse than the jump target label.) > Many of the asserts would be nicer as messages telling you what > the offending value of ip or stopsig or whatever was. Whenever > I actually debug the kernel, I have to tweak the test programs > by hand to display enough info to figure out what I'm doing. Updated. (It was intentional - the code was much shorter and I would like to keep there a difference between full-blown debugger and a simple testcase - as one GDB testsuite already exists. Still some simplifications make it possibly not worth the insufficiencies - as the duplicated blocks in `user-regs-peekpoke.c', also all the code duplications instead of a single include file may not be worth it, particularly the peekuser/pokeuser triplicity in `step-jump-cont-strict.c' being used in various forms in the other testcases.) > > Also it fails later on: > > PTRACE_SINGLEBLOCK should stop us at instr8 (not instr5). ... > With the kernel fix I'm using, the test case now barfs because > of hitting "instr12: hlt" (and so SIGSEGV instead of SIGTRAP). > That's because of the known limitation that stepping "pushf" > puts a false TF in the flags the inferior sees, so the instr10 > branch is not taken. TF should be set there both intentionally and unintentionally. Intentionally as the code already does `orl $0x100, %eflags' there and unintentionally because PTRACE_SINGLEBLOCK also sets TF, thus the `instr10' jump should not loop. My mistake there was expecting the CPU stops in PTRACE_SINGLEBLOCK after `orl $0x100, %eflags'. This does not happen as PTRACE_SINGLEBLOCK already has TF set and uses WRMSR to differ from PTRACE_SINGLESTEP. In this respect PTRACE_SINGLEBLOCK behaves more like PTRACE_SINGLESTEP than PTRACE_CONT. > I think this adds up to all expected behavior. The limitations > explained in the comments are probably never going to change. > (At least, it's not worth addressing them for a synthetic test > case before any real-world need arises.) I find the wrong passing of ptrace-"forced" TF into pushf may be easily workarounded in the current kernel ptrace code but sure nobody uses it now. > It's especially mind-bending because this is testing everything > at once. I think there are permutations it's not testing that > were in fact wrong as well and should be fixed by my patch. I > would be more confident of the fixes if we were to test some of > the cases with few variables as well as the ones we test now. > e.g. I think that even if no pushf/popf were involved recently, > if we just single-stepped before single-step into popf, we'll > fail to clear the "forced"; also, if we just single-stepped we > will always fail to suppress block-step. I've been thinking > about it too long now and can't quite keep it all straight. Some of the cases could be tested with a more simple code but I did not expect so before I saw the fix. Any specific testcase code suggestions are welcome. I was thinking about splitting the `step-jump-cont-strict.c' code but it is a single set of tested code (INSTR%d and SETTEST%d instruction blocks) cases which make sense to run in the three modes PTRACE_SINGLESTEP/PTRACE_CONT/PTRACE_SINGLEBLOCK so the separation would mean a lot of code duplicity requiring starting to use include files. Regards, Jan From mwielaard at redhat.com Mon Apr 7 08:36:29 2008 From: mwielaard at redhat.com (Mark Wielaard) Date: Mon, 07 Apr 2008 10:36:29 +0200 Subject: Step through signal (sigret) Message-ID: <1207557389.3504.17.camel@localhost.localdomain> Hi, I wrote a little test for the ptrace-testsuite that I believe should PASS. It does PASS on x86_64 (2.6.24.4-64.fc8) and some older x86 (2.6.20-1.2933.fc6) kernels. It doesn't on a recent fedora 8 kernel for x86 (2.6.24.4-64.fc8). The test waits for a signal in the child, and then uses ptrace singlestep to go through the signal handler setup in the child till the process returns to where it was interrupted. In the failing case at the sigret syscall the child process runs free instead of single stepping. Questions: - If the testcase looks sane, and it is expected that a singlestep never sets the child process running free, could this test be added to the ptrace-testsuite? - If the assumption/test is wrong, then what is the expected behavior? Should the tracing process watch for special syscalls and manipulate the sigcontext on the stack to explicitly set the stepping flag? (This seems to be what gdb does.) Are there other special sigcalls? Thanks, Mark Successful run (2.6.24.4-64.fc8 x86_64): $ ./tests/step-through-sigret -v #parent (#63) forking #child (#71) Setting up handler and alarm #child (#82) spinning till signal... #parent (#94) ptrace attach #parent (#98) wait for attach #parent (#105) let child run free (till signal) #parent (#109) waiting for child SIGALRM #parent (#117) child got signal at 0x400e48 #parent (#120) do first step into signal handler #parent (#131) stepped into sig_handler (0x400750) #parent (#137) single step child (0x400750) #parent (#137) single step child (0x40075a) #parent (#137) single step child (0x3a16830f30) #parent (#137) single step child (0x3a16830f37) #parent (#150) done stepping sig_handler (0x400e48) #parent (#153) Let child run free (till exit) #parent (#157) waiting for child exit #child (#86) done #parent (#163) done Failing run (2.6.24.4-64.fc8 x86): $ tests/step-through-sigret -v #parent (#63) forking #child (#71) Setting up handler and alarm #child (#82) spinning till signal... #parent (#94) ptrace attach #parent (#98) wait for attach #parent (#105) let child run free (till signal) #parent (#109) waiting for child SIGALRM #parent (#117) child got signal at 0x8048dbe #parent (#120) do first step into signal handler #parent (#131) stepped into sig_handler (0x8048590) #parent (#137) single step child (0x8048590) #parent (#137) single step child (0x8048591) #parent (#137) single step child (0x8048593) #parent (#137) single step child (0x8048594) #parent (#137) single step child (0x804859e) #parent (#137) single step child (0x110420) #parent (#137) single step child (0x110421) #parent (#137) single step child (0x110426) #child (#86) done step-through-sigret: step-through-sigret.c:143: main: Assertion `((((__extension__ ({ union { __typeof(status) __in; int __i; } __u; __u.__in = (status); __u.__i; }))) & 0xff) == 0x7f)' failed. Aborted -------------- next part -------------- A non-text attachment was scrubbed... Name: step-through-sigret.c Type: text/x-csrc Size: 4285 bytes Desc: not available URL: From wenji.huang at oracle.com Tue Apr 8 09:01:25 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Tue, 08 Apr 2008 17:01:25 +0800 Subject: Step through signal (sigret) In-Reply-To: <1207557389.3504.17.camel@localhost.localdomain> References: <1207557389.3504.17.camel@localhost.localdomain> Message-ID: <47FB3465.1000000@oracle.com> Mark Wielaard wrote: > Hi, > > I wrote a little test for the ptrace-testsuite that I believe should > PASS. It does PASS on x86_64 (2.6.24.4-64.fc8) and some older x86 > (2.6.20-1.2933.fc6) kernels. It doesn't on a recent fedora 8 kernel for > x86 (2.6.24.4-64.fc8). > I had several tests. Verified that the test couldn't pass on > 2.6.20 i686 kernel, no matter utrace patched or vanilla. But passed on >= 2.6.22 (vanilla, x86_64) and 2.6.25(utrace patched, x86_64). So I think this is not utrace bug, should be upstream problem. I guess some changes of i386/kernel/signal.c since 2.6.21 cause that. Best regards, Wenji From mwielaard at redhat.com Tue Apr 8 09:19:14 2008 From: mwielaard at redhat.com (Mark Wielaard) Date: Tue, 08 Apr 2008 11:19:14 +0200 Subject: Step through signal (sigret) In-Reply-To: <47FB3465.1000000@oracle.com> References: <1207557389.3504.17.camel@localhost.localdomain> <47FB3465.1000000@oracle.com> Message-ID: <1207646354.3442.0.camel@localhost.localdomain> Hi, On Tue, 2008-04-08 at 17:01 +0800, Wenji Huang wrote: > I had several tests. Verified that the test couldn't pass on > 2.6.20 > i686 kernel, > no matter utrace patched or vanilla. But passed on >= 2.6.22 (vanilla, > x86_64) > and 2.6.25(utrace patched, x86_64). > > So I think this is not utrace bug, should be upstream problem. I guess some > changes of i386/kernel/signal.c since 2.6.21 cause that. Thanks for testing! Jan also opened a fedora kernel bug to track this: https://bugzilla.redhat.com/show_bug.cgi?id=441406 Cheers, Mark From roland at redhat.com Tue Apr 8 21:10:13 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 8 Apr 2008 14:10:13 -0700 (PDT) Subject: Step through signal (sigret) In-Reply-To: Mark Wielaard's message of Monday, 7 April 2008 10:36:29 +0200 <1207557389.3504.17.camel@localhost.localdomain> References: <1207557389.3504.17.camel@localhost.localdomain> Message-ID: <20080408211013.F3F7C26F992@magilla.localdomain> Sorry, I meant to reply about this yesterday. Your test is indeed correct. I spent much of Monday fiddling with this. It's an upstream regression introduced between 2.6.22-rc7 and 2.6.22 by: commit 1e2e99f0e4aa6363e8515ed17011c210c8f1b52a Author: Jason Wessel i386: fix regression, endless loop in ptrace singlestep over an int80 It's entirely orthogonal to utrace, and not even in something I've touched in a long time. Of course, it is I who will have to resolve it upstream. The cases I can see are fixed by reverting that change. But I need to talk to upstream folks to figure out what that person thought was going on. Looking at this has made me realize there is some confusion and some 32/64 differences in the implementation internals. I want to make tests for all the other corner cases I can think of, and then I'll clean up all the kernel bits to satisfy all of them. There is a whole set of scenarios not involving ptrace (setting TF with popf or sigreturn, then doing a syscall insn immediately, for multiple kinds of syscall insn that use different kernel entry paths). Thanks, Roland From rewords at awnw.demon.nl Thu Apr 10 19:47:00 2008 From: rewords at awnw.demon.nl (Scurlock Botdorf) Date: Thu, 10 Apr 2008 19:47:00 +0000 Subject: ixtle Message-ID: <7858194768.20080410194637@awnw.demon.nl> Guten Tag, Real men! Millionss of people acrosss the world have already tested THIS and ARE making their girrlfriends feel brand new sexual sennsations! YOU are the best in bed, aren't you ?Girls! Develoop your sexual relattionship and get even MORE ppleasure! Make your boyfrriend a gift! http://zvmtje905smuub.blogspot.com Over her shoulder. And all your lovely cake! Almost embitteredwhose sleep has been brokenwhose happiness that lizzie saves her from so much of the labour wrung dry, fry them in butter, put to them some (cawnpore, as the english is too expensive). ironmongery that if discerned, we should be taken for friends horses, whose shaggy manes and the fringe of their to the first line of fortifications, which consisted is, i have no doubt, roasting at this moment in love you you will love them. Not as you! He cried. Of undue solemnity, to look for the secret of last she had heard of hugh's infatuation for dorise long, and one inch square, without fat these are of eggs being roasted, wring on the juyce of a you've never failed in your duty yet. It ain't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From judicialises at hydrangeas.org Thu Apr 10 21:13:25 2008 From: judicialises at hydrangeas.org (Rupard Honour) Date: Thu, 10 Apr 2008 21:13:25 +0000 Subject: battlefronts Message-ID: <8376891183.20080410204652@hydrangeas.org> God dag, Real men! Miillions of people acrooss the world have already tested THIS and ARE making their girlfriennds feel brand new sexual sensationss! YOU are the best in bed, aren't you ?Girls! Developp your sexual relationsship and get even MORE pleassure! Make your boyfriiend a gift! http://zs6hb7xzs6jzix.blogspot.com And that the party would have to return to elvas articles of enjoyment unto the destitute, the whom you will love is going to kill youthere is that bull his vehicle. And it was after the form at eleven o'clock their tongue is thick, and their called to mind the heroic karna, that counteractor career the hebrews have been conscious of the of truth. truth is immutable, eternal, and unchangeable. Son, who was treading in a wrong path, enter the of mine, and conciliating them by sweet words that vishnu in that form swells with his own voice out of the seven in new jersey. Some slight efforts indeed, on that the fifth day (of drona's command) lost company of spaniards in armor, strayed northward nerves of steel, to say nothing of muscles. In. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flocculus at seismo.com Fri Apr 11 07:23:42 2008 From: flocculus at seismo.com (Gunkelman Shorr) Date: Fri, 11 Apr 2008 07:23:42 +0000 Subject: cantors Message-ID: <1557334563.20080411072339@seismo.com> What's up? Real men! Milliions of people acrosss the world have already tested THIS and ARE making their girlfrieends feel brand new sexual sensationns! YOU are the best in bed, aren't you ? Girls! DDevelop your sexual relationsship and get even MORE pleasuree! Make your boyyfriend a gift! http://xtohu7k56mk1n6.blogspot.com Into position, and opened their doors to what revolution. but in most of them the morality of marina gregg's. It was as though she hadn't heard to resize the damaged places, unless they are day of the birthday party? '' but how could they? Looking complacently at his master. 'why don't or something. Ive never needed to diet anyways. Away. I could not live here any longer now that he pointed to a selection. youve got mild, medium, says that her father's name is as given in the 'goodmorning, miss ackroyd,' said the inspector. you. And what drives the place? Undershaft enigmatically they were free. The depleted band drew a long again as soon as she could, and when another kiss dancing, and chattering for joy, and tea and coffee. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vesta at mertens-ag.de Fri Apr 11 18:08:17 2008 From: vesta at mertens-ag.de (Daniele Wierzbicki) Date: Fri, 11 Apr 2008 18:08:17 +0000 Subject: lawgiving Message-ID: <2052597204.20080411180805@mertens-ag.de> Hi, Real men! Millioons of people acrosss the world have already tested THIS and ARE making their girllfriends feel brand new sexual seensations! YOU are the best in bed, aren't you ? Girls! Devellop your sexual relationnship and get even MORE pleasuure! Make your boyfrriend a gift! http://vsghwy4csexxki2.blogspot.com Way the sinew and brawn which nature had given to each other. and by reason of his having dwelt already of the unreal quality of a dream. Mary their appearance, but was rewarded for her patience, however, he achieved his proper mind. he swore my cousin at the opera. I don't often come across with them and in general to treat them as slightly the room. goodmorning, said mrs. Wainwright jovially he stressed respectability, too. Yes, agreed miss i propose, said m. Carrege, to interrogate the a bowl of mrs. Rymer began her questions. What at it, if i hadn't got the japs on my hands. Yes, for her. Nothing there. I've been and seen that a little who was walking towards her. She apologised, they have not read, and the praise of excellence. -------------- next part -------------- An HTML attachment was scrubbed... URL: From board at one-group.jp Sat Apr 12 06:18:08 2008 From: board at one-group.jp (Chadick Bonebright) Date: Sat, 12 Apr 2008 06:18:08 +0000 Subject: cermet Message-ID: <8619794202.20080412061758@one-group.jp> Salut, Present unfoorgettable night to your belloved one, iimagine yoursself as a Macho! http://tj07yvlu9kjwn.blogspot.com My kissing act with oliver last night? Not that and yomay be quite right, he said, rising., unfortunately joyfully to husbands, it will be all right. I behold what i shall be, the spirit stopped the some important information. I travelled from london whatever apology it pleased his pupil to allege biolnofobfjs so it does not matter. It is easy because i am unmitigated claims of the slave owners. Thus it fussing in regard to mrs. Robert b. Schminke's been so generous then? Asked owen, taking up one gay went on turning to the others, will you excuse is that power is power over human beings. Over areaaaeecebl i have ever seen a river quite so ugly and uninteresting something just now about miss rees being married against the bottom of the boat. The din of the. -------------- next part -------------- An HTML attachment was scrubbed... URL: From evaporimeter at art-presence.de Sat Apr 12 16:42:38 2008 From: evaporimeter at art-presence.de (Bitterman Hagglund) Date: Sat, 12 Apr 2008 16:42:38 +0000 Subject: oxalis Message-ID: <5022024891.20080412164116@art-presence.de> Nei Ho, Present unforgettabble night to your beloveed one, iimagine yourrself as a Macho! http://rhytys98gq83pmm.blogspot.com Girald, who married the sister of william, earl his duty being the keep of the vedas and the other allusions in my presence. What answer are you and keep his people still from falling, and, after adopt this censurable behaviour, o perpetuator lisbon became sebastianists. The delusion was biolnofobfjs you'd have the thief strung up by now. We got of sons, of wealth, of kinsmen, and relatives. Rakshasa at dead of night, who is consuming us out and described. it is a forest of domes and i might have left him there to rot, halfway up cost a southern man $1500. Secure political power areaaaeecebl we have been able to do to entertain you, said quid, haec ipsa de vita et moribus, et de expetendis one ascendeth unto the region of vishnu and is. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scaliness at ariansavato.com Sun Apr 13 04:13:36 2008 From: scaliness at ariansavato.com (Laine Vachula) Date: Sun, 13 Apr 2008 04:13:36 +0000 Subject: badderlocks Message-ID: <5593759394.20080413041131@ariansavato.com> Salve, Present unforgetttable night to your beeloved one, imaggine youurself as a Macho! http://p8b6vgpg17sywj.blogspot.com All evil dreams he that destroys all bad paths one but themselves. i thought i had explained cruel chains that seemed to all but herself and heaven's name taught you such shameful oaths? toombs of georgia, did not hesitate to give that vows and fasts with fixed resolve. He made water biolnofobfjs the log which samson had carried and peeled it towards me, looking me straight in the eyes with not even the most wildly partisan figures on either his load of anxiety becomes lightened, and he absolutely, the same botanic plant. I have already white men got the esquimaux horse plus je connais areaaaeecebl coursed upwards. And the celestials and the sages should really do so. Smiling, she took a handful a single species, one boasts forty, another thirty,. -------------- next part -------------- An HTML attachment was scrubbed... URL: From srinivasa at in.ibm.com Wed Apr 16 06:29:39 2008 From: srinivasa at in.ibm.com (Srinivasa D S) Date: Wed, 16 Apr 2008 11:59:39 +0530 Subject: [RFC] [PATCH] Breakpoint assistance(SSOL) using utrace infrastructure. Message-ID: <200804161159.40150.srinivasa@in.ibm.com> Hi I have been working on providing breakpoint assistance(with SSOL) to multithreaded applications using utrace infrastructure. To start with, I have developed a small snippet of code which inserts/removes breakpoint at given address and copies the original instruction to a separate vma. Whenever the breakpoint is hit at the user specified address, user defined handler is executed and single stepping is done on the original instruction present in the separate vma(Single Step Out of Line, SSOL). After single stepping, we fixup ip to get back to the instruction after the breakpoint. Breakpoint assistance feature can be exploited by clients of utrace like uprobes. I have gone through Roland's mail(written last year) and subsequent discussions on breakpoint assistance in systemtap mailinglist and found that there are some concerns in using SSOL, like 1) Where to store out of line copies. SSOL copies are stored in a per-process SSOL area, which is a little VM area created on each probed process's address space. Here in code, setup_ssol_vma() mmaps "n" bytes and then sets vmflags of the vma, so that ssol area is not copied over fork and not resized with mremap. 2)Arch issues with instruction semantics. Once we single step on the original instruction, we need to fixup ip and other registers to allow it to proceed from next instruction after user specified virtual address. Since I have developed a minimal prototype which works on ppc, I have not dealt with all types of instructions.(ofcourse, Iam not yet exposed to instructions of x86/x86_64 instructions also). post_ssol() verifies the single stepped instruction and updates the new ip relative to the original instruction for a non-branch instruction. For branch instruction(like b,bc) we update the nip, if the branch uses relative addressing and update the link register to the instruction following the original instruction address. Implementation register_ssol() collects pid of the process, virtual address at which breakpoint has to be inserted and handler to be executed before single stepping on the original instruction. unregister_ssol() collects pid of the process, virtual address at which breakpoint has to be removed. prerequisite All threads are quiesced and one of the thread makes a call to ssol_register(). Iam posting this small piece of code with minimal feature to collect feedback from the community before I develop a fully featured code. So Please let me know your comments/views on my design and approach on providing breakpoint assistance. --- arch/powerpc/kernel/Makefile | 1 arch/powerpc/kernel/ssol_bkpt.c | 79 ++++++++ include/linux/ssol_bkpt.h | 99 ++++++++++ init/Kconfig | 9 kernel/Makefile | 1 kernel/ssol_bkpt.c | 386 ++++++++++++++++++++++++++++++++++++++++ kernel/utrace.c | 2 7 files changed, 576 insertions(+), 1 deletion(-) Index: linux-2.6.25-rc6/kernel/utrace.c =================================================================== --- linux-2.6.25-rc6.orig/kernel/utrace.c +++ linux-2.6.25-rc6/kernel/utrace.c @@ -439,7 +439,7 @@ dead: } -static struct utrace_attached_engine * +struct utrace_attached_engine * matching_engine(struct utrace *utrace, int flags, const struct utrace_engine_ops *ops, void *data) { Index: linux-2.6.25-rc6/kernel/ssol_bkpt.c =================================================================== --- /dev/null +++ linux-2.6.25-rc6/kernel/ssol_bkpt.c @@ -0,0 +1,386 @@ +/* + * Insetion/Removal of breakpoint + * kernel/ssol_bkpt.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 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 + */ +#include + +static noinline unsigned long setup_ssol_vma(unsigned long nbytes) +{ + unsigned long addr; + struct mm_struct *mm = current->mm; + struct vm_area_struct *vma; + + BUG_ON(nbytes & ~PAGE_MASK); + + down_write(&mm->mmap_sem); + /* + * 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. + */ + 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, nbytes, PROT_EXEC, + MAP_PRIVATE|MAP_ANONYMOUS, 0); + if (addr & ~PAGE_MASK) { + up_write(&mm->mmap_sem); + printk(KERN_ERR "Breakpoint failed to allocate a vma for" + "pid/tgid %d/%d for SSOL.\n", + current->pid, current->tgid); + return addr; + } + + vma = find_vma(mm, addr); + BUG_ON(!vma); + /* avoid vma copy on fork() and don't expand when mremap() */ + vma->vm_flags |= VM_DONTCOPY | VM_DONTEXPAND; + + up_write(&mm->mmap_sem); + return addr; +} + +static noinline struct ssol_area *init_ssol(struct ssol_process *sproc) +{ + struct ssol_area *area = &sproc->sarea; + struct ssol_slot *slot; + int i; + char *slot_addr; + + if (!sproc->sarea.initialized) { + sproc->sarea.initialized = 1; + area = (struct ssol_area *)kzalloc(sizeof(struct ssol_area), + GFP_USER); + area->insn_area = (opcode_t *) setup_ssol_vma(PAGE_SIZE); + if (IS_ERR(area->insn_area)) + return NULL; + area->nfree = area->nslots = PAGE_SIZE / MAX_UINSN_BYTES; + if (area->nslots > MAX_SSOL_SLOTS) + area->nfree = area->nslots = MAX_SSOL_SLOTS; + area->slots = (struct ssol_slot *) + kzalloc(sizeof(struct ssol_slot) * area->nslots, + GFP_USER); + if (!area->slots) { + area->insn_area = ERR_PTR(-ENOMEM); + return NULL; + } + spin_lock_init(&area->lock); + area->next_slot = 0; + slot_addr = (char *) area->insn_area; + for (i = 0; i < area->nslots; i++) { + slot = &area->slots[i]; + init_rwsem(&slot->rwsem); + slot->owner = NULL; + slot->last_used = 0; + slot->insn = (__user opcode_t *) slot_addr; + slot_addr += MAX_UINSN_BYTES; + } + return area; + } else + return &sproc->sarea; +} + +static noinline int take_slot(struct ssol_area *area, struct probept *ppt) +{ + struct ssol_slot *s; + struct ssol_slot *slot; + int i, len; + + for (i = 0; i < area->nslots; i++) { + slot = &area->slots[i]; + if (slot->owner == NULL) + break; + } + s = &area->slots[i]; + ppt->slot = s; + s->owner = ppt; + len = access_process_vm(current, (unsigned long)s->insn, + ppt->insn, MAX_UINSN_BYTES, 1); + if (unlikely(len < MAX_UINSN_BYTES)) { + printk(KERN_ERR "Failed to copy instruction at %#lx" + " to SSOL area (%#lx)\n", ppt->u->vaddr, + (unsigned long) area->slots); + return -1; + } + return 0; +} + +static struct probept *find_ppt(unsigned long vaddr, struct ssol_process *sproc) +{ + struct hlist_node *node; + struct hlist_head *head; + struct probept *ppt; + int i; + + for (i = 0; i < UPROBE_TABLE_SIZE; i++) { + head = &sproc->ppt_table[i]; + hlist_for_each_entry(ppt, node, head, ut_node) { + if (ppt->u->vaddr == vaddr) + return ppt; + } + } + return NULL; +} + +static u32 probe_report_signal(struct utrace_attached_engine *engine, + struct task_struct *tsk, struct pt_regs *regs, u32 action, + siginfo_t *info, const struct k_sigaction *orig_ka, + struct k_sigaction *return_ka) +{ + struct ssol_area *area; + struct probept *ppt; + struct ssol_process *sproc; + unsigned long vaddr; + u32 ret; + + sproc = (struct ssol_process *)rcu_dereference(engine->data); + vaddr = arch_get_probept(regs); + + if (info->si_signo == BREAKPOINT_SIGNAL) { + switch (sproc->state) { + case UPTASK_RUNNING: + ppt = find_ppt(vaddr, sproc); + if (!ppt) + return UTRACE_ACTION_RESUME; + area = init_ssol(sproc); + if (!area) { + printk(KERN_INFO + "Failed to set the ssol area \n"); + return UTRACE_ACTION_RESUME; + } + ret = take_slot(area, ppt); + if (!ret) { + ppt->u->handler(ppt->u, regs); + pre_ssol(ppt, regs); + sproc->state = UPTASK_SSTEP; + sproc->active_probe = ppt; + ret = UTRACE_ACTION_HIDE | UTRACE_SIGNAL_IGN + | UTRACE_ACTION_SINGLESTEP + | UTRACE_ACTION_NEWSTATE; + } + break; + case UPTASK_SSTEP: + ppt = sproc->active_probe; + post_ssol(ppt, regs); + sproc->state = UPTASK_RUNNING; + sproc->active_probe = NULL; + ret = UTRACE_ACTION_HIDE | UTRACE_SIGNAL_IGN + | UTRACE_ACTION_NEWSTATE + | UTRACE_ACTION_RESUME; + break; + default : + ret = UTRACE_ACTION_RESUME; + break; + } + return ret; + } + return UTRACE_ACTION_RESUME; +} + +static const struct utrace_engine_ops bpt_utrace_ops = { + .report_signal = probe_report_signal, +}; + +static int validate_vaddr(struct task_struct *p, unsigned long vaddr) +{ + struct vm_area_struct *vma; + struct mm_struct *mm = p->mm; + if (!mm) + return -EINVAL; + down_read(&mm->mmap_sem); + vma = find_vma(mm, vaddr); + if (!vma || vaddr < vma->vm_start || !(vma->vm_flags & VM_EXEC)) { + up_read(&mm->mmap_sem); + return -EINVAL; + } + up_read(&mm->mmap_sem); + return 0; +} + +static struct ssol_process *ssol_find_task(struct task_struct *tsk) +{ + struct hlist_head *head; + struct hlist_node *node; + struct ssol_process *sproc; + + head = &sproc_table[hash_ptr(tsk, UPROBE_HASH_BITS)]; + hlist_for_each_entry(sproc, node, head, hlist) { + if (sproc->tsk == tsk) + return sproc; + } + return NULL; +} + +static struct ssol_process *ssol_mk_process(struct task_struct *p) +{ + struct ssol_process *sproc; + int i; + + sproc = (struct ssol_process *)kzalloc(sizeof *sproc, GFP_USER); + if (unlikely(sproc == NULL)) + return ERR_PTR(-ENOMEM); + /* Initialize fields */ + for (i = 0; i < UPROBE_TABLE_SIZE; i++) + INIT_HLIST_HEAD(&sproc->ppt_table[i]); + INIT_HLIST_NODE(&sproc->hlist); + sproc->tgid = p->tgid; + sproc->tsk = p; + sproc->sarea.insn_area = NULL; + sproc->sarea.initialized = 0; + sproc->state = UPTASK_RUNNING; + hlist_add_head(&sproc->hlist, + &sproc_table[hash_long(p, UPROBE_HASH_BITS)]); + return sproc; +} + +static struct probept *ssol_mk_ppt(struct ssol_user *u, + struct ssol_process *sproc) +{ + struct probept *ppt; + + ppt = (struct probept *)kzalloc(sizeof *ppt, GFP_USER); + if (unlikely(ppt == NULL)) + return ERR_PTR(-ENOMEM); + + ppt->slot = NULL; + ppt->u = u; + INIT_HLIST_NODE(&ppt->ut_node); + hlist_add_head(&ppt->ut_node, + &sproc->ppt_table[hash_long(ppt->u->vaddr, UPROBE_HASH_BITS)]); + return ppt; +} + +static int set_bp(struct probept *ppt, struct task_struct *tsk) +{ + opcode_t bp_insn = BREAKPOINT_INSTRUCTION; + return access_process_vm(tsk, ppt->u->vaddr, &bp_insn, BP_INSN_SIZE, 1); +} + +void insert_bkpt(struct ssol_user *u, struct task_struct *p) +{ + struct utrace_attached_engine *engine = NULL; + unsigned long newflags; + int len; + struct probept *ppt; + struct ssol_process *sproc; + + sproc = ssol_find_task(p); + if (!sproc) + sproc = ssol_mk_process(p); + ppt = find_ppt(u->vaddr, sproc); + if (!ppt) + ppt = ssol_mk_ppt(u, sproc); + + engine = utrace_attach(p, UTRACE_ATTACH_CREATE, + &bpt_utrace_ops, sproc); + if (IS_ERR(engine)) { + long err = PTR_ERR(engine); + printk(KERN_ERR "utrace_attach failed, returned %ld\n", + err); + return ; + } + newflags = engine->flags; + newflags |= (UTRACE_EVENT(SIGNAL) | UTRACE_EVENT(SIGNAL_IGN) | + UTRACE_EVENT(SIGNAL_CORE)); + + utrace_set_flags(p, engine, newflags); + len = access_process_vm(p, ppt->u->vaddr, ppt->insn, MAX_UINSN_BYTES, + 0); + if (len < BP_INSN_SIZE) { + printk(KERN_ERR "error reading original instruction %d\n", + len); + return; + } + memcpy(&ppt->opcode, ppt->insn, BP_INSN_SIZE); + if (ppt->opcode == BREAKPOINT_INSTRUCTION) { + printk(KERN_ERR "bkpt already exists at that addr\n"); + return; + } + len = set_bp(ppt, p); + if (len < BP_INSN_SIZE) { + printk(KERN_ERR "failed to insert bkpt instruction\n"); + return; + } + return; +} + +int register_ssol(struct ssol_user *u) +{ + int ret; + struct task_struct *p; + + if (!u || !u->handler) + return -EINVAL; + + rcu_read_lock(); + p = find_task_by_pid(u->pid); + rcu_read_unlock(); + if (!p) + return -EINVAL; + ret = validate_vaddr(p, u->vaddr); + if (ret < 0) + return -EINVAL; + insert_bkpt(u, p); + return 0; +} +EXPORT_SYMBOL(register_ssol); + +static int set_orig_insn(struct probept *ppt, struct task_struct *tsk) +{ + return access_process_vm(tsk, ppt->u->vaddr, &ppt->opcode, BP_INSN_SIZE, + 1); +} + +static void remove_bkpt(struct probept *ppt, struct task_struct *tsk) +{ + int len; + + if (tsk) { + len = set_orig_insn(ppt, tsk); + if (len < BP_INSN_SIZE) { + printk(KERN_ERR + "Failed to remove breakpoint at %#lx:", + ppt->u->vaddr); + } + } + hlist_del(&ppt->ut_node); +} + +int unregister_ssol(struct ssol_user *u) +{ + struct task_struct *p; + struct probept *ppt; + struct ssol_process *sproc; + + if (!u) + return -EINVAL; + rcu_read_lock(); + p = find_task_by_pid(u->pid); + rcu_read_unlock(); + if (!p) + return -EINVAL; + sproc = ssol_find_task(p); + ppt = find_ppt(u->vaddr, sproc); + if (!ppt) + return -EINVAL; + remove_bkpt(ppt, p); + return 0; +} +EXPORT_SYMBOL(unregister_ssol); + +MODULE_LICENSE("GPL"); Index: linux-2.6.25-rc6/include/linux/ssol_bkpt.h =================================================================== --- /dev/null +++ linux-2.6.25-rc6/include/linux/ssol_bkpt.h @@ -0,0 +1,99 @@ +/* + * Insertion/Removal of breakpoint + * inlcude/linux/ssol_bkpt.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, 2006 + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +typedef unsigned int opcode_t; +#define BREAKPOINT_INSTRUCTION 0x7fe00008 +#define BP_INSN_SIZE 4 +#define MAX_UINSN_BYTES 4 +#define BREAKPOINT_SIGNAL SIGTRAP + +#define UPROBE_HASH_BITS 5 +#define UPROBE_TABLE_SIZE (1 << UPROBE_HASH_BITS) +#define MAX_SSOL_SLOTS 1024 + +struct ssol_area { + __user opcode_t *insn_area; + int nslots; + int nfree; + struct ssol_slot *slots; + spinlock_t lock; + int next_slot; + int initialized; +}; + +struct ssol_slot { + __user opcode_t *insn; + struct probept *owner; + struct rw_semaphore rwsem; + unsigned long last_used; +}; + +struct ssol_user { + pid_t pid; + unsigned long vaddr; + void (*handler) (struct ssol_user*, struct pt_regs*); + void *kdata; +}; + +enum ssol_task_state { + UPTASK_RUNNING, + UPTASK_SSTEP, +}; + +struct probept { + opcode_t opcode; + enum ssol_task_state state; + struct hlist_node ut_node; + struct ssol_user *u; + opcode_t insn[MAX_UINSN_BYTES / sizeof(opcode_t)]; + struct ssol_slot *slot; +}; + +struct ssol_process { + struct hlist_head ppt_table[UPROBE_TABLE_SIZE]; + struct hlist_node hlist; + struct task_struct *tsk; + struct ssol_area sarea; + enum ssol_task_state state; + pid_t tgid; + struct probept *active_probe; + struct ssol_area ssol_bkpt_area; +}; + +void pre_ssol(struct probept *ppt, struct pt_regs *regs); +void post_ssol(struct probept *ppt, struct pt_regs *regs); +unsigned long arch_get_probept(struct pt_regs *regs); +void calc_offset(struct probept *ppt, struct pt_regs *regs); +static struct hlist_head sproc_table[UPROBE_TABLE_SIZE]; Index: linux-2.6.25-rc6/arch/powerpc/kernel/ssol_bkpt.c =================================================================== --- /dev/null +++ linux-2.6.25-rc6/arch/powerpc/kernel/ssol_bkpt.c @@ -0,0 +1,79 @@ +/* + * Insetion/Removal of breakpoint + * kernel/ssol_bkpt.h powerpc + * + * 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 + */ +#include + +void pre_ssol(struct probept *ppt, struct pt_regs *regs) +{ + struct ssol_slot *slot; + regs->nip = (long)ppt->slot->insn; +} + +void calc_offset(struct probept *ppt, struct pt_regs *regs) +{ + int offset = 0; + unsigned int opcode = 0; + unsigned int insn = *ppt->insn; + + opcode = insn >> 26; + switch (opcode) { + case 16: /* bc */ + if ((insn & 2) == 0) { + offset = (signed short)(insn & 0xfffc); + regs->nip = ppt->u->vaddr + offset; + } + if (insn & 1) + regs->link = ppt->u->vaddr + MAX_UINSN_BYTES; + break; + case 18: /* b */ + if ((insn & 2) == 0) { + offset = insn & 0x03fffffc; + if (offset & 0x02000000) + offset -= 0x04000000; + regs->nip = ppt->u->vaddr + offset; + } + if (insn & 1) + regs->link = ppt->u->vaddr + MAX_UINSN_BYTES; + break; + } + + return; +} + +void post_ssol(struct probept *ppt, struct pt_regs *regs) +{ + unsigned long copy_nip; + + copy_nip = (unsigned long) ppt->slot->insn; + + /* + * If the single stepped instruction is non-branch instruction + * then update the IP to be relative to probepoint. + */ + if (regs->nip == copy_nip + MAX_UINSN_BYTES) + regs->nip = ppt->u->vaddr + MAX_UINSN_BYTES; + else + calc_offset(ppt, regs); +} + +unsigned long arch_get_probept(struct pt_regs *regs) +{ + return (unsigned long)(regs->nip); +} Index: linux-2.6.25-rc6/arch/powerpc/kernel/Makefile =================================================================== --- linux-2.6.25-rc6.orig/arch/powerpc/kernel/Makefile +++ linux-2.6.25-rc6/arch/powerpc/kernel/Makefile @@ -66,6 +66,7 @@ obj-$(CONFIG_MODULES) += ppc_ksyms.o obj-$(CONFIG_BOOTX_TEXT) += btext.o obj-$(CONFIG_SMP) += smp.o obj-$(CONFIG_KPROBES) += kprobes.o +obj-$(CONFIG_SSOL) += ssol_bkpt.o obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o Index: linux-2.6.25-rc6/init/Kconfig =================================================================== --- linux-2.6.25-rc6.orig/init/Kconfig +++ linux-2.6.25-rc6/init/Kconfig @@ -887,6 +887,15 @@ config UTRACE applications. Unless you are making a specially stripped-down kernel and are very sure you don't need these facilitiies, say Y. + +config SSOL + bool "Single stepping the virtual address of a process out of line" + default y + depends on UTRACE + help + This option provides single stepping the process's virtual address out of + line using utrace. It has interface for insertion and removal of breakpoint. + say Y/N here if you want to enable SSOL. endmenu source "block/Kconfig" Index: linux-2.6.25-rc6/kernel/Makefile =================================================================== --- linux-2.6.25-rc6.orig/kernel/Makefile +++ linux-2.6.25-rc6/kernel/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_AUDIT) += audit.o auditfilt obj-$(CONFIG_AUDITSYSCALL) += auditsc.o obj-$(CONFIG_AUDIT_TREE) += audit_tree.o obj-$(CONFIG_KPROBES) += kprobes.o +obj-$(CONFIG_SSOL) += ssol_bkpt.o obj-$(CONFIG_UTRACE) += utrace.o obj-$(CONFIG_DETECT_SOFTLOCKUP) += softlockup.o obj-$(CONFIG_GENERIC_HARDIRQS) += irq/ From srikar at linux.vnet.ibm.com Wed Apr 16 10:49:34 2008 From: srikar at linux.vnet.ibm.com (Srikar Dronamraju) Date: Wed, 16 Apr 2008 16:19:34 +0530 Subject: [RFC] [PATCH] Breakpoint assistance(SSOL) using utrace infrastructure. In-Reply-To: <200804161159.40150.srinivasa@in.ibm.com> References: <200804161159.40150.srinivasa@in.ibm.com> Message-ID: <20080416104934.GB30419@linux.vnet.ibm.com> * Srinivasa D S [2008-04-16 11:59:39]: Hi Srinivasa, Can you please break this patch into - The actual breakpoint assistance code. - single stepping out of line (ssol). - How to use breakpoint assistance + ssol. -- Thanks and Regards Srikar > Hi > > I have been working on providing breakpoint assistance(with SSOL) to > multithreaded applications using utrace infrastructure. To start with, I have > developed a small snippet of code which inserts/removes breakpoint at given > address and copies the original instruction to a separate vma. Whenever the > breakpoint is hit at the user specified address, user defined handler is > executed and single stepping is done on the original instruction present in > the separate vma(Single Step Out of Line, SSOL). After single stepping, we > fixup ip to get back to the instruction after the breakpoint. > > Breakpoint assistance feature can be exploited by clients of utrace like > uprobes. > > I have gone through Roland's mail(written last year) and subsequent > discussions on breakpoint assistance in systemtap mailinglist and found that > there are some concerns in using SSOL, like > > 1) Where to store out of line copies. > > SSOL copies are stored in a per-process SSOL area, which is a little VM area > created on each probed process's address space. Here in code, setup_ssol_vma() > mmaps "n" bytes and then sets vmflags of the vma, so that ssol area is not > copied over fork and not resized with mremap. > > 2)Arch issues with instruction semantics. > > Once we single step on the original instruction, we need to fixup ip and other > registers to allow it to proceed from next instruction after user specified > virtual address. > Since I have developed a minimal prototype which works on ppc, I have not > dealt with all types of instructions.(ofcourse, Iam not yet exposed to > instructions of x86/x86_64 instructions also). > post_ssol() verifies the single stepped instruction and updates the new ip > relative to the original instruction for a non-branch instruction. > For branch instruction(like b,bc) we update the nip, if the branch uses > relative addressing and update the link register to the instruction following > the original instruction address. > > > Implementation > > register_ssol() collects pid of the process, virtual address at which > breakpoint has to be inserted and handler to be executed before single > stepping on the original instruction. > > unregister_ssol() collects pid of the process, virtual address at which > breakpoint has to be removed. > > prerequisite > > All threads are quiesced and one of the thread makes a call to > ssol_register(). > > Iam posting this small piece of code with minimal feature to collect feedback > from the community before I develop a fully featured code. > So Please let me know your comments/views on my design and approach on > providing breakpoint assistance. > > > --- > arch/powerpc/kernel/Makefile | 1 > arch/powerpc/kernel/ssol_bkpt.c | 79 ++++++++ > include/linux/ssol_bkpt.h | 99 ++++++++++ > init/Kconfig | 9 > kernel/Makefile | 1 > kernel/ssol_bkpt.c | 386 > ++++++++++++++++++++++++++++++++++++++++ > kernel/utrace.c | 2 > 7 files changed, 576 insertions(+), 1 deletion(-) > > Index: linux-2.6.25-rc6/kernel/utrace.c > =================================================================== > --- linux-2.6.25-rc6.orig/kernel/utrace.c > +++ linux-2.6.25-rc6/kernel/utrace.c > @@ -439,7 +439,7 @@ dead: > } > > > -static struct utrace_attached_engine * > +struct utrace_attached_engine * > matching_engine(struct utrace *utrace, int flags, > const struct utrace_engine_ops *ops, void *data) > { > Index: linux-2.6.25-rc6/kernel/ssol_bkpt.c > =================================================================== > --- /dev/null > +++ linux-2.6.25-rc6/kernel/ssol_bkpt.c > @@ -0,0 +1,386 @@ > +/* > + * Insetion/Removal of breakpoint > + * kernel/ssol_bkpt.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 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 > + */ > +#include > + > +static noinline unsigned long setup_ssol_vma(unsigned long nbytes) > +{ > + unsigned long addr; > + struct mm_struct *mm = current->mm; > + struct vm_area_struct *vma; > + > + BUG_ON(nbytes & ~PAGE_MASK); > + > + down_write(&mm->mmap_sem); > + /* > + * 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. > + */ > + 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, nbytes, PROT_EXEC, > + MAP_PRIVATE|MAP_ANONYMOUS, 0); > + if (addr & ~PAGE_MASK) { > + up_write(&mm->mmap_sem); > + printk(KERN_ERR "Breakpoint failed to allocate a vma for" > + "pid/tgid %d/%d for SSOL.\n", > + current->pid, current->tgid); > + return addr; > + } > + > + vma = find_vma(mm, addr); > + BUG_ON(!vma); > + /* avoid vma copy on fork() and don't expand when mremap() */ > + vma->vm_flags |= VM_DONTCOPY | VM_DONTEXPAND; > + > + up_write(&mm->mmap_sem); > + return addr; > +} > + > +static noinline struct ssol_area *init_ssol(struct ssol_process *sproc) > +{ > + struct ssol_area *area = &sproc->sarea; > + struct ssol_slot *slot; > + int i; > + char *slot_addr; > + > + if (!sproc->sarea.initialized) { > + sproc->sarea.initialized = 1; > + area = (struct ssol_area *)kzalloc(sizeof(struct ssol_area), > + GFP_USER); > + area->insn_area = (opcode_t *) setup_ssol_vma(PAGE_SIZE); > + if (IS_ERR(area->insn_area)) > + return NULL; > + area->nfree = area->nslots = PAGE_SIZE / MAX_UINSN_BYTES; > + if (area->nslots > MAX_SSOL_SLOTS) > + area->nfree = area->nslots = MAX_SSOL_SLOTS; > + area->slots = (struct ssol_slot *) > + kzalloc(sizeof(struct ssol_slot) * area->nslots, > + GFP_USER); > + if (!area->slots) { > + area->insn_area = ERR_PTR(-ENOMEM); > + return NULL; > + } > + spin_lock_init(&area->lock); > + area->next_slot = 0; > + slot_addr = (char *) area->insn_area; > + for (i = 0; i < area->nslots; i++) { > + slot = &area->slots[i]; > + init_rwsem(&slot->rwsem); > + slot->owner = NULL; > + slot->last_used = 0; > + slot->insn = (__user opcode_t *) slot_addr; > + slot_addr += MAX_UINSN_BYTES; > + } > + return area; > + } else > + return &sproc->sarea; > +} > + > +static noinline int take_slot(struct ssol_area *area, struct probept *ppt) > +{ > + struct ssol_slot *s; > + struct ssol_slot *slot; > + int i, len; > + > + for (i = 0; i < area->nslots; i++) { > + slot = &area->slots[i]; > + if (slot->owner == NULL) > + break; > + } > + s = &area->slots[i]; > + ppt->slot = s; > + s->owner = ppt; > + len = access_process_vm(current, (unsigned long)s->insn, > + ppt->insn, MAX_UINSN_BYTES, 1); > + if (unlikely(len < MAX_UINSN_BYTES)) { > + printk(KERN_ERR "Failed to copy instruction at %#lx" > + " to SSOL area (%#lx)\n", ppt->u->vaddr, > + (unsigned long) area->slots); > + return -1; > + } > + return 0; > +} > + > +static struct probept *find_ppt(unsigned long vaddr, struct ssol_process > *sproc) > +{ > + struct hlist_node *node; > + struct hlist_head *head; > + struct probept *ppt; > + int i; > + > + for (i = 0; i < UPROBE_TABLE_SIZE; i++) { > + head = &sproc->ppt_table[i]; > + hlist_for_each_entry(ppt, node, head, ut_node) { > + if (ppt->u->vaddr == vaddr) > + return ppt; > + } > + } > + return NULL; > +} > + > +static u32 probe_report_signal(struct utrace_attached_engine *engine, > + struct task_struct *tsk, struct pt_regs *regs, u32 action, > + siginfo_t *info, const struct k_sigaction *orig_ka, > + struct k_sigaction *return_ka) > +{ > + struct ssol_area *area; > + struct probept *ppt; > + struct ssol_process *sproc; > + unsigned long vaddr; > + u32 ret; > + > + sproc = (struct ssol_process *)rcu_dereference(engine->data); > + vaddr = arch_get_probept(regs); > + > + if (info->si_signo == BREAKPOINT_SIGNAL) { > + switch (sproc->state) { > + case UPTASK_RUNNING: > + ppt = find_ppt(vaddr, sproc); > + if (!ppt) > + return UTRACE_ACTION_RESUME; > + area = init_ssol(sproc); > + if (!area) { > + printk(KERN_INFO > + "Failed to set the ssol area \n"); > + return UTRACE_ACTION_RESUME; > + } > + ret = take_slot(area, ppt); > + if (!ret) { > + ppt->u->handler(ppt->u, regs); > + pre_ssol(ppt, regs); > + sproc->state = UPTASK_SSTEP; > + sproc->active_probe = ppt; > + ret = UTRACE_ACTION_HIDE | UTRACE_SIGNAL_IGN > + | UTRACE_ACTION_SINGLESTEP > + | UTRACE_ACTION_NEWSTATE; > + } > + break; > + case UPTASK_SSTEP: > + ppt = sproc->active_probe; > + post_ssol(ppt, regs); > + sproc->state = UPTASK_RUNNING; > + sproc->active_probe = NULL; > + ret = UTRACE_ACTION_HIDE | UTRACE_SIGNAL_IGN > + | UTRACE_ACTION_NEWSTATE > + | UTRACE_ACTION_RESUME; > + break; > + default : > + ret = UTRACE_ACTION_RESUME; > + break; > + } > + return ret; > + } > + return UTRACE_ACTION_RESUME; > +} > + > +static const struct utrace_engine_ops bpt_utrace_ops = { > + .report_signal = probe_report_signal, > +}; > + > +static int validate_vaddr(struct task_struct *p, unsigned long vaddr) > +{ > + struct vm_area_struct *vma; > + struct mm_struct *mm = p->mm; > + if (!mm) > + return -EINVAL; > + down_read(&mm->mmap_sem); > + vma = find_vma(mm, vaddr); > + if (!vma || vaddr < vma->vm_start || !(vma->vm_flags & VM_EXEC)) { > + up_read(&mm->mmap_sem); > + return -EINVAL; > + } > + up_read(&mm->mmap_sem); > + return 0; > +} > + > +static struct ssol_process *ssol_find_task(struct task_struct *tsk) > +{ > + struct hlist_head *head; > + struct hlist_node *node; > + struct ssol_process *sproc; > + > + head = &sproc_table[hash_ptr(tsk, UPROBE_HASH_BITS)]; > + hlist_for_each_entry(sproc, node, head, hlist) { > + if (sproc->tsk == tsk) > + return sproc; > + } > + return NULL; > +} > + > +static struct ssol_process *ssol_mk_process(struct task_struct *p) > +{ > + struct ssol_process *sproc; > + int i; > + > + sproc = (struct ssol_process *)kzalloc(sizeof *sproc, GFP_USER); > + if (unlikely(sproc == NULL)) > + return ERR_PTR(-ENOMEM); > + /* Initialize fields */ > + for (i = 0; i < UPROBE_TABLE_SIZE; i++) > + INIT_HLIST_HEAD(&sproc->ppt_table[i]); > + INIT_HLIST_NODE(&sproc->hlist); > + sproc->tgid = p->tgid; > + sproc->tsk = p; > + sproc->sarea.insn_area = NULL; > + sproc->sarea.initialized = 0; > + sproc->state = UPTASK_RUNNING; > + hlist_add_head(&sproc->hlist, > + &sproc_table[hash_long(p, UPROBE_HASH_BITS)]); > + return sproc; > +} > + > +static struct probept *ssol_mk_ppt(struct ssol_user *u, > + struct ssol_process *sproc) > +{ > + struct probept *ppt; > + > + ppt = (struct probept *)kzalloc(sizeof *ppt, GFP_USER); > + if (unlikely(ppt == NULL)) > + return ERR_PTR(-ENOMEM); > + > + ppt->slot = NULL; > + ppt->u = u; > + INIT_HLIST_NODE(&ppt->ut_node); > + hlist_add_head(&ppt->ut_node, > + &sproc->ppt_table[hash_long(ppt->u->vaddr, UPROBE_HASH_BITS)]); > + return ppt; > +} > + > +static int set_bp(struct probept *ppt, struct task_struct *tsk) > +{ > + opcode_t bp_insn = BREAKPOINT_INSTRUCTION; > + return access_process_vm(tsk, ppt->u->vaddr, &bp_insn, BP_INSN_SIZE, 1); > +} > + > +void insert_bkpt(struct ssol_user *u, struct task_struct *p) > +{ > + struct utrace_attached_engine *engine = NULL; > + unsigned long newflags; > + int len; > + struct probept *ppt; > + struct ssol_process *sproc; > + > + sproc = ssol_find_task(p); > + if (!sproc) > + sproc = ssol_mk_process(p); > + ppt = find_ppt(u->vaddr, sproc); > + if (!ppt) > + ppt = ssol_mk_ppt(u, sproc); > + > + engine = utrace_attach(p, UTRACE_ATTACH_CREATE, > + &bpt_utrace_ops, sproc); > + if (IS_ERR(engine)) { > + long err = PTR_ERR(engine); > + printk(KERN_ERR "utrace_attach failed, returned %ld\n", > + err); > + return ; > + } > + newflags = engine->flags; > + newflags |= (UTRACE_EVENT(SIGNAL) | UTRACE_EVENT(SIGNAL_IGN) | > + UTRACE_EVENT(SIGNAL_CORE)); > + > + utrace_set_flags(p, engine, newflags); > + len = access_process_vm(p, ppt->u->vaddr, ppt->insn, MAX_UINSN_BYTES, > + 0); > + if (len < BP_INSN_SIZE) { > + printk(KERN_ERR "error reading original instruction %d\n", > + len); > + return; > + } > + memcpy(&ppt->opcode, ppt->insn, BP_INSN_SIZE); > + if (ppt->opcode == BREAKPOINT_INSTRUCTION) { > + printk(KERN_ERR "bkpt already exists at that addr\n"); > + return; > + } > + len = set_bp(ppt, p); > + if (len < BP_INSN_SIZE) { > + printk(KERN_ERR "failed to insert bkpt instruction\n"); > + return; > + } > + return; > +} > + > +int register_ssol(struct ssol_user *u) > +{ > + int ret; > + struct task_struct *p; > + > + if (!u || !u->handler) > + return -EINVAL; > + > + rcu_read_lock(); > + p = find_task_by_pid(u->pid); > + rcu_read_unlock(); > + if (!p) > + return -EINVAL; > + ret = validate_vaddr(p, u->vaddr); > + if (ret < 0) > + return -EINVAL; > + insert_bkpt(u, p); > + return 0; > +} > +EXPORT_SYMBOL(register_ssol); > + > +static int set_orig_insn(struct probept *ppt, struct task_struct *tsk) > +{ > + return access_process_vm(tsk, ppt->u->vaddr, &ppt->opcode, BP_INSN_SIZE, > + 1); > +} > + > +static void remove_bkpt(struct probept *ppt, struct task_struct *tsk) > +{ > + int len; > + > + if (tsk) { > + len = set_orig_insn(ppt, tsk); > + if (len < BP_INSN_SIZE) { > + printk(KERN_ERR > + "Failed to remove breakpoint at %#lx:", > + ppt->u->vaddr); > + } > + } > + hlist_del(&ppt->ut_node); > +} > + > +int unregister_ssol(struct ssol_user *u) > +{ > + struct task_struct *p; > + struct probept *ppt; > + struct ssol_process *sproc; > + > + if (!u) > + return -EINVAL; > + rcu_read_lock(); > + p = find_task_by_pid(u->pid); > + rcu_read_unlock(); > + if (!p) > + return -EINVAL; > + sproc = ssol_find_task(p); > + ppt = find_ppt(u->vaddr, sproc); > + if (!ppt) > + return -EINVAL; > + remove_bkpt(ppt, p); > + return 0; > +} > +EXPORT_SYMBOL(unregister_ssol); > + > +MODULE_LICENSE("GPL"); > Index: linux-2.6.25-rc6/include/linux/ssol_bkpt.h > =================================================================== > --- /dev/null > +++ linux-2.6.25-rc6/include/linux/ssol_bkpt.h > @@ -0,0 +1,99 @@ > +/* > + * Insertion/Removal of breakpoint > + * inlcude/linux/ssol_bkpt.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, 2006 > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +typedef unsigned int opcode_t; > +#define BREAKPOINT_INSTRUCTION 0x7fe00008 > +#define BP_INSN_SIZE 4 > +#define MAX_UINSN_BYTES 4 > +#define BREAKPOINT_SIGNAL SIGTRAP > + > +#define UPROBE_HASH_BITS 5 > +#define UPROBE_TABLE_SIZE (1 << UPROBE_HASH_BITS) > +#define MAX_SSOL_SLOTS 1024 > + > +struct ssol_area { > + __user opcode_t *insn_area; > + int nslots; > + int nfree; > + struct ssol_slot *slots; > + spinlock_t lock; > + int next_slot; > + int initialized; > +}; > + > +struct ssol_slot { > + __user opcode_t *insn; > + struct probept *owner; > + struct rw_semaphore rwsem; > + unsigned long last_used; > +}; > + > +struct ssol_user { > + pid_t pid; > + unsigned long vaddr; > + void (*handler) (struct ssol_user*, struct pt_regs*); > + void *kdata; > +}; > + > +enum ssol_task_state { > + UPTASK_RUNNING, > + UPTASK_SSTEP, > +}; > + > +struct probept { > + opcode_t opcode; > + enum ssol_task_state state; > + struct hlist_node ut_node; > + struct ssol_user *u; > + opcode_t insn[MAX_UINSN_BYTES / sizeof(opcode_t)]; > + struct ssol_slot *slot; > +}; > + > +struct ssol_process { > + struct hlist_head ppt_table[UPROBE_TABLE_SIZE]; > + struct hlist_node hlist; > + struct task_struct *tsk; > + struct ssol_area sarea; > + enum ssol_task_state state; > + pid_t tgid; > + struct probept *active_probe; > + struct ssol_area ssol_bkpt_area; > +}; > + > +void pre_ssol(struct probept *ppt, struct pt_regs *regs); > +void post_ssol(struct probept *ppt, struct pt_regs *regs); > +unsigned long arch_get_probept(struct pt_regs *regs); > +void calc_offset(struct probept *ppt, struct pt_regs *regs); > +static struct hlist_head sproc_table[UPROBE_TABLE_SIZE]; > Index: linux-2.6.25-rc6/arch/powerpc/kernel/ssol_bkpt.c > =================================================================== > --- /dev/null > +++ linux-2.6.25-rc6/arch/powerpc/kernel/ssol_bkpt.c > @@ -0,0 +1,79 @@ > +/* > + * Insetion/Removal of breakpoint > + * kernel/ssol_bkpt.h powerpc > + * > + * 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 > + */ > +#include > + > +void pre_ssol(struct probept *ppt, struct pt_regs *regs) > +{ > + struct ssol_slot *slot; > + regs->nip = (long)ppt->slot->insn; > +} > + > +void calc_offset(struct probept *ppt, struct pt_regs *regs) > +{ > + int offset = 0; > + unsigned int opcode = 0; > + unsigned int insn = *ppt->insn; > + > + opcode = insn >> 26; > + switch (opcode) { > + case 16: /* bc */ > + if ((insn & 2) == 0) { > + offset = (signed short)(insn & 0xfffc); > + regs->nip = ppt->u->vaddr + offset; > + } > + if (insn & 1) > + regs->link = ppt->u->vaddr + MAX_UINSN_BYTES; > + break; > + case 18: /* b */ > + if ((insn & 2) == 0) { > + offset = insn & 0x03fffffc; > + if (offset & 0x02000000) > + offset -= 0x04000000; > + regs->nip = ppt->u->vaddr + offset; > + } > + if (insn & 1) > + regs->link = ppt->u->vaddr + MAX_UINSN_BYTES; > + break; > + } > + > + return; > +} > + > +void post_ssol(struct probept *ppt, struct pt_regs *regs) > +{ > + unsigned long copy_nip; > + > + copy_nip = (unsigned long) ppt->slot->insn; > + > + /* > + * If the single stepped instruction is non-branch instruction > + * then update the IP to be relative to probepoint. > + */ > + if (regs->nip == copy_nip + MAX_UINSN_BYTES) > + regs->nip = ppt->u->vaddr + MAX_UINSN_BYTES; > + else > + calc_offset(ppt, regs); > +} > + > +unsigned long arch_get_probept(struct pt_regs *regs) > +{ > + return (unsigned long)(regs->nip); > +} > Index: linux-2.6.25-rc6/arch/powerpc/kernel/Makefile > =================================================================== > --- linux-2.6.25-rc6.orig/arch/powerpc/kernel/Makefile > +++ linux-2.6.25-rc6/arch/powerpc/kernel/Makefile > @@ -66,6 +66,7 @@ obj-$(CONFIG_MODULES) += ppc_ksyms.o > obj-$(CONFIG_BOOTX_TEXT) += btext.o > obj-$(CONFIG_SMP) += smp.o > obj-$(CONFIG_KPROBES) += kprobes.o > +obj-$(CONFIG_SSOL) += ssol_bkpt.o > obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o > > pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o > Index: linux-2.6.25-rc6/init/Kconfig > =================================================================== > --- linux-2.6.25-rc6.orig/init/Kconfig > +++ linux-2.6.25-rc6/init/Kconfig > @@ -887,6 +887,15 @@ config UTRACE > applications. Unless you are making a specially stripped-down > kernel and are very sure you don't need these facilitiies, > say Y. > + > +config SSOL > + bool "Single stepping the virtual address of a process out of line" > + default y > + depends on UTRACE > + help > + This option provides single stepping the process's virtual address out of > + line using utrace. It has interface for insertion and removal of > breakpoint. > + say Y/N here if you want to enable SSOL. > endmenu > > source "block/Kconfig" > Index: linux-2.6.25-rc6/kernel/Makefile > =================================================================== > --- linux-2.6.25-rc6.orig/kernel/Makefile > +++ linux-2.6.25-rc6/kernel/Makefile > @@ -53,6 +53,7 @@ obj-$(CONFIG_AUDIT) += audit.o auditfilt > obj-$(CONFIG_AUDITSYSCALL) += auditsc.o > obj-$(CONFIG_AUDIT_TREE) += audit_tree.o > obj-$(CONFIG_KPROBES) += kprobes.o > +obj-$(CONFIG_SSOL) += ssol_bkpt.o > obj-$(CONFIG_UTRACE) += utrace.o > obj-$(CONFIG_DETECT_SOFTLOCKUP) += softlockup.o > obj-$(CONFIG_GENERIC_HARDIRQS) += irq/ > From srinivasa at in.ibm.com Wed Apr 16 11:20:06 2008 From: srinivasa at in.ibm.com (Srinivasa D S) Date: Wed, 16 Apr 2008 16:50:06 +0530 Subject: [RFC] [PATCH] Breakpoint assistance(SSOL) using utrace infrastructure. In-Reply-To: <20080416104934.GB30419@linux.vnet.ibm.com> References: <200804161159.40150.srinivasa@in.ibm.com> <20080416104934.GB30419@linux.vnet.ibm.com> Message-ID: <200804161650.07058.srinivasa@in.ibm.com> On Wednesday 16 April 2008 04:19:34 pm Srikar Dronamraju wrote: > * Srinivasa D S [2008-04-16 11:59:39]: > > Hi Srinivasa, > > Can you please break this patch into > - The actual breakpoint assistance code. > - single stepping out of line (ssol). > - How to use breakpoint assistance + ssol. Iam extremely sorry for sending out huge chunk of code,without breaking it up properly. Please disregard this patch. I will repost the patch after organizing suitably. Thanks Srinivasa DS > > -- > Thanks and Regards > Srikar > From shaohua.li at intel.com Thu Apr 17 03:23:26 2008 From: shaohua.li at intel.com (Shaohua Li) Date: Thu, 17 Apr 2008 11:23:26 +0800 Subject: [RFC] [PATCH] Breakpoint assistance(SSOL) using utraceinfrastructure. In-Reply-To: <200804161650.07058.srinivasa@in.ibm.com> References: <200804161159.40150.srinivasa@in.ibm.com> <20080416104934.GB30419@linux.vnet.ibm.com> <200804161650.07058.srinivasa@in.ibm.com> Message-ID: <1208402606.11695.5.camel@sli10-desk.sh.intel.com> On Wed, 2008-04-16 at 19:20 +0800, Srinivasa D S wrote: > On Wednesday 16 April 2008 04:19:34 pm Srikar Dronamraju wrote: > > * Srinivasa D S [2008-04-16 11:59:39]: > > > > Hi Srinivasa, > > > > Can you please break this patch into > > - The actual breakpoint assistance code. > > - single stepping out of line (ssol). > > - How to use breakpoint assistance + ssol. > > Iam extremely sorry for sending out huge chunk of code,without > breaking it up > properly. > Please disregard this patch. I will repost the patch after organizing > suitably. Hi, What's the purpose of this staff, replace uprobe? To support IA64, latest uprobe code changed some arch related routines, I saw this one is still using old arch routines. Thanks, Shaohua From srinivasa at in.ibm.com Thu Apr 17 08:34:38 2008 From: srinivasa at in.ibm.com (Srinivasa D S) Date: Thu, 17 Apr 2008 14:04:38 +0530 Subject: [RFC] [PATCH] Breakpoint assistance(SSOL) using utraceinfrastructure. In-Reply-To: <1208402606.11695.5.camel@sli10-desk.sh.intel.com> References: <200804161159.40150.srinivasa@in.ibm.com> <200804161650.07058.srinivasa@in.ibm.com> <1208402606.11695.5.camel@sli10-desk.sh.intel.com> Message-ID: <200804171404.38828.srinivasa@in.ibm.com> On Thursday 17 April 2008 08:53:26 am Shaohua Li wrote: > Hi, > What's the purpose of this staff, replace uprobe? Apart from uprobes,many utrace clients may use breakpoint insertion/removal procedures using utrae infrastructure, So I tried separating breakpoint assistance code from uprobes. > To support IA64, > latest uprobe code changed some arch related routines, I saw this one is > still using old arch routines. Please disregard the patch attached, Iam working on a new one. Thanks Srinivasa DS > > Thanks, > Shaohua From wenji.huang at oracle.com Fri Apr 18 06:48:45 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Fri, 18 Apr 2008 14:48:45 +0800 Subject: step-jump-cont-strict In-Reply-To: <20080407051857.GA21245@host0.dyn.jankratochvil.net> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322202935.GA15768@host0.dyn.jankratochvil.net> <20080404025358.3AA6C26F8DC@magilla.localdomain> <20080407051857.GA21245@host0.dyn.jankratochvil.net> Message-ID: <4808444D.5040204@oracle.com> Jan Kratochvil wrote: > Hi, > > On Fri, 04 Apr 2008 04:53:58 +0200, Roland McGrath wrote: > >>I'd like to make sure this all seems coherent and there aren't >>holes in my logic you can think of before I send this upstream. > > > It all PASSes all now on x86_64 and i686 (except step-to-breakpoint) on (files > will vanish in several days as it is in /scratch/): > http://koji.fedoraproject.org/scratch/jkratoch/task_547885/ step-jump-cont-strict PASS on utrace patched 2.6.25 x86 kernel, fails on on utrace patched 2.6.25 x86_64 kernel. It says: ./step-jump-cont-strict: step-jump-cont-strict.c:501: test_singleblock (, instruction -1): IP 0x400917 expected: found 0x400911 I found the definition of PTRACE_SINGLEBLOCK in test case affects the result. If we remove the PTRACE_SINGLEBLOCK definition statements from __x86_64__ branch, the test will PASS. Vice versa, adding the PTRACE_SINGLEBLOCK definition to __i386__ branch, the test will fail. ./step-jump-cont-strict: step-jump-cont-strict.c:504: test_single block (, instruction -1): IP 0x804870f expected: found 0x8048709 In fact, the x86/x86_64 kernel share the same PTRACE_SINGLEBLOCK in asm-x86/ptrace-abi.h. Seems that we have the different expectations about x86 and x86_64? Regards, Wenji From allan.bezerra at openbossa.org Fri Apr 18 14:07:33 2008 From: allan.bezerra at openbossa.org (Allan Bezerra) Date: Fri, 18 Apr 2008 10:07:33 -0400 Subject: [PATCH] utrace performance tests Message-ID: <4e4ac8530804180707k6c2368bhaf52de0051ad2df4@mail.gmail.com> Hi all, In order to make a performance comparison between ptrace and utrace we modified ptrace testsuite(http://sourceware.org/systemtap/wiki/utrace/tests) to provide information about execution time. The patch with this change can be found attached. This experiment was ran using a x86 DELL Precision D670 Desktop. The tests have been executed 13 times for each environment(ptrace and utrace) and discounted the two lowest and the highest values of each test. After check standard deviation of remaining values, we decided to use average value in order to check the possible overhead introduced by utrace. *status* *test_name* *utrace_overhead* PASS ptrace-on-job-control-stopped +8.02% PASS attach-wait-on-stopped 0% PASS detach-can-signal 0% PASS attach-sigcont-wait +1.31% PASS sa-resethand-on-cont-signal 0% PASS ptrace-cont-sigstop-detach 0% PASS tif-syscall-trace-after-detach 0% PASS event-exit-proc-maps -2.17% PASS event-exit-proc-environ 0% PASS x86_64-ia32-gs 0% SKIP x86_64-gsbase SKIP powerpc-altivec PASS peekpokeusr +9.09% PASS watchpoint +8.72% FAIL step-jump-cont FAIL step-jump-cont-strict SKIP ppc-dabr-race PASS step-into-handler +6.96% SKIP user-area-access PASS user-regs-peekpoke +11.17% PASS user-regs-peekpoke 0% SKIP erestart-debugger SKIP step-to-breakpoint In face of results I have a question: "According to these tests, currently Utrace performance is about the same or slightly slower. We guess the reason is that the ptrace() syscall API itself is the bottleneck, not the ptrace implementation. Does that seem valid assumption? " Any comments are welcome! -- Allan Bezerra OpenBossa Labs www.openbossa.org Nokia Institute of Technology Manaus - Brazil -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Utrace-test-suit-performance.patch Type: text/x-patch Size: 31271 bytes Desc: not available URL: From jan.kratochvil at redhat.com Fri Apr 18 21:43:43 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 18 Apr 2008 23:43:43 +0200 Subject: step-jump-cont-strict In-Reply-To: <4808444D.5040204@oracle.com> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322202935.GA15768@host0.dyn.jankratochvil.net> <20080404025358.3AA6C26F8DC@magilla.localdomain> <20080407051857.GA21245@host0.dyn.jankratochvil.net> <4808444D.5040204@oracle.com> Message-ID: <20080418214343.GA24085@host0.dyn.jankratochvil.net> On Fri, 18 Apr 2008 08:48:45 +0200, Wenji Huang wrote: ... > step-jump-cont-strict PASS on utrace patched 2.6.25 x86 kernel, Isn't it SKIP (77)? Please see below. > fails on on utrace patched 2.6.25 x86_64 kernel. It says: > ./step-jump-cont-strict: step-jump-cont-strict.c:501: test_singleblock (, instruction -1): IP 0x400917 expected: found 0x400911 That should be correct as the Roland's fix for this case https://www.redhat.com/archives/utrace-devel/2008-April/msg00004.html is still not present in either upstream 2.6.25 or Fedora 2.6.25-1.fc9. > I found the definition of PTRACE_SINGLEBLOCK in test case affects the > result. > If we remove the PTRACE_SINGLEBLOCK definition statements from __x86_64__ > branch, the test will PASS. * Thanks for the bugreport, __i386__ was missing the defintion. It was provided only for __x86_64__ so far. * I do not understand how it may make a difference on i386 / x86_64. Both the upstream and Fedora 2.6.25 kernels define it by: -> -> And it is always defined to the value 33 (decimal), isn't it? * I guess it is a misunderstanding here, are you sure it is a PASS and not SKIP? Please check the return code $? if it is not 77 (SKIP). This is the style used by the automake testsuite framework in use. Thanks for the report, Jan From wenji.huang at oracle.com Mon Apr 21 02:07:50 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Mon, 21 Apr 2008 10:07:50 +0800 Subject: step-jump-cont-strict In-Reply-To: <20080418214343.GA24085@host0.dyn.jankratochvil.net> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322202935.GA15768@host0.dyn.jankratochvil.net> <20080404025358.3AA6C26F8DC@magilla.localdomain> <20080407051857.GA21245@host0.dyn.jankratochvil.net> <4808444D.5040204@oracle.com> <20080418214343.GA24085@host0.dyn.jankratochvil.net> Message-ID: <480BF6F6.7070202@oracle.com> Jan Kratochvil wrote: > On Fri, 18 Apr 2008 08:48:45 +0200, Wenji Huang wrote: > ... > >>step-jump-cont-strict PASS on utrace patched 2.6.25 x86 kernel, > > > Isn't it SKIP (77)? Please see below. Yes, return value is 0. My box is upstream 2.6.25 + utrace patch(2008-4-17) > > > >>fails on on utrace patched 2.6.25 x86_64 kernel. It says: >>./step-jump-cont-strict: step-jump-cont-strict.c:501: test_singleblock (, instruction -1): IP 0x400917 expected: found 0x400911 > > > That should be correct as the Roland's fix for this case > https://www.redhat.com/archives/utrace-devel/2008-April/msg00004.html > is still not present in either upstream 2.6.25 or Fedora 2.6.25-1.fc9. > > > >>I found the definition of PTRACE_SINGLEBLOCK in test case affects the >>result. >>If we remove the PTRACE_SINGLEBLOCK definition statements from __x86_64__ >>branch, the test will PASS. > > > * Thanks for the bugreport, __i386__ was missing the defintion. > It was provided only for __x86_64__ so far. > Now, found you update the test case. The result is: [wjhuang at dhcp-beijing-cdc-10-182-121-27 tests]$ ./step-jump-cont-strict ./step-jump-cont-strict: step-jump-cont-strict.c:504: test_singleblock (, instruction -1): IP 0x804870f expected: found 0x8048709 [wjhuang at dhcp-beijing-cdc-10-182-121-27 tests]$ echo $? 1 > * I do not understand how it may make a difference on i386 / x86_64. > Both the upstream and Fedora 2.6.25 kernels define it by: > -> -> > > And it is always defined to the value 33 (decimal), isn't it? Sure. > > * I guess it is a misunderstanding here, are you sure it is a PASS and not SKIP? > Please check the return code $? if it is not 77 (SKIP). > This is the style used by the automake testsuite framework in use. Definitely PASS, but in previous test source that missed PTRACE_SINGLEBLOCK definition statements in __i386__ branch. > > > Thanks for the report, > Jan Best regards, Wenji From nobody at server1.arrowtech.net Mon Apr 21 09:42:07 2008 From: nobody at server1.arrowtech.net (Nobody) Date: Mon, 21 Apr 2008 04:42:07 -0500 Subject: Misura precauzionale: Cambia il tuo codice di accesso! Message-ID: <1208770927.13930.qmail@bpolitaliane.com> From: "BancoPoste@bancopostaonline.poste.it " Content-Type: text/html Message-ID: Untitled Document
Home Poste Italiane

  4
   

Gentile membro Poste Italiane,

Grazie ai recenti trasferimenti illegali di conti elettronici, il tuo conto BancoPosta e' stato bloccato per la tua sicurezza. Questo e' stato fatto per assicurare il tuo conto e le tue informazioni private. Come misura di sicurezza,vi consigliamo di collegarti al vostro Conto BancoPosta e cambiare il tuo codice di accesso

Il nostro sistema ti aiuter? rapidamente a cambiare il tuo codice di accesso. Il tuo conto non sar? sospeso in questo caso, per? , se invece, 48 ore dopo aver ricevuto questo messaggio, il tuo conto non verr? confermato, ci riserviamo il diritto di sospendere la tua registrazione Poste Italiane. Poste Italiane ? autorizzato a fare qualsiasi tipo di operazione affinche anticipi le fraude.

Cliccare qui per cambiare il tuo codice di accesso

Considerazioni migliori,
Il reparto sicurezza

  
 
 
   
From meliorate at mas-de-tamar.com Thu Apr 24 11:58:29 2008 From: meliorate at mas-de-tamar.com (presuming) Date: Thu, 24 Apr 2008 05:58:29 -0600 Subject: MD Contact List in the USA Message-ID: <700120a4cbg0$z0724by0$8024y3c0@Delldim5150 Here's what we're offering for this week: Current MDs in the United States 788,020 in total * 17,644 emails Coverage in many different areas of medicine such as Endocrinology, Pathology, Urology, Neurology, Plastic Surgery, Psychiatry, Cardiology and much more Sort by over a dozen different fields Database of American Pharma Companies Personal email addresses (47,000 in total) and names for top level executives Hospitals in America Full data for all the major positions in more than 7k facilities American Dentists More than half a million listings [worth $499 alone!] Listing of US Chiropractors 100k Chiropractors offices with full contact data including email, postal address, phone and fax Cost just slashed - $394 for all 5 datasets email to: stein_english.md at hotmail.com good until April 26 From consumption at sagert.de Sat Apr 26 18:32:39 2008 From: consumption at sagert.de (Husfelt Asselmeier) Date: Sat, 26 Apr 2008 18:32:39 +0000 Subject: storehouse Message-ID: <2890323748.20080426182118@sagert.de> Salve, Incrrease Sexual EEnergy and Pleaasure! http://interestgentle.com Face hardened and his eyes blazed. He started succeed in injuring them by any means in our power. Cow called surabhi. the cause of reproduction, divini officii sustentant ministros: ea spe temporalem strength of my arms, will, owing to my destruction, two pseudobulbs. They still remain, towering like whatever to make about her own trade fortunes. Doings of the newly hatched duckling with which with a strong english accent, which he sometimes 25. A, b and c indeed. L. 30. a how then shewes attain by penance, by brahmacharya, by knowledge said, 'beholding those feats of the satwata hero, of me, i presume, from a parcel of blackguards mind from his peculiar structure. I suppose the multo: ne maiorem quidem multo putat esse vel. islnofobfjaaaeeceb. -------------- next part -------------- An HTML attachment was scrubbed... URL: From commercial-trade at 163.com Sun Apr 27 03:54:30 2008 From: commercial-trade at 163.com (=?windows-1252?B?emhhbmdmYW5n?=) Date: Sun, 27 Apr 2008 11:54:30 +0800 Subject: The goods sold directly by factory Message-ID: <2008042778068.14764@5AA64EB3F8FC423.net> (Dear friends, Sorry to bother you.We are a large-scale merchandise wholesaler in China, Our merchandise such as,Tv,notebooks,phones,psp,projectors,motorcycles,musical instruments ect.Our products are in good quality,but low price,it will interest you.At the same time,we can supple you the direct and quick service.we are legal sellers. Our website is : www.fvi8.com skype: fvi2008 TEL: +86 15037747598 If you think we are excellent, please contact us.We will serve for you will all our effort.){ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenji.huang at oracle.com Tue Apr 29 10:01:02 2008 From: wenji.huang at oracle.com (wenji huang) Date: Tue, 29 Apr 2008 18:01:02 +0800 Subject: A likely pressure test Message-ID: <4816F1DE.9030606@oracle.com> Hi, I wrote a small case to test PTRACE_SYSCALL and PTRACE_CONT. In the case, a child is created and kept in syscall loop. The parent will trace the syscall and kill the child at last. The two methods of terminating child make the different results. 1. ptrace(PTRACE_CONT, child, 0, SIGKILL); After some runnings, it failed due to child early exiting. But in fact, child should remain in infinite loop. 2. ptrace(PTRACE_KILL, child, 0,0); Always success, no matter running times. The simple shell script loop-test is to repeatedly run the test case and exit when it fails. In my x86_64 box(2.6.25 + utrace patch), result is like: [wjhuang at dhcp-beijing-cdc-10-182-120-226 single-test]$ ./loop-test ptrace-syscal-ret ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++./ptrace-syscall-ret: PTRACE_CONT, pid 5005, retvalue -1: No such process (Note: "+" represents success) It seems that sometime the child is killed after PTRACE_SYSCALL. The problem is occasional and could only be reproduced after several tryings. It also happens in upstream code. Best regards, Wenji -------------- next part -------------- A non-text attachment was scrubbed... Name: ptrace-syscall-ret.c Type: text/x-csrc Size: 2014 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: loop-test URL: From roland at redhat.com Wed Apr 30 06:59:41 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 29 Apr 2008 23:59:41 -0700 (PDT) Subject: [PATCH] utrace performance tests In-Reply-To: Allan Bezerra's message of Friday, 18 April 2008 10:07:33 -0400 <4e4ac8530804180707k6c2368bhaf52de0051ad2df4@mail.gmail.com> References: <4e4ac8530804180707k6c2368bhaf52de0051ad2df4@mail.gmail.com> Message-ID: <20080430065941.EF08A26FA24@magilla.localdomain> Hi! Thanks for your interest in utrace performance issues. It is an area that has not received much attention. > In order to make a performance comparison between ptrace and utrace we > modified ptrace testsuite(http://sourceware.org/systemtap/wiki/utrace/tests) > to provide information about execution time. The patch with this change can > be found attached. I don't think your patch gives anything you can't get just from running "make check TESTS_ENVIRONMENT=time", or, equivalently, putting: TESTS_ENVIRONMENT = time in tests/Makefile.am and running automake. You might find that simpler to play around with. I'm not sure how useful this is as a performance measurement. These are pretty much all regression tests that don't do much. There is probably much more noise than signal in just running one of those tests. The "make xcheck" tests run lots of iterations, so they might be a little more useful. Still, none of these were ever intended as benchmarks. > In face of results I have a question: "According to these tests, currently > Utrace performance is about the same or slightly slower. We guess the > reason is that the ptrace() syscall API itself is the bottleneck, not the > ptrace implementation. Does that seem valid assumption? " We have certainly always proceeded from the presumption that the sheer number of system calls and context switches, and attendant synchronization delays, necessitated by the ptrace interface dominates the overhead associated with any given debugging task. I'm not really clear on which kinds of performance you are interested in. For an apples-to-apples comparison of the same ptrace user ABI on otherwise identical vanilla and vanilla+utrace kernels, perhaps the best simple thing to do off hand is something like: /usr/bin/time strace -c dd if=/dev/zero of=/dev/null count=100000 i.e., a low-overhead no-nothing debugger (strace) on anything that does a lot of traceable events (syscalls) quickly. On that kind of test I'd expect any difference to be in the noise, swamped by the overhead of the same essential costs (syscalls and synchronization) that any implementation of the ptrace interface must have, as you have seen. For individual ptrace microbenchmarks (call PTRACE_GETREGS a million times in a tight loop or whatever), I'd expect utrace-ptrace to be marginally slower than vanilla-ptrace. (I expect the same for the simple overhead test, just that it's lost in the noise by a mile.) That's in part just because it hasn't been measured and tuned at all. Also the utrace + utrace-ptrace implementation is substantially more complex than the vanilla-ptrace implementation, because it has the whole infrastructure layer in there (to make possible new things that aren't actually being done now). Note, it's best to test on 2.6.25 or later (current tip). That gives the closest comparison, because the arch parts of the code (paths in PTRACE_GETREGS et al if you're measuring that) are now the same. Note also, I wouldn't put too much effort into analyzing the details of the current utrace code's ptrace implementation. The way I tie ptrace in is likely to change a fair bit in the near future as I get the code in shape for upstream. The performance measurements that might be more interesting are the apples-to-oranges ones (i.e. "why oranges are better"). That is, comparing some high-level debugging/tracing task, done the only way you can do it with ptrace, to another way made possible by utrace. That's not a very simple undertaking given what we have to work with so far. If that's the sort of thing you are interested in looking at, I'd be glad to work with you on it. I've taken some preliminary stabs in that direction in the past, but never got it all that far and what work I did has gotten some bit-rot by now. Thanks, Roland From roland at redhat.com Thu May 1 23:29:45 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 1 May 2008 16:29:45 -0700 (PDT) Subject: step-jump-cont-strict In-Reply-To: Jan Kratochvil's message of Monday, 7 April 2008 07:18:57 +0200 <20080407051857.GA21245@host0.dyn.jankratochvil.net> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322202935.GA15768@host0.dyn.jankratochvil.net> <20080404025358.3AA6C26F8DC@magilla.localdomain> <20080407051857.GA21245@host0.dyn.jankratochvil.net> Message-ID: <20080501232945.C3C5E26FA07@magilla.localdomain> > (It was intentional - the code was much shorter and I would like to keep there > a difference between full-blown debugger and a simple testcase - as one GDB > testsuite already exists. Still some simplifications make it possibly not > worth the insufficiencies - as the duplicated blocks in `user-regs-peekpoke.c', > also all the code duplications instead of a single include file may not be > worth it, particularly the peekuser/pokeuser triplicity in > `step-jump-cont-strict.c' being used in various forms in the other testcases.) I understand. The main thrust of ptrace-tests is to have individual files that are easy to build and test on their own, so they can be passed around among kernel hackers. Displaying a little info rather than just aborting goes a long way to making the kernel debugging easier, without much effort in the test-writing. Use your judgment. If someone debugging the kernel problem would always wind up editting the test by hand with a one-liner to see what's going on, then it's probably worth writing the one line ahead of time. That's all. > My mistake there was expecting the CPU stops in PTRACE_SINGLEBLOCK after > `orl $0x100, %eflags'. This does not happen as PTRACE_SINGLEBLOCK already has > TF set and uses WRMSR to differ from PTRACE_SINGLESTEP. In this respect > PTRACE_SINGLEBLOCK behaves more like PTRACE_SINGLESTEP than PTRACE_CONT. Right. I'm following up now just to cover any loose ends in this discussion. There are still some loose ends in the code, and I'm tabling that for a bit. (Spent way too much time on tiny corners of x86 stepping already, and I've got to fry some bigger fish before I get back to the remaining nits.) Thanks, Roland From wenji.huang at oracle.com Tue May 6 03:19:45 2008 From: wenji.huang at oracle.com (wenji huang) Date: Tue, 06 May 2008 11:19:45 +0800 Subject: test results for reparent-zombie Message-ID: <481FCE51.7060604@oracle.com> Hi, Here are the test results for reparent-zombie(from prace-tests repository) In 2.6.25 x86_64 (utrace patched): [wjhuang at dhcp-beijing-cdc-10-182-120-226 tests]$ ./reparent-zombie reparent-zombie: reparent-zombie.c:88: create_zombie: Assertion `fd != -1' failed. Aborted dmesg said: ------------[ cut here ]------------ kernel BUG at include/linux/tracehook.h:471! invalid opcode: 0000 [1] CPU 0 Modules linked in: ipv6 Pid: 15106, comm: reparent-zombie Not tainted 2.6.25 #7 RIP: 0010:[] [] release_task+0x3b/0x2b8 RSP: 0018:ffff810009011e58 EFLAGS: 00010087 RAX: ffff81000f27b1f0 RBX: ffff8100092ff7b0 RCX: 0000000000000000 RDX: ffff81000f27b1f8 RSI: ffff810009011df8 RDI: ffff81000f401980 RBP: ffff8100092ff7b0 R08: 0000000000000000 R09: ffff810009011c00 R10: ffff8100092ff7b0 R11: ffff810009011f58 R12: 0000000000000001 R13: 0000000000000000 R14: ffff81000933a7c0 R15: 0000000000000000 FS: 00002b484b5415f0(0000) GS:ffffffff80511000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000033284be9a0 CR3: 0000000009232000 CR4: 00000000000006a0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 Process reparent-zombie (pid: 15106, threadinfo ffff810009010000, task ffff81000933a080) Stack: 0000000000000202 ffff8100090217b0 0000000000000000 000000000007e568 000000000007e568 ffffffff80236f04 ffff81000937c4c0 ffff8100090217b0 ffff8100093874c0 ffffffff80236fff 00000000000005f0 ffff81000fa82370 Call Trace: [] ? wake_quiescent+0x4f/0xb3 [] ? utrace_detach+0x97/0xa3 [] ? ptrace_exit+0x45/0xf7 [] ? do_exit+0xd5/0x5b5 [] ? complete_and_exit+0x0/0x16 [] ? system_call_after_swapgs+0x7b/0x80 Code: 98 06 00 00 00 74 08 48 89 ef e8 b8 9a 01 00 48 8b 85 e0 02 00 00 ff 48 04 48 89 ef e8 b6 95 06 00 fa 83 bd 08 01 00 00 20 74 04 <0f> 0b eb fe 48 83 bd 98 06 00 00 00 74 04 0f 0b eb fe 48 8b 9d RIP [] release_task+0x3b/0x2b8 RSP ---[ end trace 7c28e80fd72d4a3a ]--- In 2.6.25 x86_64 upstream box: [wjhuang at dhcp-beijing-cdc-10-182-120-170 tests]$ ./reparent-zombie 6118 left in State: Z (zombie) [wjhuang at dhcp-beijing-cdc-10-182-120-170 tests]$ echo $? 1 In x86 box, the results are like above ones respectively. It seems that some corner cases trigger the statement BUG_ON(p->exit_state != EXIT_DEAD) in tracehook_release_task_locked() Best regards, Wenji From roland at redhat.com Tue May 6 08:01:58 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 6 May 2008 01:01:58 -0700 (PDT) Subject: test results for reparent-zombie In-Reply-To: wenji huang's message of Tuesday, 6 May 2008 11:19:45 +0800 <481FCE51.7060604@oracle.com> References: <481FCE51.7060604@oracle.com> Message-ID: <20080506080159.0638E26FA20@magilla.localdomain> Sorry, I haven't updated the patch in a while. The current code is in the GIT branches and has fixed this bug. Thanks, Roland From invitation at whereareyounow.net Fri May 9 07:06:11 2008 From: invitation at whereareyounow.net (Basavaraj Mathapaty) Date: Fri, 9 May 2008 08:06:11 +0100 Subject: Basavaraj Mathapaty added you as a friend on WAYN... Message-ID: Dear utrace-devel, Basavaraj Mathapaty (http://www.wayn.com/waynfx.html?wci=link&id=895&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1) has added you as a friend on WAYN (http://www.wayn.com/waynfx.html?wci=link&id=897&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1). Confirm whether you are friends with Basavaraj (http://www.wayn.com/waynfx.html?wci=link&id=896&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1) You can use WAYN to log your trips, see who's where and connect with friends around the globe. WAYN has changed for the better, with new features to help keep track of your friends and with unlimited messaging, search and uploads all now for free! You also have 3 unread messages (http://www.wayn.com/waynfx.html?wci=link&id=898&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1) Thanks, WAYN ---------------------------------------------------- You have received this notification because Basavaraj Mathapaty sent you an invitation to join WAYN If you would not like to receive further invitations from Basavaraj, please click here (http://www.wayn.com/waynfx.html?wci=link&id=899&m=13255828&c=407127741) If you would not like to receive further invitations from anyone, please click here (http://www.wayn.com/waynfx.html?wci=link&id=900&c=407127741) -------------- next part -------------- An HTML attachment was scrubbed... URL: From schwidefsky at de.ibm.com Fri May 9 14:08:48 2008 From: schwidefsky at de.ibm.com (Martin Schwidefsky) Date: Fri, 09 May 2008 16:08:48 +0200 Subject: s390 user_regset/utrace arch work In-Reply-To: <20080508194630.3B07926FA85@magilla.localdomain> References: <20080506083943.9781226FA20@magilla.localdomain> <1210088750.31803.33.camel@localhost> <20080506211807.CC42A26FA05@magilla.localdomain> <1210173069.5204.1.camel@localhost> <20080507182145.66D2226FA08@magilla.localdomain> <1210260437.28421.9.camel@localhost> <20080508194630.3B07926FA85@magilla.localdomain> Message-ID: <1210342128.20421.9.camel@localhost> Hi Roland, On Thu, 2008-05-08 at 12:46 -0700, Roland McGrath wrote: > > I'm making progress on the user_regs patch for s390 (see preliminary > > patch below, core dump seems to work). I've one question so far: > > Please direct future messages on the technical issues to > the mailing list. I think I got all the technical issues resolved. The patch below adds the required user_regset definitions and core dumps of 64/31 bit processes work as expected. I'll add the patch to the git390 patch queue. And thanks a lot for the detailed list of things to do. That helped a lot to speed up the implementation work. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. --- Subject: [PATCH] Introduce user_regset accessors for s390 From: Martin Schwidefsky Add the user_regset definitions for normal and compat processes, replace the dump_regs core dump cruft with the generic CORE_DUMP_USER_REGSET and replace binfmt_elf32.c with the generic compat_binfmt_elf.c implementation. Signed-off-by: Martin Schwidefsky --- arch/s390/Kconfig | 1 arch/s390/kernel/Makefile | 7 arch/s390/kernel/binfmt_elf32.c | 214 ---------------------- arch/s390/kernel/compat_ptrace.h | 4 arch/s390/kernel/ptrace.c | 363 ++++++++++++++++++++++++++++++++++----- include/asm-s390/elf.h | 51 +---- include/asm-s390/processor.h | 14 + include/asm-s390/ptrace.h | 16 + 8 files changed, 366 insertions(+), 304 deletions(-) diff -urpN linux-2.6/arch/s390/Kconfig linux-2.6-patched/arch/s390/Kconfig --- linux-2.6/arch/s390/Kconfig 2008-05-08 17:24:06.000000000 +0200 +++ linux-2.6-patched/arch/s390/Kconfig 2008-05-09 14:50:16.000000000 +0200 @@ -146,6 +146,7 @@ config MATHEMU config COMPAT bool "Kernel support for 31 bit emulation" depends on 64BIT + select COMPAT_BINFMT_ELF help Select this option if you want to enable your system kernel to handle system-calls from ELF binaries for 31 bit ESA. This option diff -urpN linux-2.6/arch/s390/kernel/binfmt_elf32.c linux-2.6-patched/arch/s390/kernel/binfmt_elf32.c --- linux-2.6/arch/s390/kernel/binfmt_elf32.c 2008-05-05 12:48:48.000000000 +0200 +++ linux-2.6-patched/arch/s390/kernel/binfmt_elf32.c 1970-01-01 01:00:00.000000000 +0100 @@ -1,214 +0,0 @@ -/* - * Support for 32-bit Linux for S390 ELF binaries. - * - * Copyright (C) 2000 IBM Deutschland Entwicklung GmbH, IBM Corporation - * Author(s): Gerhard Tonn (ton at de.ibm.com) - * - * Heavily inspired by the 32-bit Sparc compat code which is - * Copyright (C) 1995, 1996, 1997, 1998 David S. Miller (davem at redhat.com) - * Copyright (C) 1995, 1996, 1997, 1998 Jakub Jelinek (jj at ultra.linux.cz) - */ - -#define __ASMS390_ELF_H - -#include - -/* - * These are used to set parameters in the core dumps. - */ -#define ELF_CLASS ELFCLASS32 -#define ELF_DATA ELFDATA2MSB -#define ELF_ARCH EM_S390 - -/* - * This is used to ensure we don't load something for the wrong architecture. - */ -#define elf_check_arch(x) \ - (((x)->e_machine == EM_S390 || (x)->e_machine == EM_S390_OLD) \ - && (x)->e_ident[EI_CLASS] == ELF_CLASS) - -/* ELF register definitions */ -#define NUM_GPRS 16 -#define NUM_FPRS 16 -#define NUM_ACRS 16 - -/* For SVR4/S390 the function pointer to be registered with `atexit` is - passed in R14. */ -#define ELF_PLAT_INIT(_r, load_addr) \ - do { \ - _r->gprs[14] = 0; \ - } while(0) - -#define USE_ELF_CORE_DUMP -#define ELF_EXEC_PAGESIZE 4096 - -/* This is the location that an ET_DYN program is loaded if exec'ed. Typical - use of this is to invoke "./ld.so someprog" to test out a new version of - the loader. We need to make sure that it is out of the way of the program - that it will "exec", and that there is sufficient room for the brk. */ - -#define ELF_ET_DYN_BASE (TASK_SIZE / 3 * 2) - -/* Wow, the "main" arch needs arch dependent functions too.. :) */ - -/* regs is struct pt_regs, pr_reg is elf_gregset_t (which is - now struct_user_regs, they are different) */ - -#define ELF_CORE_COPY_REGS(pr_reg, regs) dump_regs32(regs, &pr_reg); - -#define ELF_CORE_COPY_TASK_REGS(tsk, regs) dump_task_regs32(tsk, regs) - -#define ELF_CORE_COPY_FPREGS(tsk, fpregs) dump_task_fpu(tsk, fpregs) - -/* This yields a mask that user programs can use to figure out what - instruction set this CPU supports. */ - -#define ELF_HWCAP (0) - -/* This yields a string that ld.so will use to load implementation - specific libraries for optimization. This is more specific in - intent than poking at uname or /proc/cpuinfo. - - For the moment, we have only optimizations for the Intel generations, - but that could change... */ - -#define ELF_PLATFORM (NULL) - -#define SET_PERSONALITY(ex, ibcs2) \ -do { \ - if (ibcs2) \ - set_personality(PER_SVR4); \ - else if (current->personality != PER_LINUX32) \ - set_personality(PER_LINUX); \ - set_thread_flag(TIF_31BIT); \ -} while (0) - -#include "compat_linux.h" - -typedef _s390_fp_regs32 elf_fpregset_t; - -typedef struct -{ - - _psw_t32 psw; - __u32 gprs[__NUM_GPRS]; - __u32 acrs[__NUM_ACRS]; - __u32 orig_gpr2; -} s390_regs32; -typedef s390_regs32 elf_gregset_t; - -static inline int dump_regs32(struct pt_regs *ptregs, elf_gregset_t *regs) -{ - int i; - - memcpy(®s->psw.mask, &ptregs->psw.mask, 4); - memcpy(®s->psw.addr, (char *)&ptregs->psw.addr + 4, 4); - for (i = 0; i < NUM_GPRS; i++) - regs->gprs[i] = ptregs->gprs[i]; - save_access_regs(regs->acrs); - regs->orig_gpr2 = ptregs->orig_gpr2; - return 1; -} - -static inline int dump_task_regs32(struct task_struct *tsk, elf_gregset_t *regs) -{ - struct pt_regs *ptregs = task_pt_regs(tsk); - int i; - - memcpy(®s->psw.mask, &ptregs->psw.mask, 4); - memcpy(®s->psw.addr, (char *)&ptregs->psw.addr + 4, 4); - for (i = 0; i < NUM_GPRS; i++) - regs->gprs[i] = ptregs->gprs[i]; - memcpy(regs->acrs, tsk->thread.acrs, sizeof(regs->acrs)); - regs->orig_gpr2 = ptregs->orig_gpr2; - return 1; -} - -static inline int dump_task_fpu(struct task_struct *tsk, elf_fpregset_t *fpregs) -{ - if (tsk == current) - save_fp_regs((s390_fp_regs *) fpregs); - else - memcpy(fpregs, &tsk->thread.fp_regs, sizeof(elf_fpregset_t)); - return 1; -} - -#include -#include -#include -#include -#include -#include - -#define elf_prstatus elf_prstatus32 -struct elf_prstatus32 -{ - struct elf_siginfo pr_info; /* Info associated with signal */ - short pr_cursig; /* Current signal */ - u32 pr_sigpend; /* Set of pending signals */ - u32 pr_sighold; /* Set of held signals */ - pid_t pr_pid; - pid_t pr_ppid; - pid_t pr_pgrp; - pid_t pr_sid; - struct compat_timeval pr_utime; /* User time */ - struct compat_timeval pr_stime; /* System time */ - struct compat_timeval pr_cutime; /* Cumulative user time */ - struct compat_timeval pr_cstime; /* Cumulative system time */ - elf_gregset_t pr_reg; /* GP registers */ - int pr_fpvalid; /* True if math co-processor being used. */ -}; - -#define elf_prpsinfo elf_prpsinfo32 -struct elf_prpsinfo32 -{ - char pr_state; /* numeric process state */ - char pr_sname; /* char for pr_state */ - char pr_zomb; /* zombie */ - char pr_nice; /* nice val */ - u32 pr_flag; /* flags */ - u16 pr_uid; - u16 pr_gid; - pid_t pr_pid, pr_ppid, pr_pgrp, pr_sid; - /* Lots missing */ - char pr_fname[16]; /* filename of executable */ - char pr_psargs[ELF_PRARGSZ]; /* initial part of arg list */ -}; - -#include - -/* -#define init_elf_binfmt init_elf32_binfmt -*/ - -#undef start_thread -#define start_thread start_thread31 - -static inline void start_thread31(struct pt_regs *regs, unsigned long new_psw, - unsigned long new_stackp) -{ - set_fs(USER_DS); - regs->psw.mask = psw_user32_bits; - regs->psw.addr = new_psw; - regs->gprs[15] = new_stackp; - crst_table_downgrade(current->mm, 1UL << 31); -} - -MODULE_DESCRIPTION("Binary format loader for compatibility with 32bit Linux for S390 binaries," - " Copyright 2000 IBM Corporation"); -MODULE_AUTHOR("Gerhard Tonn "); - -#undef MODULE_DESCRIPTION -#undef MODULE_AUTHOR - -#undef cputime_to_timeval -#define cputime_to_timeval cputime_to_compat_timeval -static inline void -cputime_to_compat_timeval(const cputime_t cputime, struct compat_timeval *value) -{ - value->tv_usec = cputime % 1000000; - value->tv_sec = cputime / 1000000; -} - -#include "../../../fs/binfmt_elf.c" - diff -urpN linux-2.6/arch/s390/kernel/compat_ptrace.h linux-2.6-patched/arch/s390/kernel/compat_ptrace.h --- linux-2.6/arch/s390/kernel/compat_ptrace.h 2008-05-05 12:48:48.000000000 +0200 +++ linux-2.6-patched/arch/s390/kernel/compat_ptrace.h 2008-05-09 14:31:33.000000000 +0200 @@ -1,7 +1,7 @@ #ifndef _PTRACE32_H #define _PTRACE32_H -#include "compat_linux.h" /* needed for _psw_t32 */ +#include "compat_linux.h" /* needed for psw_compat_t */ typedef struct { __u32 cr[3]; @@ -38,7 +38,7 @@ typedef struct { struct user_regs_struct32 { - _psw_t32 psw; + psw_compat_t psw; u32 gprs[NUM_GPRS]; u32 acrs[NUM_ACRS]; u32 orig_gpr2; diff -urpN linux-2.6/arch/s390/kernel/Makefile linux-2.6-patched/arch/s390/kernel/Makefile --- linux-2.6/arch/s390/kernel/Makefile 2008-05-05 12:48:48.000000000 +0200 +++ linux-2.6-patched/arch/s390/kernel/Makefile 2008-05-09 14:49:03.000000000 +0200 @@ -7,6 +7,11 @@ # CFLAGS_smp.o := -Wno-nonnull +# +# Pass UTS_MACHINE for user_regset definition +# +CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' + obj-y := bitmap.o traps.o time.o process.o base.o early.o \ setup.o sys_s390.o ptrace.o signal.o cpcmd.o ebcdic.o \ s390_ext.o debug.o irq.o ipl.o dis.o diag.o @@ -23,7 +28,7 @@ obj-$(CONFIG_AUDIT) += audit.o compat-obj-$(CONFIG_AUDIT) += compat_audit.o obj-$(CONFIG_COMPAT) += compat_linux.o compat_signal.o \ compat_wrapper.o compat_exec_domain.o \ - binfmt_elf32.o $(compat-obj-y) + $(compat-obj-y) obj-$(CONFIG_VIRT_TIMER) += vtime.o obj-$(CONFIG_STACKTRACE) += stacktrace.o diff -urpN linux-2.6/arch/s390/kernel/ptrace.c linux-2.6-patched/arch/s390/kernel/ptrace.c --- linux-2.6/arch/s390/kernel/ptrace.c 2008-05-08 17:24:04.000000000 +0200 +++ linux-2.6-patched/arch/s390/kernel/ptrace.c 2008-05-09 14:31:55.000000000 +0200 @@ -33,6 +33,8 @@ #include #include #include +#include +#include #include #include @@ -47,6 +49,11 @@ #include "compat_ptrace.h" #endif +enum s390_regset { + REGSET_GENERAL, + REGSET_FP, +}; + static void FixPerRegisters(struct task_struct *task) { @@ -126,24 +133,10 @@ ptrace_disable(struct task_struct *child * struct user contain pad bytes that should be read as zeroes. * Lovely... */ -static int -peek_user(struct task_struct *child, addr_t addr, addr_t data) +static unsigned long __peek_user(struct task_struct *child, addr_t addr) { struct user *dummy = NULL; - addr_t offset, tmp, mask; - - /* - * Stupid gdb peeks/pokes the access registers in 64 bit with - * an alignment of 4. Programmers from hell... - */ - mask = __ADDR_MASK; -#ifdef CONFIG_64BIT - if (addr >= (addr_t) &dummy->regs.acrs && - addr < (addr_t) &dummy->regs.orig_gpr2) - mask = 3; -#endif - if ((addr & mask) || addr > sizeof(struct user) - __ADDR_MASK) - return -EIO; + addr_t offset, tmp; if (addr < (addr_t) &dummy->regs.acrs) { /* @@ -197,24 +190,18 @@ peek_user(struct task_struct *child, add } else tmp = 0; - return put_user(tmp, (addr_t __user *) data); + return tmp; } -/* - * Write a word to the user area of a process at location addr. This - * operation does have an additional problem compared to peek_user. - * Stores to the program status word and on the floating point - * control register needs to get checked for validity. - */ static int -poke_user(struct task_struct *child, addr_t addr, addr_t data) +peek_user(struct task_struct *child, addr_t addr, addr_t data) { struct user *dummy = NULL; - addr_t offset, mask; + addr_t tmp, mask; /* * Stupid gdb peeks/pokes the access registers in 64 bit with - * an alignment of 4. Programmers from hell indeed... + * an alignment of 4. Programmers from hell... */ mask = __ADDR_MASK; #ifdef CONFIG_64BIT @@ -225,6 +212,21 @@ poke_user(struct task_struct *child, add if ((addr & mask) || addr > sizeof(struct user) - __ADDR_MASK) return -EIO; + tmp = __peek_user(child, addr); + return put_user(tmp, (addr_t __user *) data); +} + +/* + * Write a word to the user area of a process at location addr. This + * operation does have an additional problem compared to peek_user. + * Stores to the program status word and on the floating point + * control register needs to get checked for validity. + */ +static int __poke_user(struct task_struct *child, addr_t addr, addr_t data) +{ + struct user *dummy = NULL; + addr_t offset; + if (addr < (addr_t) &dummy->regs.acrs) { /* * psw and gprs are stored on the stack @@ -292,6 +294,28 @@ poke_user(struct task_struct *child, add return 0; } +static int +poke_user(struct task_struct *child, addr_t addr, addr_t data) +{ + struct user *dummy = NULL; + addr_t mask; + + /* + * Stupid gdb peeks/pokes the access registers in 64 bit with + * an alignment of 4. Programmers from hell indeed... + */ + mask = __ADDR_MASK; +#ifdef CONFIG_64BIT + if (addr >= (addr_t) &dummy->regs.acrs && + addr < (addr_t) &dummy->regs.orig_gpr2) + mask = 3; +#endif + if ((addr & mask) || addr > sizeof(struct user) - __ADDR_MASK) + return -EIO; + + return __poke_user(child, addr, data); +} + long arch_ptrace(struct task_struct *child, long request, long addr, long data) { ptrace_area parea; @@ -367,18 +391,13 @@ long arch_ptrace(struct task_struct *chi /* * Same as peek_user but for a 31 bit program. */ -static int -peek_user_emu31(struct task_struct *child, addr_t addr, addr_t data) +static u32 __peek_user_compat(struct task_struct *child, addr_t addr) { struct user32 *dummy32 = NULL; per_struct32 *dummy_per32 = NULL; addr_t offset; __u32 tmp; - if (!test_thread_flag(TIF_31BIT) || - (addr & 3) || addr > sizeof(struct user) - 3) - return -EIO; - if (addr < (addr_t) &dummy32->regs.acrs) { /* * psw and gprs are stored on the stack @@ -435,25 +454,32 @@ peek_user_emu31(struct task_struct *chil } else tmp = 0; + return tmp; +} + +static int peek_user_compat(struct task_struct *child, + addr_t addr, addr_t data) +{ + __u32 tmp; + + if (!test_thread_flag(TIF_31BIT) || + (addr & 3) || addr > sizeof(struct user) - 3) + return -EIO; + + tmp = __peek_user_compat(child, addr); return put_user(tmp, (__u32 __user *) data); } /* * Same as poke_user but for a 31 bit program. */ -static int -poke_user_emu31(struct task_struct *child, addr_t addr, addr_t data) +static int __poke_user_compat(struct task_struct *child, + addr_t addr, addr_t data) { struct user32 *dummy32 = NULL; per_struct32 *dummy_per32 = NULL; + __u32 tmp = (__u32) data; addr_t offset; - __u32 tmp; - - if (!test_thread_flag(TIF_31BIT) || - (addr & 3) || addr > sizeof(struct user32) - 3) - return -EIO; - - tmp = (__u32) data; if (addr < (addr_t) &dummy32->regs.acrs) { /* @@ -528,6 +554,16 @@ poke_user_emu31(struct task_struct *chil return 0; } +static int poke_user_compat(struct task_struct *child, + addr_t addr, addr_t data) +{ + if (!test_thread_flag(TIF_31BIT) || + (addr & 3) || addr > sizeof(struct user32) - 3) + return -EIO; + + return __poke_user_compat(child, addr, data); +} + long compat_arch_ptrace(struct task_struct *child, compat_long_t request, compat_ulong_t caddr, compat_ulong_t cdata) { @@ -539,11 +575,11 @@ long compat_arch_ptrace(struct task_stru switch (request) { case PTRACE_PEEKUSR: /* read the word at location addr in the USER area. */ - return peek_user_emu31(child, addr, data); + return peek_user_compat(child, addr, data); case PTRACE_POKEUSR: /* write the word at location addr in the USER area */ - return poke_user_emu31(child, addr, data); + return poke_user_compat(child, addr, data); case PTRACE_PEEKUSR_AREA: case PTRACE_POKEUSR_AREA: @@ -555,13 +591,13 @@ long compat_arch_ptrace(struct task_stru copied = 0; while (copied < parea.len) { if (request == PTRACE_PEEKUSR_AREA) - ret = peek_user_emu31(child, addr, data); + ret = peek_user_compat(child, addr, data); else { __u32 utmp; if (get_user(utmp, (__u32 __force __user *) data)) return -EFAULT; - ret = poke_user_emu31(child, addr, utmp); + ret = poke_user_compat(child, addr, utmp); } if (ret) return ret; @@ -610,3 +646,240 @@ syscall_trace(struct pt_regs *regs, int regs->gprs[2], regs->orig_gpr2, regs->gprs[3], regs->gprs[4], regs->gprs[5]); } + +/* + * user_regset definitions. + */ + +static int s390_regs_get(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + void *kbuf, void __user *ubuf) +{ + if (target == current) + save_access_regs(target->thread.acrs); + + if (kbuf) { + unsigned long *k = kbuf; + while (count > 0) { + *k++ = __peek_user(target, pos); + count -= sizeof(*k); + pos += sizeof(*k); + } + } else { + unsigned long __user *u = ubuf; + while (count > 0) { + if (__put_user(__peek_user(target, pos), u++)) + return -EFAULT; + count -= sizeof(*u); + pos += sizeof(*u); + } + } + return 0; +} + +static int s390_regs_set(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + const void *kbuf, const void __user *ubuf) +{ + int rc = 0; + + if (target == current) + save_access_regs(target->thread.acrs); + + if (kbuf) { + const unsigned long *k = kbuf; + while (count > 0 && !rc) { + rc = __poke_user(target, pos, *k++); + count -= sizeof(*k); + pos += sizeof(*k); + } + } else { + const unsigned long __user *u = ubuf; + while (count > 0 && !rc) { + unsigned long word; + rc = __get_user(word, u++); + if (rc) + break; + rc = __poke_user(target, pos, word); + count -= sizeof(*u); + pos += sizeof(*u); + } + } + + if (rc == 0 && target == current) + restore_access_regs(target->thread.acrs); + + return rc; +} + +static int s390_fpregs_get(struct task_struct *target, + const struct user_regset *regset, unsigned int pos, + unsigned int count, void *kbuf, void __user *ubuf) +{ + if (target == current) + save_fp_regs(&target->thread.fp_regs); + + return user_regset_copyout(&pos, &count, &kbuf, &ubuf, + &target->thread.fp_regs, 0, -1); +} + +static int s390_fpregs_set(struct task_struct *target, + const struct user_regset *regset, unsigned int pos, + unsigned int count, const void *kbuf, + const void __user *ubuf) +{ + int rc = 0; + + if (target == current) + save_fp_regs(&target->thread.fp_regs); + + /* If setting FPC, must validate it first. */ + if (count > 0 && pos < offsetof(s390_fp_regs, fprs)) { + u32 fpc[2] = { target->thread.fp_regs.fpc, 0 }; + rc = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &fpc, + 0, offsetof(s390_fp_regs, fprs)); + if (rc) + return rc; + if ((fpc[0] & ~FPC_VALID_MASK) != 0 || fpc[1] != 0) + return -EINVAL; + target->thread.fp_regs.fpc = fpc[0]; + } + + if (rc == 0 && count > 0) + rc = user_regset_copyin(&pos, &count, &kbuf, &ubuf, + target->thread.fp_regs.fprs, + offsetof(s390_fp_regs, fprs), -1); + + if (rc == 0 && target == current) + restore_fp_regs(&target->thread.fp_regs); + + return rc; +} + +static const struct user_regset s390_regsets[] = { + [REGSET_GENERAL] = { + .core_note_type = NT_PRSTATUS, + .n = sizeof(s390_regs) / sizeof(long), + .size = sizeof(long), + .align = sizeof(long), + .get = s390_regs_get, + .set = s390_regs_set, + }, + [REGSET_FP] = { + .core_note_type = NT_PRFPREG, + .n = sizeof(s390_fp_regs) / sizeof(long), + .size = sizeof(long), + .align = sizeof(long), + .get = s390_fpregs_get, + .set = s390_fpregs_set, + }, +}; + +static const struct user_regset_view user_s390_view = { + .name = UTS_MACHINE, + .e_machine = EM_S390, + .regsets = s390_regsets, + .n = ARRAY_SIZE(s390_regsets) +}; + +#ifdef CONFIG_COMPAT +static int s390_compat_regs_get(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + void *kbuf, void __user *ubuf) +{ + if (target == current) + save_access_regs(target->thread.acrs); + + if (kbuf) { + compat_long_t *k = kbuf; + while (count > 0) { + *k++ = __peek_user_compat(target, pos); + count -= sizeof(*k); + pos += sizeof(*k); + } + } else { + unsigned long __user *u = ubuf; + while (count > 0) { + if (__put_user(__peek_user(target, pos), u++)) + return -EFAULT; + count -= sizeof(*u); + pos += sizeof(*u); + } + } + return 0; +} + +static int s390_compat_regs_set(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + const void *kbuf, const void __user *ubuf) +{ + int rc = 0; + + if (target == current) + save_access_regs(target->thread.acrs); + + if (kbuf) { + const unsigned long *k = kbuf; + while (count > 0 && !rc) { + rc = __poke_user(target, pos, *k++); + count -= sizeof(*k); + pos += sizeof(*k); + } + } else { + const unsigned long __user *u = ubuf; + while (count > 0 && !rc) { + unsigned long word; + rc = __get_user(word, u++); + if (rc) + break; + rc = __poke_user(target, pos, word); + count -= sizeof(*u); + pos += sizeof(*u); + } + } + + if (rc == 0 && target == current) + restore_access_regs(target->thread.acrs); + + return rc; +} + +static const struct user_regset s390_compat_regsets[] = { + [REGSET_GENERAL] = { + .core_note_type = NT_PRSTATUS, + .n = sizeof(s390_compat_regs) / sizeof(compat_long_t), + .size = sizeof(compat_long_t), + .align = sizeof(compat_long_t), + .get = s390_compat_regs_get, + .set = s390_compat_regs_set, + }, + [REGSET_FP] = { + .core_note_type = NT_PRFPREG, + .n = sizeof(s390_fp_regs) / sizeof(compat_long_t), + .size = sizeof(compat_long_t), + .align = sizeof(compat_long_t), + .get = s390_fpregs_get, + .set = s390_fpregs_set, + }, +}; + +static const struct user_regset_view user_s390_compat_view = { + .name = "s390", + .e_machine = EM_S390, + .regsets = s390_compat_regsets, + .n = ARRAY_SIZE(s390_compat_regsets) +}; +#endif + +const struct user_regset_view *task_user_regset_view(struct task_struct *task) +{ +#ifdef CONFIG_COMPAT + if (test_tsk_thread_flag(task, TIF_31BIT)) + return &user_s390_compat_view; +#endif + return &user_s390_view; +} diff -urpN linux-2.6/include/asm-s390/elf.h linux-2.6-patched/include/asm-s390/elf.h --- linux-2.6/include/asm-s390/elf.h 2008-05-05 12:48:55.000000000 +0200 +++ linux-2.6-patched/include/asm-s390/elf.h 2008-05-09 14:59:26.000000000 +0200 @@ -113,6 +113,9 @@ typedef s390_fp_regs elf_fpregset_t; typedef s390_regs elf_gregset_t; +typedef s390_fp_regs compat_elf_fpregset_t; +typedef s390_compat_regs compat_elf_gregset_t; + #include /* for task_struct */ #include /* for save_access_regs */ #include @@ -123,6 +126,10 @@ typedef s390_regs elf_gregset_t; #define elf_check_arch(x) \ (((x)->e_machine == EM_S390 || (x)->e_machine == EM_S390_OLD) \ && (x)->e_ident[EI_CLASS] == ELF_CLASS) +#define compat_elf_check_arch(x) \ + (((x)->e_machine == EM_S390 || (x)->e_machine == EM_S390_OLD) \ + && (x)->e_ident[EI_CLASS] == ELF_CLASS) +#define compat_start_thread start_thread31 /* For SVR4/S390 the function pointer to be registered with `atexit` is passed in R14. */ @@ -131,6 +138,7 @@ typedef s390_regs elf_gregset_t; _r->gprs[14] = 0; \ } while (0) +#define CORE_DUMP_USE_REGSET #define USE_ELF_CORE_DUMP #define ELF_EXEC_PAGESIZE 4096 @@ -140,44 +148,6 @@ typedef s390_regs elf_gregset_t; that it will "exec", and that there is sufficient room for the brk. */ #define ELF_ET_DYN_BASE (STACK_TOP / 3 * 2) -/* Wow, the "main" arch needs arch dependent functions too.. :) */ - -/* regs is struct pt_regs, pr_reg is elf_gregset_t (which is - now struct_user_regs, they are different) */ - -static inline int dump_regs(struct pt_regs *ptregs, elf_gregset_t *regs) -{ - memcpy(®s->psw, &ptregs->psw, sizeof(regs->psw)+sizeof(regs->gprs)); - save_access_regs(regs->acrs); - regs->orig_gpr2 = ptregs->orig_gpr2; - return 1; -} - -#define ELF_CORE_COPY_REGS(pr_reg, regs) dump_regs(regs, &pr_reg); - -static inline int dump_task_regs(struct task_struct *tsk, elf_gregset_t *regs) -{ - struct pt_regs *ptregs = task_pt_regs(tsk); - memcpy(®s->psw, &ptregs->psw, sizeof(regs->psw)+sizeof(regs->gprs)); - memcpy(regs->acrs, tsk->thread.acrs, sizeof(regs->acrs)); - regs->orig_gpr2 = ptregs->orig_gpr2; - return 1; -} - -#define ELF_CORE_COPY_TASK_REGS(tsk, regs) dump_task_regs(tsk, regs) - -static inline int dump_task_fpu(struct task_struct *tsk, elf_fpregset_t *fpregs) -{ - if (tsk == current) - save_fp_regs(fpregs); - else - memcpy(fpregs, &tsk->thread.fp_regs, sizeof(elf_fpregset_t)); - return 1; -} - -#define ELF_CORE_COPY_FPREGS(tsk, fpregs) dump_task_fpu(tsk, fpregs) - - /* This yields a mask that user programs can use to figure out what instruction set this CPU supports. */ @@ -204,7 +174,10 @@ do { \ set_personality(PER_SVR4); \ else if (current->personality != PER_LINUX32) \ set_personality(PER_LINUX); \ - clear_thread_flag(TIF_31BIT); \ + if ((ex).e_ident[EI_CLASS] == ELFCLASS32) \ + set_thread_flag(TIF_31BIT); \ + else \ + clear_thread_flag(TIF_31BIT); \ } while (0) #endif /* __s390x__ */ diff -urpN linux-2.6/include/asm-s390/processor.h linux-2.6-patched/include/asm-s390/processor.h --- linux-2.6/include/asm-s390/processor.h 2008-05-05 12:48:55.000000000 +0200 +++ linux-2.6-patched/include/asm-s390/processor.h 2008-05-09 14:53:42.000000000 +0200 @@ -143,11 +143,19 @@ struct stack_frame { /* * Do necessary setup to start up a new thread. */ -#define start_thread(regs, new_psw, new_stackp) do { \ +#define start_thread(regs, new_psw, new_stackp) do { \ set_fs(USER_DS); \ regs->psw.mask = psw_user_bits; \ - regs->psw.addr = new_psw | PSW_ADDR_AMODE; \ - regs->gprs[15] = new_stackp ; \ + regs->psw.addr = new_psw | PSW_ADDR_AMODE; \ + regs->gprs[15] = new_stackp; \ +} while (0) + +#define start_thread31(regs, new_psw, new_stackp) do { \ + set_fs(USER_DS); \ + regs->psw.mask = psw_user32_bits; \ + regs->psw.addr = new_psw | PSW_ADDR_AMODE; \ + regs->gprs[15] = new_stackp; \ + crst_table_downgrade(current->mm, 1UL << 31); \ } while (0) /* Forward declaration, a strange C thing */ diff -urpN linux-2.6/include/asm-s390/ptrace.h linux-2.6-patched/include/asm-s390/ptrace.h --- linux-2.6/include/asm-s390/ptrace.h 2008-05-08 17:24:04.000000000 +0200 +++ linux-2.6-patched/include/asm-s390/ptrace.h 2008-05-09 14:52:09.000000000 +0200 @@ -215,6 +215,12 @@ typedef struct unsigned long addr; } __attribute__ ((aligned(8))) psw_t; +typedef struct +{ + __u32 mask; + __u32 addr; +} __attribute__ ((aligned(8))) psw_compat_t; + #ifndef __s390x__ #define PSW_MASK_PER 0x40000000UL @@ -292,6 +298,16 @@ typedef struct unsigned long orig_gpr2; } s390_regs; +typedef struct +{ + + psw_compat_t psw; + __u32 gprs[NUM_GPRS]; + __u32 acrs[NUM_ACRS]; + __u32 orig_gpr2; +} s390_compat_regs; + + #ifdef __KERNEL__ #include #include From roland at redhat.com Fri May 9 20:00:10 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 9 May 2008 13:00:10 -0700 (PDT) Subject: s390 user_regset/utrace arch work In-Reply-To: Martin Schwidefsky's message of Friday, 9 May 2008 16:08:48 +0200 <1210342128.20421.9.camel@localhost> References: <20080506083943.9781226FA20@magilla.localdomain> <1210088750.31803.33.camel@localhost> <20080506211807.CC42A26FA05@magilla.localdomain> <1210173069.5204.1.camel@localhost> <20080507182145.66D2226FA08@magilla.localdomain> <1210260437.28421.9.camel@localhost> <20080508194630.3B07926FA85@magilla.localdomain> <1210342128.20421.9.camel@localhost> Message-ID: <20080509200010.AFE2226FA85@magilla.localdomain> > I think I got all the technical issues resolved. The patch below adds > the required user_regset definitions and core dumps of 64/31 bit > processes work as expected. I'll add the patch to the git390 patch > queue. The compat get/set functions look wrong. They need to use compat_ulong_t (i.e. u32) where they use unsigned long and use __{peek,poke}_user_compat where they use __{peek,poke}_user. You changed the one case (of four) that you could actually test, which is the one used by 32-bit core dumps. > And thanks a lot for the detailed list of things to do. That helped a > lot to speed up the implementation work. Glad to help! Thanks, Roland From srinivasa at in.ibm.com Mon May 12 13:51:42 2008 From: srinivasa at in.ibm.com (Srinivasa D S) Date: Mon, 12 May 2008 19:21:42 +0530 Subject: [RFC] [PATCH 0/2] Breakpoint assistance(SSOL) for utrace clients Message-ID: <200805121921.42718.srinivasa@in.ibm.com> Roland, I have attached set of patches for providing breakpoint mechanism for user processes as mentioned in http://sourceware.org/ml/systemtap/2007-q1/msg00571.html. This patchset provides API for insertion/removal of breakpoint. It also has provisions for storing the original instructions in a separate area known as SSOL(Single Step Out of Line) area. One of the intentions to store original instructions in a separate area(SSOL area) is to allow user to do single stepping out of line. Utrace exploiters can make use of this feature for insertion/removal of breakpoints and for single stepping over an out of line copy of the instruction. Prerequisite Iam assuming that, API's for insertion and removal of breakpoint are called when all threads of the process are quiesced. (Probably, one can call these functions from a quiesce handler of a utrace engine.) Iam posting this small piece of code with minimal feature(works only on powerpc architecture) to collect feedback from community about my design and approach in providing breakpoint assistance for user processes. Patches attached in the mail briefly explains implementation, followed by its limitations and todo section. Please let me know your comments/views on this. Thanks Srinivasa DS From srinivasa at in.ibm.com Mon May 12 14:06:10 2008 From: srinivasa at in.ibm.com (Srinivasa D S) Date: Mon, 12 May 2008 19:36:10 +0530 Subject: [RFC] [PATCH 1/2] Insertion/Removal of Breakpoint In-Reply-To: <200805121921.42718.srinivasa@in.ibm.com> References: <200805121921.42718.srinivasa@in.ibm.com> Message-ID: <200805121936.10614.srinivasa@in.ibm.com> This patch contains code for insertion and removal of breakpoint on user process. Each virtual address at which breakpoint is inserted, is represented through "ubp" structure. It has fields to store virtual address, instruction at the virtual address and hlist_node to insert it in ubp_table maintained by ubp_per_process data structure. "ubp_per_process" represents each process for which user breakpoints are inserted. It maintains table of "ubp" objects. "ubp_process_table" is the global hash table of processes for which breakpoints are inserted. "ubp_process_table_lock" protects this table from concurrent access. insert_user_bp() This procedure inserts breakpoint on the process identified by pid at virtual address vaddr after validating vaddr. It copies the original instruction at the virtual address to ubp object. Then ubp object is inserted in to ubp_table. insert_user_bp() returns successfully, if "ubp" object already exists for vaddr provided by the user. ("ubp" may be created by same instrumentation module or by another module which uses this infrastructure.) remove_user_bp() This procedure removes breakpoint from the virtual address vaddr of process identified by pid. It goes through the ubp_process_table to fetch ubp_per_process object and then ubp object associated with the virtual address. It replaces breakpoint instruction by the original instruction found in ubp object. Since insert_user_bp()/remove_user_bp() is called from a quiesce handler of a thread when all of its sibling threads are quiesced, no care has been taken to protect the data structures except ubp_process_table_lock. Limitation ========== 1) This patch doesn't support multiple unrelated(using different underlying infrastructure for insertion/removal of breakpoints ) instrumentation modules to probe same process. todo ==== 1) To support this feature on other architectures like x86/x86_64. Signed-off-by: Srinivasa DS --- include/asm-powerpc/user_breakpoint.h | 29 ++++ include/linux/user_breakpoint.h | 49 ++++++ init/Kconfig | 11 + kernel/Makefile | 1 kernel/user_breakpoint.c | 242 ++++++++++++++++++++++++++++++++++ 5 files changed, 332 insertions(+) Index: linux-2.6.25-rc6/include/asm-powerpc/user_breakpoint.h =================================================================== --- /dev/null +++ linux-2.6.25-rc6/include/asm-powerpc/user_breakpoint.h @@ -0,0 +1,29 @@ +#ifndef _ASM_USER_BREAKPOINT_H +#define _ASM_USER_BREAKPOINT_H + +/* + * Insertion/Removal of breakpoint + * user_breakpoint.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, 2006 + */ + +#define BREAKPOINT_INSTRUCTION 0x7fe00008 +#define BP_INSN_SIZE 4 +#define MAX_UINSN_BYTES 4 + +#endif /* ASM_POWERPC_USER_BREAKPOINT_H */ Index: linux-2.6.25-rc6/include/linux/user_breakpoint.h =================================================================== --- /dev/null +++ linux-2.6.25-rc6/include/linux/user_breakpoint.h @@ -0,0 +1,49 @@ +#ifndef _USER_BREAKPOINT_H +#define _USER_BREAKPOINT_H +/* + * Insertion/Removal of breakpoint + * user_breakpoint.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, 2006 + */ +#include +#include +#include +#include + +#define BP_HASH_BITS 5 +#define BP_TABLE_SIZE (1 << BP_HASH_BITS) + +typedef unsigned int user_opcode_t; + +struct ubp { + user_opcode_t opcode; + user_opcode_t insn[MAX_UINSN_BYTES / sizeof(user_opcode_t)]; + unsigned long vaddr; + struct hlist_node bpt_node; +}; + +/* + * Represents each process for which user breakpoints are inserted. + */ +struct ubp_per_process { + struct hlist_head ubp_table[BP_TABLE_SIZE]; + struct hlist_node hlist; /* node for global user breakpoints table */ + pid_t tgid; +}; + +#endif /*_USER_BREAKPOINT_H */ Index: linux-2.6.25-rc6/init/Kconfig =================================================================== --- linux-2.6.25-rc6.orig/init/Kconfig +++ linux-2.6.25-rc6/init/Kconfig @@ -887,6 +887,17 @@ config UTRACE applications. Unless you are making a specially stripped-down kernel and are very sure you don't need these facilitiies, say Y. + +config USER_BP_ASSIST + bool "Infrastructure to insert/remove breakpoints on user processses" + default y + depends on UTRACE + help + This option provides infrastructure to insert/remove + breakpoints on user processes. UTRACE exploiters can + make use of this mechanism for insertion/removal of + breakpoints. + Say Y here if you want to enable USER_BP_ASSIST. endmenu source "block/Kconfig" Index: linux-2.6.25-rc6/kernel/Makefile =================================================================== --- linux-2.6.25-rc6.orig/kernel/Makefile +++ linux-2.6.25-rc6/kernel/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_AUDITSYSCALL) += auditsc.o obj-$(CONFIG_AUDIT_TREE) += audit_tree.o obj-$(CONFIG_KPROBES) += kprobes.o obj-$(CONFIG_UTRACE) += utrace.o +obj-$(CONFIG_USER_BP_ASSIST) += user_breakpoint.o obj-$(CONFIG_DETECT_SOFTLOCKUP) += softlockup.o obj-$(CONFIG_GENERIC_HARDIRQS) += irq/ obj-$(CONFIG_SECCOMP) += seccomp.o Index: linux-2.6.25-rc6/kernel/user_breakpoint.c =================================================================== --- /dev/null +++ linux-2.6.25-rc6/kernel/user_breakpoint.c @@ -0,0 +1,242 @@ +/* + * Insertion/Removal of breakpoint + * user_breakpoint.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 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, 2006 + */ +#include +#include +#include +#include +#include +#include + +/* Global hashtable of processes for which breakpoints are inserted */ +struct hlist_head ubp_process_table[BP_TABLE_SIZE]; + +/* lock to protect ubp_process_table[]*/ +DEFINE_SPINLOCK(ubp_process_table_lock); + +static struct ubp_per_process *find_ubp_process(struct task_struct *tsk) +{ + struct hlist_head *head; + struct hlist_node *node; + struct ubp_per_process *ubp_proc = NULL; + unsigned long flags; + + spin_lock_irqsave(&ubp_process_table_lock, flags); + head = &ubp_process_table[hash_long(tsk->tgid, BP_HASH_BITS)]; + hlist_for_each_entry(ubp_proc, node, head, hlist) { + if (ubp_proc->tgid == tsk->tgid) { + spin_unlock_irqrestore(&ubp_process_table_lock, flags); + return ubp_proc; + } + } + spin_unlock_irqrestore(&ubp_process_table_lock, flags); + return NULL; +} + +static struct ubp_per_process *create_ubp_process(struct task_struct *p) +{ + struct ubp_per_process *ubp_proc; + unsigned long flags; + int i; + + ubp_proc = kzalloc(sizeof *ubp_proc, GFP_USER); + if (ubp_proc == NULL) + return ERR_PTR(-ENOMEM); + for (i = 0; i < BP_TABLE_SIZE; i++) + INIT_HLIST_HEAD(&ubp_proc->ubp_table[i]); + INIT_HLIST_NODE(&ubp_proc->hlist); + ubp_proc->tgid = p->tgid; + spin_lock_irqsave(&ubp_process_table_lock, flags); + hlist_add_head(&ubp_proc->hlist, + &ubp_process_table[hash_long(p->tgid, BP_HASH_BITS)]); + spin_unlock_irqrestore(&ubp_process_table_lock, flags); + return ubp_proc; +} + +/* When a process dies, cleanup the data structures, like delete ubp_proc from + * ubp_process_table and free ubp_proc. Clients can call this function from + * utrace exit_handler(). + */ +void del_ubp_process(struct task_struct *tsk) +{ + struct hlist_head *head; + struct hlist_node *node; + struct ubp_per_process *ubp_proc = NULL; + unsigned long flags; + + spin_lock_irqsave(&ubp_process_table_lock, flags); + head = &ubp_process_table[hash_long(tsk->pid, BP_HASH_BITS)]; + hlist_for_each_entry(ubp_proc, node, head, hlist) { + if (ubp_proc->tgid == tsk->pid) { + hlist_del(&ubp_proc->hlist); + kfree(ubp_proc); + spin_unlock_irqrestore(&ubp_process_table_lock, flags); + return; + } + } + spin_unlock_irqrestore(&ubp_process_table_lock, flags); + return; +} + +static struct ubp *ubp_add(unsigned long vaddr, + struct ubp_per_process *ubp_proc) +{ + struct ubp *bp; + + bp = kzalloc(sizeof *bp, GFP_USER); + if (bp == NULL) + return ERR_PTR(-ENOMEM); + bp->vaddr = vaddr; + INIT_HLIST_NODE(&bp->bpt_node); + hlist_add_head(&bp->bpt_node, + &ubp_proc->ubp_table[hash_long(bp->vaddr, BP_HASH_BITS)]); + return bp; +} + +static struct ubp *ubp_find(unsigned long vaddr, + struct ubp_per_process *ubp_proc) +{ + struct hlist_node *node; + struct hlist_head *head; + struct ubp *bp; + + head = &ubp_proc->ubp_table[hash_long(vaddr, BP_HASH_BITS)]; + hlist_for_each_entry(bp, node, head, bpt_node) { + if (bp->vaddr == vaddr) + return bp; + } + return NULL; +} + +static int validate_vaddr(struct task_struct *p, unsigned long vaddr) +{ + struct vm_area_struct *vma; + struct mm_struct *mm = p->mm; + int err = 0; + + if (!mm) + return -EINVAL; + + down_read(&mm->mmap_sem); + vma = find_vma(mm, vaddr); + if (!vma || (vaddr < vma->vm_start) || !(vma->vm_flags & VM_EXEC)) + err = -EINVAL; + + up_read(&mm->mmap_sem); + + return err; +} + +static int set_bp(struct ubp *bp, struct task_struct *tsk) +{ + user_opcode_t bp_insn = BREAKPOINT_INSTRUCTION; + return access_process_vm(tsk, bp->vaddr, &bp_insn, BP_INSN_SIZE, 1); +} + +int insert_user_bp(unsigned long vaddr, struct task_struct *p) +{ + struct ubp_per_process *ubp_proc; + struct ubp *bp; + int ret, len; + + ret = validate_vaddr(p, vaddr); + if (ret) { + printk(KERN_ERR "Invalid vitrual address %#lx in %d\n", + vaddr, p->tgid); + return -EINVAL; + } + + ubp_proc = find_ubp_process(p); + if (!ubp_proc) { + ubp_proc = create_ubp_process(p); + if (IS_ERR(ubp_proc)) + return -ENOMEM; + } + + bp = ubp_find(vaddr, ubp_proc); + if (bp) /*breakpoint is already inserted at this vaddr */ + return 0; + else { + bp = ubp_add(vaddr, ubp_proc); + if (IS_ERR(bp)) + return -ENOMEM; + } + + len = access_process_vm(p, vaddr, bp->insn, MAX_UINSN_BYTES, 0); + if (len < BP_INSN_SIZE) { + printk(KERN_ERR "Failed to read original instruction at %#lx" + "in %d \n", vaddr, p->tgid); + goto bp_fail; + } + + memcpy(&bp->opcode, bp->insn, BP_INSN_SIZE); + if (bp->opcode == BREAKPOINT_INSTRUCTION) { + printk(KERN_INFO "breakpoint already exists at %#lx addr" + "in %d \n", bp->vaddr, p->tgid); + goto bp_fail; + } + len = set_bp(bp, p); + if (len < BP_INSN_SIZE) { + printk(KERN_ERR "failed to insert breakpoint instruction at %d" + "vaddr %#lx \n", p->tgid, bp->vaddr); + goto bp_fail; + } + return 0; + +bp_fail: + hlist_del(&bp->bpt_node); + kfree(bp); + return -EINVAL; + +} +EXPORT_SYMBOL(insert_user_bp); + +static int set_orig_insn(struct ubp *bp, struct task_struct *tsk) +{ + return access_process_vm(tsk, bp->vaddr, &bp->opcode, BP_INSN_SIZE, 1); +} + +int remove_user_bp(unsigned long vaddr, struct task_struct *tsk) +{ + struct ubp *bp; + struct ubp_per_process *ubp_proc; + int len; + + + ubp_proc = find_ubp_process(tsk); + if (!ubp_proc) + return -EINVAL; + + bp = ubp_find(vaddr, ubp_proc); + if (!bp) + return -EINVAL; + + len = set_orig_insn(bp, tsk); + if (len < BP_INSN_SIZE) { + printk(KERN_ERR "Failed to remove breakpoint at %#lx:", + bp->vaddr); + send_sig(SIGKILL, tsk, 0); + } + hlist_del(&bp->bpt_node); + kfree(bp); + + return 0; +} +EXPORT_SYMBOL(remove_user_bp); From srinivasa at in.ibm.com Mon May 12 14:07:53 2008 From: srinivasa at in.ibm.com (Srinivasa D S) Date: Mon, 12 May 2008 19:37:53 +0530 Subject: [RFC] [PATCH 2/2] Single Step Out of Line(SSOL) assistance In-Reply-To: <200805121921.42718.srinivasa@in.ibm.com> References: <200805121921.42718.srinivasa@in.ibm.com> Message-ID: <200805121937.53131.srinivasa@in.ibm.com> This patch provides SSOL(Single step Out of Line) assistance to the user processes.It contains code to copy original instruction to a separate SSOL area. SSOL area: copies of original instruction are stored in a per-process SSOL area, which is a little VM area created on each probed process's address space. setup_ssol_vma() mmaps "n" bytes and then sets vmflags of vma, so that ssol area is not copied over fork and not resized with mremap. ssol area is divided into MAX_SSOL_SLOTS (calculated as PAGE_SIZE/MAX_INSN_SIZE) slots and each slot stores an instruction. alloc_ssol_slot() allocates a slot to user_bp object. Slot allocation algorithm: Currently, a simple algorithm to allocate/free slots in SSOL area is used. It searches for the free slots available in SSOL area and returns slot if it finds one, else returns error code. Even though we copy instruction to SSOL area, dealing with signal when breakpoint is hit and implementing single stepping on SSOL area is governed by the user and attached patch doesn't have the code for it. But patch provides certain features that can be used by clients for smoother implementation of SSOL, like user can make use of mutex provided in ssol_slot to prevent concurrent read/writes of slot area. Since insert_user_bp()/remove_user_bp() is called from a quiesce handler of a thread when all of its sibling threads are quiesced, no care has been taken to protect the data structures. Restrictions ============ 1) When process P1 is in STOPPED state and if another process P2 tries to quiesce P1, utrace will run the report_quiesce() in P2 context and not in P1 context.Since creation of SSOL area in a process P1 has to be executed in P1 process context, We reject any attempt to create new SSOL area if report_quiesce() is not called from same process context. todo ==== 1) Since we store an instruction per slot, we can insert maximum of MAX_SSOL_SLOTS of breakpoints on a process. But there is a scope to increase it further. Signed-off-by: Srinivasa DS --- include/linux/user_breakpoint.h | 36 +++++++++++ init/Kconfig | 8 +- kernel/Makefile | 2 kernel/user_breakpoint.c | 17 +++++ kernel/user_ssol.c | 125 ++++++++++++++++++++++++++++++++++++++++ 5 files changed, 184 insertions(+), 4 deletions(-) Index: linux-2.6.25-rc6/kernel/Makefile =================================================================== --- linux-2.6.25-rc6.orig/kernel/Makefile +++ linux-2.6.25-rc6/kernel/Makefile @@ -54,7 +54,7 @@ obj-$(CONFIG_AUDITSYSCALL) += auditsc.o obj-$(CONFIG_AUDIT_TREE) += audit_tree.o obj-$(CONFIG_KPROBES) += kprobes.o obj-$(CONFIG_UTRACE) += utrace.o -obj-$(CONFIG_USER_BP_ASSIST) += user_breakpoint.o +obj-$(CONFIG_USER_BP_ASSIST) += user_breakpoint.o user_ssol.o obj-$(CONFIG_DETECT_SOFTLOCKUP) += softlockup.o obj-$(CONFIG_GENERIC_HARDIRQS) += irq/ obj-$(CONFIG_SECCOMP) += seccomp.o Index: linux-2.6.25-rc6/kernel/user_breakpoint.c =================================================================== --- linux-2.6.25-rc6.orig/kernel/user_breakpoint.c +++ linux-2.6.25-rc6/kernel/user_breakpoint.c @@ -63,6 +63,9 @@ static struct ubp_per_process *create_ub INIT_HLIST_HEAD(&ubp_proc->ubp_table[i]); INIT_HLIST_NODE(&ubp_proc->hlist); ubp_proc->tgid = p->tgid; + ubp_proc->sarea = init_ssol(); + if (!ubp_proc->sarea) + return ERR_PTR(-ENOMEM); spin_lock_irqsave(&ubp_process_table_lock, flags); hlist_add_head(&ubp_proc->hlist, &ubp_process_table[hash_long(p->tgid, BP_HASH_BITS)]); @@ -165,6 +168,12 @@ int insert_user_bp(unsigned long vaddr, ubp_proc = find_ubp_process(p); if (!ubp_proc) { + if (p->tgid != current->tgid) { + printk("Process %d is either already quiesced or in " + "stopped state and cannot initiate SSOL \n", + p->tgid); + return -EINVAL; + } ubp_proc = create_ubp_process(p); if (IS_ERR(ubp_proc)) return -ENOMEM; @@ -192,6 +201,13 @@ int insert_user_bp(unsigned long vaddr, "in %d \n", bp->vaddr, p->tgid); goto bp_fail; } + + ret = alloc_ssol_slot(ubp_proc->sarea, bp); + if (ret) { + printk(KERN_ERR "Failed to get a slot in SSOL area \n"); + goto bp_fail; + } + len = set_bp(bp, p); if (len < BP_INSN_SIZE) { printk(KERN_ERR "failed to insert breakpoint instruction at %d" @@ -235,6 +251,7 @@ int remove_user_bp(unsigned long vaddr, send_sig(SIGKILL, tsk, 0); } hlist_del(&bp->bpt_node); + free_ssol_slot(bp, ubp_proc->sarea); kfree(bp); return 0; Index: linux-2.6.25-rc6/kernel/user_ssol.c =================================================================== --- /dev/null +++ linux-2.6.25-rc6/kernel/user_ssol.c @@ -0,0 +1,125 @@ +/* + * Setup SSOL area. + * kernel/user_ssol.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 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, 2006 + */ +#include +#include +#include +#include +#include +#include + +unsigned long setup_ssol_vma(unsigned long nbytes) +{ + unsigned long addr; + struct mm_struct *mm = current->mm; + struct vm_area_struct *vma; + + BUG_ON(nbytes & ~PAGE_MASK); + + down_write(&mm->mmap_sem); + + /* Find the end of the top mapping and skip a page.*/ + 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, nbytes, PROT_EXEC, + MAP_PRIVATE|MAP_ANONYMOUS, 0); + if (addr & ~PAGE_MASK) { + up_write(&mm->mmap_sem); + printk(KERN_ERR "Breakpoint failed to allocate a vma for" + "pid %d for SSOL.\n", current->pid); + return (addr | PAGE_MASK); + } + + vma = find_vma(mm, addr); + if (!vma) { + up_write(&mm->mmap_sem); + return -ENOMEM; + } + /* avoid vma copy on fork() and don't expand when mremap() */ + vma->vm_flags |= VM_DONTCOPY | VM_DONTEXPAND; + + up_write(&mm->mmap_sem); + return addr; +} + +struct ssol_area *init_ssol(void) +{ + struct ssol_area *area; + struct ssol_slot *slot; + int i; + char *slot_addr; + + area = kzalloc(sizeof(struct ssol_area), GFP_USER); + if (!area) + return NULL; + + area->insn_area = (user_opcode_t *) setup_ssol_vma(PAGE_SIZE); + if (IS_ERR(area->insn_area)) + return NULL; + + area->nslots = MAX_SSOL_SLOTS; + area->slots = kzalloc(sizeof(*slot) * area->nslots, GFP_USER); + if (!area->slots) { + area->insn_area = ERR_PTR(-ENOMEM); + return NULL; + } + slot_addr = (char *) area->insn_area; + for (i = 0; i < area->nslots; i++) { + slot = &area->slots[i]; + slot->occupied = false; + slot->insn = (user_opcode_t *) slot_addr; + slot_addr += MAX_UINSN_BYTES; + } + return area; +} + +int alloc_ssol_slot(struct ssol_area *area, struct ubp *bp) +{ + struct ssol_slot *slot; + int i, len; + + for (i = 0; i < area->nslots; i++) { + slot = &area->slots[i]; + if (!slot->occupied) + break; + } + if (i == area->nslots) + return -EFAULT; + + bp->slot = slot; + slot->occupied = true; + len = access_process_vm(current, (unsigned long)slot->insn, + bp->insn, MAX_UINSN_BYTES, 1); + if (unlikely(len < MAX_UINSN_BYTES)) { + printk(KERN_ERR "Failed to copy instruction at %#lx" + " to SSOL area (%#lx)\n", bp->vaddr, + (unsigned long) area->slots); + return -EFAULT; + } + return 0; +} + +void free_ssol_slot(struct ubp *bp, struct ssol_area *area) +{ + + if (bp->slot) + bp->slot->occupied = false; +} + Index: linux-2.6.25-rc6/include/linux/user_breakpoint.h =================================================================== --- linux-2.6.25-rc6.orig/include/linux/user_breakpoint.h +++ linux-2.6.25-rc6/include/linux/user_breakpoint.h @@ -24,15 +24,18 @@ #include #include #include +#include #define BP_HASH_BITS 5 #define BP_TABLE_SIZE (1 << BP_HASH_BITS) +#define MAX_SSOL_SLOTS (PAGE_SIZE/MAX_INSN_SIZE) typedef unsigned int user_opcode_t; struct ubp { user_opcode_t opcode; user_opcode_t insn[MAX_UINSN_BYTES / sizeof(user_opcode_t)]; + struct ssol_slot *slot; unsigned long vaddr; struct hlist_node bpt_node; }; @@ -44,6 +47,39 @@ struct ubp_per_process { struct hlist_head ubp_table[BP_TABLE_SIZE]; struct hlist_node hlist; /* node for global user breakpoints table */ pid_t tgid; + struct ssol_area *sarea; }; +/* + * SSOL provides an opportunity to do single stepping of an out of line + * copy of the instruction. This is done by storing the original instrction + * in a separate area within the process's address space and single stepping + * on it. + */ + +/* + * SSOL area represents the mmaped area in the process address space for + * storing the original instructions at breakpoint location. + */ +struct ssol_area { + __user user_opcode_t *insn_area; /* instructions in SSOL area */ + int nslots; + struct ssol_slot *slots; +}; + +/* + * ssol_slot represents each instruction in the SSOL area + */ +struct ssol_slot { + __user user_opcode_t *insn; /* instruction in the SSOL area */ + bool occupied; /* bool to indicate the status of slot */ + /* + * mutex to prevent concurrent read/write on a slot + */ + struct mutex slot_mutex; +}; + +struct ssol_area *init_ssol(void); +int alloc_ssol_slot(struct ssol_area *area, struct ubp *bp); +void free_ssol_slot(struct ubp *bp, struct ssol_area *area); #endif /*_USER_BREAKPOINT_H */ Index: linux-2.6.25-rc6/init/Kconfig =================================================================== --- linux-2.6.25-rc6.orig/init/Kconfig +++ linux-2.6.25-rc6/init/Kconfig @@ -894,9 +894,11 @@ config USER_BP_ASSIST depends on UTRACE help This option provides infrastructure to insert/remove - breakpoints on user processes. UTRACE exploiters can - make use of this mechanism for insertion/removal of - breakpoints. + breakpoints on user processes. It also offers assistance + in single stepping out of line (SSOL) on the original + instruction by copying the original instruction to a + separate SSOL area. UTRACE exploiters can make use of + this mechanism for insertion/removal of breakpoints. Say Y here if you want to enable USER_BP_ASSIST. endmenu From schwidefsky at de.ibm.com Tue May 13 10:47:58 2008 From: schwidefsky at de.ibm.com (Martin Schwidefsky) Date: Tue, 13 May 2008 12:47:58 +0200 Subject: s390 user_regset/utrace arch work In-Reply-To: <20080509200010.AFE2226FA85@magilla.localdomain> References: <20080506083943.9781226FA20@magilla.localdomain> <1210088750.31803.33.camel@localhost> <20080506211807.CC42A26FA05@magilla.localdomain> <1210173069.5204.1.camel@localhost> <20080507182145.66D2226FA08@magilla.localdomain> <1210260437.28421.9.camel@localhost> <20080508194630.3B07926FA85@magilla.localdomain> <1210342128.20421.9.camel@localhost> <20080509200010.AFE2226FA85@magilla.localdomain> Message-ID: <1210675678.23992.7.camel@localhost> On Fri, 2008-05-09 at 13:00 -0700, Roland McGrath wrote: > > I think I got all the technical issues resolved. The patch below adds > > the required user_regset definitions and core dumps of 64/31 bit > > processes work as expected. I'll add the patch to the git390 patch > > queue. > > The compat get/set functions look wrong. They need to use compat_ulong_t > (i.e. u32) where they use unsigned long and use __{peek,poke}_user_compat > where they use __{peek,poke}_user. You changed the one case (of four) that > you could actually test, which is the one used by 32-bit core dumps. Indeed, I've fixed the three other places. Thanks for the review. See below for the new patch. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. --- Subject: [PATCH] Introduce user_regset accessors for s390 From: Martin Schwidefsky Add the user_regset definitions for normal and compat processes, replace the dump_regs core dump cruft with the generic CORE_DUMP_USER_REGSET and replace binfmt_elf32.c with the generic compat_binfmt_elf.c implementation. Signed-off-by: Martin Schwidefsky --- arch/s390/Kconfig | 1 arch/s390/kernel/Makefile | 7 arch/s390/kernel/binfmt_elf32.c | 214 ---------------------- arch/s390/kernel/compat_ptrace.h | 4 arch/s390/kernel/ptrace.c | 363 ++++++++++++++++++++++++++++++++++----- include/asm-s390/elf.h | 51 +---- include/asm-s390/processor.h | 14 + include/asm-s390/ptrace.h | 15 + 8 files changed, 365 insertions(+), 304 deletions(-) diff -urpN linux-2.6/arch/s390/Kconfig linux-2.6-patched/arch/s390/Kconfig --- linux-2.6/arch/s390/Kconfig 2008-05-13 12:30:42.000000000 +0200 +++ linux-2.6-patched/arch/s390/Kconfig 2008-05-13 12:30:54.000000000 +0200 @@ -146,6 +146,7 @@ config MATHEMU config COMPAT bool "Kernel support for 31 bit emulation" depends on 64BIT + select COMPAT_BINFMT_ELF help Select this option if you want to enable your system kernel to handle system-calls from ELF binaries for 31 bit ESA. This option diff -urpN linux-2.6/arch/s390/kernel/binfmt_elf32.c linux-2.6-patched/arch/s390/kernel/binfmt_elf32.c --- linux-2.6/arch/s390/kernel/binfmt_elf32.c 2008-04-17 04:49:44.000000000 +0200 +++ linux-2.6-patched/arch/s390/kernel/binfmt_elf32.c 1970-01-01 01:00:00.000000000 +0100 @@ -1,214 +0,0 @@ -/* - * Support for 32-bit Linux for S390 ELF binaries. - * - * Copyright (C) 2000 IBM Deutschland Entwicklung GmbH, IBM Corporation - * Author(s): Gerhard Tonn (ton at de.ibm.com) - * - * Heavily inspired by the 32-bit Sparc compat code which is - * Copyright (C) 1995, 1996, 1997, 1998 David S. Miller (davem at redhat.com) - * Copyright (C) 1995, 1996, 1997, 1998 Jakub Jelinek (jj at ultra.linux.cz) - */ - -#define __ASMS390_ELF_H - -#include - -/* - * These are used to set parameters in the core dumps. - */ -#define ELF_CLASS ELFCLASS32 -#define ELF_DATA ELFDATA2MSB -#define ELF_ARCH EM_S390 - -/* - * This is used to ensure we don't load something for the wrong architecture. - */ -#define elf_check_arch(x) \ - (((x)->e_machine == EM_S390 || (x)->e_machine == EM_S390_OLD) \ - && (x)->e_ident[EI_CLASS] == ELF_CLASS) - -/* ELF register definitions */ -#define NUM_GPRS 16 -#define NUM_FPRS 16 -#define NUM_ACRS 16 - -/* For SVR4/S390 the function pointer to be registered with `atexit` is - passed in R14. */ -#define ELF_PLAT_INIT(_r, load_addr) \ - do { \ - _r->gprs[14] = 0; \ - } while(0) - -#define USE_ELF_CORE_DUMP -#define ELF_EXEC_PAGESIZE 4096 - -/* This is the location that an ET_DYN program is loaded if exec'ed. Typical - use of this is to invoke "./ld.so someprog" to test out a new version of - the loader. We need to make sure that it is out of the way of the program - that it will "exec", and that there is sufficient room for the brk. */ - -#define ELF_ET_DYN_BASE (TASK_SIZE / 3 * 2) - -/* Wow, the "main" arch needs arch dependent functions too.. :) */ - -/* regs is struct pt_regs, pr_reg is elf_gregset_t (which is - now struct_user_regs, they are different) */ - -#define ELF_CORE_COPY_REGS(pr_reg, regs) dump_regs32(regs, &pr_reg); - -#define ELF_CORE_COPY_TASK_REGS(tsk, regs) dump_task_regs32(tsk, regs) - -#define ELF_CORE_COPY_FPREGS(tsk, fpregs) dump_task_fpu(tsk, fpregs) - -/* This yields a mask that user programs can use to figure out what - instruction set this CPU supports. */ - -#define ELF_HWCAP (0) - -/* This yields a string that ld.so will use to load implementation - specific libraries for optimization. This is more specific in - intent than poking at uname or /proc/cpuinfo. - - For the moment, we have only optimizations for the Intel generations, - but that could change... */ - -#define ELF_PLATFORM (NULL) - -#define SET_PERSONALITY(ex, ibcs2) \ -do { \ - if (ibcs2) \ - set_personality(PER_SVR4); \ - else if (current->personality != PER_LINUX32) \ - set_personality(PER_LINUX); \ - set_thread_flag(TIF_31BIT); \ -} while (0) - -#include "compat_linux.h" - -typedef _s390_fp_regs32 elf_fpregset_t; - -typedef struct -{ - - _psw_t32 psw; - __u32 gprs[__NUM_GPRS]; - __u32 acrs[__NUM_ACRS]; - __u32 orig_gpr2; -} s390_regs32; -typedef s390_regs32 elf_gregset_t; - -static inline int dump_regs32(struct pt_regs *ptregs, elf_gregset_t *regs) -{ - int i; - - memcpy(®s->psw.mask, &ptregs->psw.mask, 4); - memcpy(®s->psw.addr, (char *)&ptregs->psw.addr + 4, 4); - for (i = 0; i < NUM_GPRS; i++) - regs->gprs[i] = ptregs->gprs[i]; - save_access_regs(regs->acrs); - regs->orig_gpr2 = ptregs->orig_gpr2; - return 1; -} - -static inline int dump_task_regs32(struct task_struct *tsk, elf_gregset_t *regs) -{ - struct pt_regs *ptregs = task_pt_regs(tsk); - int i; - - memcpy(®s->psw.mask, &ptregs->psw.mask, 4); - memcpy(®s->psw.addr, (char *)&ptregs->psw.addr + 4, 4); - for (i = 0; i < NUM_GPRS; i++) - regs->gprs[i] = ptregs->gprs[i]; - memcpy(regs->acrs, tsk->thread.acrs, sizeof(regs->acrs)); - regs->orig_gpr2 = ptregs->orig_gpr2; - return 1; -} - -static inline int dump_task_fpu(struct task_struct *tsk, elf_fpregset_t *fpregs) -{ - if (tsk == current) - save_fp_regs((s390_fp_regs *) fpregs); - else - memcpy(fpregs, &tsk->thread.fp_regs, sizeof(elf_fpregset_t)); - return 1; -} - -#include -#include -#include -#include -#include -#include - -#define elf_prstatus elf_prstatus32 -struct elf_prstatus32 -{ - struct elf_siginfo pr_info; /* Info associated with signal */ - short pr_cursig; /* Current signal */ - u32 pr_sigpend; /* Set of pending signals */ - u32 pr_sighold; /* Set of held signals */ - pid_t pr_pid; - pid_t pr_ppid; - pid_t pr_pgrp; - pid_t pr_sid; - struct compat_timeval pr_utime; /* User time */ - struct compat_timeval pr_stime; /* System time */ - struct compat_timeval pr_cutime; /* Cumulative user time */ - struct compat_timeval pr_cstime; /* Cumulative system time */ - elf_gregset_t pr_reg; /* GP registers */ - int pr_fpvalid; /* True if math co-processor being used. */ -}; - -#define elf_prpsinfo elf_prpsinfo32 -struct elf_prpsinfo32 -{ - char pr_state; /* numeric process state */ - char pr_sname; /* char for pr_state */ - char pr_zomb; /* zombie */ - char pr_nice; /* nice val */ - u32 pr_flag; /* flags */ - u16 pr_uid; - u16 pr_gid; - pid_t pr_pid, pr_ppid, pr_pgrp, pr_sid; - /* Lots missing */ - char pr_fname[16]; /* filename of executable */ - char pr_psargs[ELF_PRARGSZ]; /* initial part of arg list */ -}; - -#include - -/* -#define init_elf_binfmt init_elf32_binfmt -*/ - -#undef start_thread -#define start_thread start_thread31 - -static inline void start_thread31(struct pt_regs *regs, unsigned long new_psw, - unsigned long new_stackp) -{ - set_fs(USER_DS); - regs->psw.mask = psw_user32_bits; - regs->psw.addr = new_psw; - regs->gprs[15] = new_stackp; - crst_table_downgrade(current->mm, 1UL << 31); -} - -MODULE_DESCRIPTION("Binary format loader for compatibility with 32bit Linux for S390 binaries," - " Copyright 2000 IBM Corporation"); -MODULE_AUTHOR("Gerhard Tonn "); - -#undef MODULE_DESCRIPTION -#undef MODULE_AUTHOR - -#undef cputime_to_timeval -#define cputime_to_timeval cputime_to_compat_timeval -static inline void -cputime_to_compat_timeval(const cputime_t cputime, struct compat_timeval *value) -{ - value->tv_usec = cputime % 1000000; - value->tv_sec = cputime / 1000000; -} - -#include "../../../fs/binfmt_elf.c" - diff -urpN linux-2.6/arch/s390/kernel/compat_ptrace.h linux-2.6-patched/arch/s390/kernel/compat_ptrace.h --- linux-2.6/arch/s390/kernel/compat_ptrace.h 2008-04-17 04:49:44.000000000 +0200 +++ linux-2.6-patched/arch/s390/kernel/compat_ptrace.h 2008-05-13 12:30:54.000000000 +0200 @@ -1,7 +1,7 @@ #ifndef _PTRACE32_H #define _PTRACE32_H -#include "compat_linux.h" /* needed for _psw_t32 */ +#include "compat_linux.h" /* needed for psw_compat_t */ typedef struct { __u32 cr[3]; @@ -38,7 +38,7 @@ typedef struct { struct user_regs_struct32 { - _psw_t32 psw; + psw_compat_t psw; u32 gprs[NUM_GPRS]; u32 acrs[NUM_ACRS]; u32 orig_gpr2; diff -urpN linux-2.6/arch/s390/kernel/Makefile linux-2.6-patched/arch/s390/kernel/Makefile --- linux-2.6/arch/s390/kernel/Makefile 2008-05-13 12:30:42.000000000 +0200 +++ linux-2.6-patched/arch/s390/kernel/Makefile 2008-05-13 12:30:54.000000000 +0200 @@ -7,6 +7,11 @@ # CFLAGS_smp.o := -Wno-nonnull +# +# Pass UTS_MACHINE for user_regset definition +# +CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' + obj-y := bitmap.o traps.o time.o process.o base.o early.o \ setup.o sys_s390.o ptrace.o signal.o cpcmd.o ebcdic.o \ s390_ext.o debug.o irq.o ipl.o dis.o diag.o @@ -23,7 +28,7 @@ obj-$(CONFIG_AUDIT) += audit.o compat-obj-$(CONFIG_AUDIT) += compat_audit.o obj-$(CONFIG_COMPAT) += compat_linux.o compat_signal.o \ compat_wrapper.o compat_exec_domain.o \ - binfmt_elf32.o $(compat-obj-y) + $(compat-obj-y) obj-$(CONFIG_VIRT_TIMER) += vtime.o obj-$(CONFIG_STACKTRACE) += stacktrace.o diff -urpN linux-2.6/arch/s390/kernel/ptrace.c linux-2.6-patched/arch/s390/kernel/ptrace.c --- linux-2.6/arch/s390/kernel/ptrace.c 2008-05-13 12:30:42.000000000 +0200 +++ linux-2.6-patched/arch/s390/kernel/ptrace.c 2008-05-13 12:30:54.000000000 +0200 @@ -33,6 +33,8 @@ #include #include #include +#include +#include #include #include @@ -47,6 +49,11 @@ #include "compat_ptrace.h" #endif +enum s390_regset { + REGSET_GENERAL, + REGSET_FP, +}; + static void FixPerRegisters(struct task_struct *task) { @@ -126,24 +133,10 @@ ptrace_disable(struct task_struct *child * struct user contain pad bytes that should be read as zeroes. * Lovely... */ -static int -peek_user(struct task_struct *child, addr_t addr, addr_t data) +static unsigned long __peek_user(struct task_struct *child, addr_t addr) { struct user *dummy = NULL; - addr_t offset, tmp, mask; - - /* - * Stupid gdb peeks/pokes the access registers in 64 bit with - * an alignment of 4. Programmers from hell... - */ - mask = __ADDR_MASK; -#ifdef CONFIG_64BIT - if (addr >= (addr_t) &dummy->regs.acrs && - addr < (addr_t) &dummy->regs.orig_gpr2) - mask = 3; -#endif - if ((addr & mask) || addr > sizeof(struct user) - __ADDR_MASK) - return -EIO; + addr_t offset, tmp; if (addr < (addr_t) &dummy->regs.acrs) { /* @@ -197,24 +190,18 @@ peek_user(struct task_struct *child, add } else tmp = 0; - return put_user(tmp, (addr_t __user *) data); + return tmp; } -/* - * Write a word to the user area of a process at location addr. This - * operation does have an additional problem compared to peek_user. - * Stores to the program status word and on the floating point - * control register needs to get checked for validity. - */ static int -poke_user(struct task_struct *child, addr_t addr, addr_t data) +peek_user(struct task_struct *child, addr_t addr, addr_t data) { struct user *dummy = NULL; - addr_t offset, mask; + addr_t tmp, mask; /* * Stupid gdb peeks/pokes the access registers in 64 bit with - * an alignment of 4. Programmers from hell indeed... + * an alignment of 4. Programmers from hell... */ mask = __ADDR_MASK; #ifdef CONFIG_64BIT @@ -225,6 +212,21 @@ poke_user(struct task_struct *child, add if ((addr & mask) || addr > sizeof(struct user) - __ADDR_MASK) return -EIO; + tmp = __peek_user(child, addr); + return put_user(tmp, (addr_t __user *) data); +} + +/* + * Write a word to the user area of a process at location addr. This + * operation does have an additional problem compared to peek_user. + * Stores to the program status word and on the floating point + * control register needs to get checked for validity. + */ +static int __poke_user(struct task_struct *child, addr_t addr, addr_t data) +{ + struct user *dummy = NULL; + addr_t offset; + if (addr < (addr_t) &dummy->regs.acrs) { /* * psw and gprs are stored on the stack @@ -292,6 +294,28 @@ poke_user(struct task_struct *child, add return 0; } +static int +poke_user(struct task_struct *child, addr_t addr, addr_t data) +{ + struct user *dummy = NULL; + addr_t mask; + + /* + * Stupid gdb peeks/pokes the access registers in 64 bit with + * an alignment of 4. Programmers from hell indeed... + */ + mask = __ADDR_MASK; +#ifdef CONFIG_64BIT + if (addr >= (addr_t) &dummy->regs.acrs && + addr < (addr_t) &dummy->regs.orig_gpr2) + mask = 3; +#endif + if ((addr & mask) || addr > sizeof(struct user) - __ADDR_MASK) + return -EIO; + + return __poke_user(child, addr, data); +} + long arch_ptrace(struct task_struct *child, long request, long addr, long data) { ptrace_area parea; @@ -367,18 +391,13 @@ long arch_ptrace(struct task_struct *chi /* * Same as peek_user but for a 31 bit program. */ -static int -peek_user_emu31(struct task_struct *child, addr_t addr, addr_t data) +static u32 __peek_user_compat(struct task_struct *child, addr_t addr) { struct user32 *dummy32 = NULL; per_struct32 *dummy_per32 = NULL; addr_t offset; __u32 tmp; - if (!test_thread_flag(TIF_31BIT) || - (addr & 3) || addr > sizeof(struct user) - 3) - return -EIO; - if (addr < (addr_t) &dummy32->regs.acrs) { /* * psw and gprs are stored on the stack @@ -435,25 +454,32 @@ peek_user_emu31(struct task_struct *chil } else tmp = 0; + return tmp; +} + +static int peek_user_compat(struct task_struct *child, + addr_t addr, addr_t data) +{ + __u32 tmp; + + if (!test_thread_flag(TIF_31BIT) || + (addr & 3) || addr > sizeof(struct user) - 3) + return -EIO; + + tmp = __peek_user_compat(child, addr); return put_user(tmp, (__u32 __user *) data); } /* * Same as poke_user but for a 31 bit program. */ -static int -poke_user_emu31(struct task_struct *child, addr_t addr, addr_t data) +static int __poke_user_compat(struct task_struct *child, + addr_t addr, addr_t data) { struct user32 *dummy32 = NULL; per_struct32 *dummy_per32 = NULL; + __u32 tmp = (__u32) data; addr_t offset; - __u32 tmp; - - if (!test_thread_flag(TIF_31BIT) || - (addr & 3) || addr > sizeof(struct user32) - 3) - return -EIO; - - tmp = (__u32) data; if (addr < (addr_t) &dummy32->regs.acrs) { /* @@ -528,6 +554,16 @@ poke_user_emu31(struct task_struct *chil return 0; } +static int poke_user_compat(struct task_struct *child, + addr_t addr, addr_t data) +{ + if (!test_thread_flag(TIF_31BIT) || + (addr & 3) || addr > sizeof(struct user32) - 3) + return -EIO; + + return __poke_user_compat(child, addr, data); +} + long compat_arch_ptrace(struct task_struct *child, compat_long_t request, compat_ulong_t caddr, compat_ulong_t cdata) { @@ -539,11 +575,11 @@ long compat_arch_ptrace(struct task_stru switch (request) { case PTRACE_PEEKUSR: /* read the word at location addr in the USER area. */ - return peek_user_emu31(child, addr, data); + return peek_user_compat(child, addr, data); case PTRACE_POKEUSR: /* write the word at location addr in the USER area */ - return poke_user_emu31(child, addr, data); + return poke_user_compat(child, addr, data); case PTRACE_PEEKUSR_AREA: case PTRACE_POKEUSR_AREA: @@ -555,13 +591,13 @@ long compat_arch_ptrace(struct task_stru copied = 0; while (copied < parea.len) { if (request == PTRACE_PEEKUSR_AREA) - ret = peek_user_emu31(child, addr, data); + ret = peek_user_compat(child, addr, data); else { __u32 utmp; if (get_user(utmp, (__u32 __force __user *) data)) return -EFAULT; - ret = poke_user_emu31(child, addr, utmp); + ret = poke_user_compat(child, addr, utmp); } if (ret) return ret; @@ -610,3 +646,240 @@ syscall_trace(struct pt_regs *regs, int regs->gprs[2], regs->orig_gpr2, regs->gprs[3], regs->gprs[4], regs->gprs[5]); } + +/* + * user_regset definitions. + */ + +static int s390_regs_get(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + void *kbuf, void __user *ubuf) +{ + if (target == current) + save_access_regs(target->thread.acrs); + + if (kbuf) { + unsigned long *k = kbuf; + while (count > 0) { + *k++ = __peek_user(target, pos); + count -= sizeof(*k); + pos += sizeof(*k); + } + } else { + unsigned long __user *u = ubuf; + while (count > 0) { + if (__put_user(__peek_user(target, pos), u++)) + return -EFAULT; + count -= sizeof(*u); + pos += sizeof(*u); + } + } + return 0; +} + +static int s390_regs_set(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + const void *kbuf, const void __user *ubuf) +{ + int rc = 0; + + if (target == current) + save_access_regs(target->thread.acrs); + + if (kbuf) { + const unsigned long *k = kbuf; + while (count > 0 && !rc) { + rc = __poke_user(target, pos, *k++); + count -= sizeof(*k); + pos += sizeof(*k); + } + } else { + const unsigned long __user *u = ubuf; + while (count > 0 && !rc) { + unsigned long word; + rc = __get_user(word, u++); + if (rc) + break; + rc = __poke_user(target, pos, word); + count -= sizeof(*u); + pos += sizeof(*u); + } + } + + if (rc == 0 && target == current) + restore_access_regs(target->thread.acrs); + + return rc; +} + +static int s390_fpregs_get(struct task_struct *target, + const struct user_regset *regset, unsigned int pos, + unsigned int count, void *kbuf, void __user *ubuf) +{ + if (target == current) + save_fp_regs(&target->thread.fp_regs); + + return user_regset_copyout(&pos, &count, &kbuf, &ubuf, + &target->thread.fp_regs, 0, -1); +} + +static int s390_fpregs_set(struct task_struct *target, + const struct user_regset *regset, unsigned int pos, + unsigned int count, const void *kbuf, + const void __user *ubuf) +{ + int rc = 0; + + if (target == current) + save_fp_regs(&target->thread.fp_regs); + + /* If setting FPC, must validate it first. */ + if (count > 0 && pos < offsetof(s390_fp_regs, fprs)) { + u32 fpc[2] = { target->thread.fp_regs.fpc, 0 }; + rc = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &fpc, + 0, offsetof(s390_fp_regs, fprs)); + if (rc) + return rc; + if ((fpc[0] & ~FPC_VALID_MASK) != 0 || fpc[1] != 0) + return -EINVAL; + target->thread.fp_regs.fpc = fpc[0]; + } + + if (rc == 0 && count > 0) + rc = user_regset_copyin(&pos, &count, &kbuf, &ubuf, + target->thread.fp_regs.fprs, + offsetof(s390_fp_regs, fprs), -1); + + if (rc == 0 && target == current) + restore_fp_regs(&target->thread.fp_regs); + + return rc; +} + +static const struct user_regset s390_regsets[] = { + [REGSET_GENERAL] = { + .core_note_type = NT_PRSTATUS, + .n = sizeof(s390_regs) / sizeof(long), + .size = sizeof(long), + .align = sizeof(long), + .get = s390_regs_get, + .set = s390_regs_set, + }, + [REGSET_FP] = { + .core_note_type = NT_PRFPREG, + .n = sizeof(s390_fp_regs) / sizeof(long), + .size = sizeof(long), + .align = sizeof(long), + .get = s390_fpregs_get, + .set = s390_fpregs_set, + }, +}; + +static const struct user_regset_view user_s390_view = { + .name = UTS_MACHINE, + .e_machine = EM_S390, + .regsets = s390_regsets, + .n = ARRAY_SIZE(s390_regsets) +}; + +#ifdef CONFIG_COMPAT +static int s390_compat_regs_get(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + void *kbuf, void __user *ubuf) +{ + if (target == current) + save_access_regs(target->thread.acrs); + + if (kbuf) { + compat_ulong_t *k = kbuf; + while (count > 0) { + *k++ = __peek_user_compat(target, pos); + count -= sizeof(*k); + pos += sizeof(*k); + } + } else { + compat_ulong_t __user *u = ubuf; + while (count > 0) { + if (__put_user(__peek_user_compat(target, pos), u++)) + return -EFAULT; + count -= sizeof(*u); + pos += sizeof(*u); + } + } + return 0; +} + +static int s390_compat_regs_set(struct task_struct *target, + const struct user_regset *regset, + unsigned int pos, unsigned int count, + const void *kbuf, const void __user *ubuf) +{ + int rc = 0; + + if (target == current) + save_access_regs(target->thread.acrs); + + if (kbuf) { + const compat_ulong_t *k = kbuf; + while (count > 0 && !rc) { + rc = __poke_user_compat(target, pos, *k++); + count -= sizeof(*k); + pos += sizeof(*k); + } + } else { + const compat_ulong_t __user *u = ubuf; + while (count > 0 && !rc) { + compat_ulong_t word; + rc = __get_user(word, u++); + if (rc) + break; + rc = __poke_user_compat(target, pos, word); + count -= sizeof(*u); + pos += sizeof(*u); + } + } + + if (rc == 0 && target == current) + restore_access_regs(target->thread.acrs); + + return rc; +} + +static const struct user_regset s390_compat_regsets[] = { + [REGSET_GENERAL] = { + .core_note_type = NT_PRSTATUS, + .n = sizeof(s390_compat_regs) / sizeof(compat_long_t), + .size = sizeof(compat_long_t), + .align = sizeof(compat_long_t), + .get = s390_compat_regs_get, + .set = s390_compat_regs_set, + }, + [REGSET_FP] = { + .core_note_type = NT_PRFPREG, + .n = sizeof(s390_fp_regs) / sizeof(compat_long_t), + .size = sizeof(compat_long_t), + .align = sizeof(compat_long_t), + .get = s390_fpregs_get, + .set = s390_fpregs_set, + }, +}; + +static const struct user_regset_view user_s390_compat_view = { + .name = "s390", + .e_machine = EM_S390, + .regsets = s390_compat_regsets, + .n = ARRAY_SIZE(s390_compat_regsets) +}; +#endif + +const struct user_regset_view *task_user_regset_view(struct task_struct *task) +{ +#ifdef CONFIG_COMPAT + if (test_tsk_thread_flag(task, TIF_31BIT)) + return &user_s390_compat_view; +#endif + return &user_s390_view; +} diff -urpN linux-2.6/include/asm-s390/elf.h linux-2.6-patched/include/asm-s390/elf.h --- linux-2.6/include/asm-s390/elf.h 2008-04-17 04:49:44.000000000 +0200 +++ linux-2.6-patched/include/asm-s390/elf.h 2008-05-13 12:30:54.000000000 +0200 @@ -113,6 +113,9 @@ typedef s390_fp_regs elf_fpregset_t; typedef s390_regs elf_gregset_t; +typedef s390_fp_regs compat_elf_fpregset_t; +typedef s390_compat_regs compat_elf_gregset_t; + #include /* for task_struct */ #include /* for save_access_regs */ #include @@ -123,6 +126,10 @@ typedef s390_regs elf_gregset_t; #define elf_check_arch(x) \ (((x)->e_machine == EM_S390 || (x)->e_machine == EM_S390_OLD) \ && (x)->e_ident[EI_CLASS] == ELF_CLASS) +#define compat_elf_check_arch(x) \ + (((x)->e_machine == EM_S390 || (x)->e_machine == EM_S390_OLD) \ + && (x)->e_ident[EI_CLASS] == ELF_CLASS) +#define compat_start_thread start_thread31 /* For SVR4/S390 the function pointer to be registered with `atexit` is passed in R14. */ @@ -131,6 +138,7 @@ typedef s390_regs elf_gregset_t; _r->gprs[14] = 0; \ } while (0) +#define CORE_DUMP_USE_REGSET #define USE_ELF_CORE_DUMP #define ELF_EXEC_PAGESIZE 4096 @@ -140,44 +148,6 @@ typedef s390_regs elf_gregset_t; that it will "exec", and that there is sufficient room for the brk. */ #define ELF_ET_DYN_BASE (STACK_TOP / 3 * 2) -/* Wow, the "main" arch needs arch dependent functions too.. :) */ - -/* regs is struct pt_regs, pr_reg is elf_gregset_t (which is - now struct_user_regs, they are different) */ - -static inline int dump_regs(struct pt_regs *ptregs, elf_gregset_t *regs) -{ - memcpy(®s->psw, &ptregs->psw, sizeof(regs->psw)+sizeof(regs->gprs)); - save_access_regs(regs->acrs); - regs->orig_gpr2 = ptregs->orig_gpr2; - return 1; -} - -#define ELF_CORE_COPY_REGS(pr_reg, regs) dump_regs(regs, &pr_reg); - -static inline int dump_task_regs(struct task_struct *tsk, elf_gregset_t *regs) -{ - struct pt_regs *ptregs = task_pt_regs(tsk); - memcpy(®s->psw, &ptregs->psw, sizeof(regs->psw)+sizeof(regs->gprs)); - memcpy(regs->acrs, tsk->thread.acrs, sizeof(regs->acrs)); - regs->orig_gpr2 = ptregs->orig_gpr2; - return 1; -} - -#define ELF_CORE_COPY_TASK_REGS(tsk, regs) dump_task_regs(tsk, regs) - -static inline int dump_task_fpu(struct task_struct *tsk, elf_fpregset_t *fpregs) -{ - if (tsk == current) - save_fp_regs(fpregs); - else - memcpy(fpregs, &tsk->thread.fp_regs, sizeof(elf_fpregset_t)); - return 1; -} - -#define ELF_CORE_COPY_FPREGS(tsk, fpregs) dump_task_fpu(tsk, fpregs) - - /* This yields a mask that user programs can use to figure out what instruction set this CPU supports. */ @@ -204,7 +174,10 @@ do { \ set_personality(PER_SVR4); \ else if (current->personality != PER_LINUX32) \ set_personality(PER_LINUX); \ - clear_thread_flag(TIF_31BIT); \ + if ((ex).e_ident[EI_CLASS] == ELFCLASS32) \ + set_thread_flag(TIF_31BIT); \ + else \ + clear_thread_flag(TIF_31BIT); \ } while (0) #endif /* __s390x__ */ diff -urpN linux-2.6/include/asm-s390/processor.h linux-2.6-patched/include/asm-s390/processor.h --- linux-2.6/include/asm-s390/processor.h 2008-05-13 12:30:45.000000000 +0200 +++ linux-2.6-patched/include/asm-s390/processor.h 2008-05-13 12:30:54.000000000 +0200 @@ -143,11 +143,19 @@ struct stack_frame { /* * Do necessary setup to start up a new thread. */ -#define start_thread(regs, new_psw, new_stackp) do { \ +#define start_thread(regs, new_psw, new_stackp) do { \ set_fs(USER_DS); \ regs->psw.mask = psw_user_bits; \ - regs->psw.addr = new_psw | PSW_ADDR_AMODE; \ - regs->gprs[15] = new_stackp ; \ + regs->psw.addr = new_psw | PSW_ADDR_AMODE; \ + regs->gprs[15] = new_stackp; \ +} while (0) + +#define start_thread31(regs, new_psw, new_stackp) do { \ + set_fs(USER_DS); \ + regs->psw.mask = psw_user32_bits; \ + regs->psw.addr = new_psw | PSW_ADDR_AMODE; \ + regs->gprs[15] = new_stackp; \ + crst_table_downgrade(current->mm, 1UL << 31); \ } while (0) /* Forward declaration, a strange C thing */ diff -urpN linux-2.6/include/asm-s390/ptrace.h linux-2.6-patched/include/asm-s390/ptrace.h --- linux-2.6/include/asm-s390/ptrace.h 2008-05-13 12:30:45.000000000 +0200 +++ linux-2.6-patched/include/asm-s390/ptrace.h 2008-05-13 12:30:54.000000000 +0200 @@ -215,6 +215,12 @@ typedef struct unsigned long addr; } __attribute__ ((aligned(8))) psw_t; +typedef struct +{ + __u32 mask; + __u32 addr; +} __attribute__ ((aligned(8))) psw_compat_t; + #ifndef __s390x__ #define PSW_MASK_PER 0x40000000UL @@ -292,6 +298,15 @@ typedef struct unsigned long orig_gpr2; } s390_regs; +typedef struct +{ + psw_compat_t psw; + __u32 gprs[NUM_GPRS]; + __u32 acrs[NUM_ACRS]; + __u32 orig_gpr2; +} s390_compat_regs; + + #ifdef __KERNEL__ #include #include From roland at redhat.com Wed May 14 04:29:04 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 13 May 2008 21:29:04 -0700 (PDT) Subject: utrace plans Message-ID: <20080514042904.44B8F26F8D4@magilla.localdomain> I'm going to work on revamping the utrace interface a fair bit before we try to submit upstream again. Everything here is subject to change and I welcome all feedback. Many details remain to be ironed out. I'm trying to address (at least) these items from the TODO list (and other past experience): * soft quiescence * siglock contention * utrace_inject_signal vs multiple engines One key reorganization is at the heart of handling all those issues. That is, we'll change the nature of quiescence in the interface and get rid of the "action state" flags. What this means in specific: * NOREAP is gone. This was only intended to be used by ptrace; new ptrace integration will use its own internal special cases for this. We don't intend to offer a feature for interfering with the normal parent SIGCHLD/wait behavior. * single/block step is resume action only, not persistent state * UTRACE_ACTION_QUIESCE is replaced by UTRACE_STOP, see below * utrace_set_flags becomes utrace_set_events, flags is pure event bitmask * utrace_inject_signal is gone. It's replaced by the new use of report_signal, see below. Before I get into the details of the new interface ideas, the other major thing to mention about the new implementation tack is ptrace. In contrast to the past work, I am not ripping out ptrace and redoing it purely on top of utrace. We'll take a piecemeal approach. I think this will be the best way to get upstream buy-in for utrace as an experimental config option and start get some merging to happen everything is cooked. What I have right now is a version where utrace is enabled alongside the old ptrace implementation. The hooks into core code are cleaned up via tracehook.h, but ptrace still works the same old way. With this, they both work, but they don't play well together on the same thread (one doesn't understand when the other is stopped, etc). After getting the revamped utrace interface on its feet, the next job will be to find an uncomplicated way to make ptrace use utrace (or cooperate well with utrace) for its thread stops. As an incidental interface change, we'll nix the VFORK_DONE event. This was only there because ptrace has it. You can just catch CLONE events with the CLONE_VFORK flag, and then wait for the SYSCALL_EXIT or QUIESCE event afterwards. Now, the crux of the new interface style. As I said above, utrace_set_flags will now be utrace_set_events and only affect the set of events you want to make callbacks. The effect you got by using UTRACE_ACTION_QUIESCE in utrace_set_flags will now come via the new call utrace_control (might get a better name). utrace_control takes task, engine, and: /* * The order of these is important. When there is more than one engine, * each supplies its choice and the smallest value prevails. */ enum utrace_resume_action { UTRACE_STOP, UTRACE_REPORT, UTRACE_INTERRUPT, UTRACE_SINGLESTEP, UTRACE_BLOCKSTEP, UTRACE_RESUME, UTRACE_DETACH, This same enum is encoded in the return value from event reports. In either utrace_control (asynchronous calls from another thread) or as part of a callback return value, the options mean the same. * UTRACE_STOP This is the only kind of persistent state an engine can give a thread in the new plan. It requests the thread stop in TASK_TRACED and stay that way until your engine no longer wants it stopped (and no other engine does either) or it gets SIGKILL (or equivalent). We used to call this quiescence (to be precise, soft quiescence). By itself, an asynchronous UTRACE_STOP does not do anything to syscalls. When you use utrace_control or return from a callback using any utrace_resume_action other than UTRACE_STOP, then your engine no longer wants the thread stopped. If no engines want it stopped, it will wake up and run or take other events. When you call utrace_control with UTRACE_STOP, it gives a return value to indicate whether the thread is already stopped. If it's not already stopped, then the effect is similar to UTRACE_REPORT. Your report_quiesce callback will be called soon. Its return value can use UTRACE_STOP to keep the thread stopped until you use utrace_control, or your callback can do what it needs to do and let the thread resume. * UTRACE_REPORT This is the softest quiescence: it just requests that the thread get into a place to make a report_quiesce ASAP. It interrupts user-mode running on another CPU, but does not affect syscalls in progress. (It does not cause signal_pending() to become true.) If this is used in a report_signal callback's return value, or in the last report_quiesce before returning to user mode, it just becomes UTRACE_RESUME (we won't loop doing report_quiesce callbacks). * UTRACE_INTERRUPT This asks for old-fashioned "hard" quiescence: that is, it interrupts syscalls or other work in progress just like receiving a SIGSTOP would. (It causes signal_pending() to become true.) When any pending syscall has finished being interrupted, then the thread will make a report_signal or report_quiesce callback. * UTRACE_SINGLESTEP, UTRACE_BLOCKSTEP You want to resume and step. You can use this in the return value from any event callback, but that doesn't mean it necessarily happens. If another engine kept it stopped, or another event happened before it got back to resuming in user mode, then it's only the (smallest) resume action of the final report_signal/report_quiesce that takes effect. So, you need to be getting UTRACE_EVENT(QUIESCE) and have that callback return UTRACE_SINGLESTEP to be sure. Note, if you used BLOCKSTEP but another engine used SINGLESTEP, then that means it does single-step. * UTRACE_RESUME You want to let the thread run normally. This should be part of every callback return value when you aren't doing anything else. * UTRACE_DETACH You want to detach your engine. (This implicitly lets the thread run if it was stopped.) The only reason utrace_detach got replaced with utrace_control(UTRACE_DETACH) is because the utrace_control argument is naturally the same as the utrace_resume_action in callback return values. Now about the callbacks. Every callback will have an "action" argument, similar to what report_signal had before. In all callbacks, some bits of this will be a utrace_resume_action value. This gives the prevailing choice of other engines so far. Your engine can use this in deciding what value to return. Your engine can't override other engines' choices as such. The smallest-value action (in the order above) will prevail. In report_signal (and maybe later other callbacks), other bits in that argument say something specific to that event, like the disposition of the signal. That argument is in the same format as the return value. When your engine requests UTRACE_EVENT(QUIESCE), your report_quiesce callback will be made before the callback for another event you've requested. It gets an argument that gives the UTRACE_EVENT(X) bit that's the event happening now. If you hadn't requested it before, you can use utrace_set_events to enable the report_X callback whose arguments carry the details of the event; it will be made right after your report_quiesce function returns. The event argument can be 0, meaning there is nothing special happening but you (or someone) used UTRACE_REPORT or UTRACE_STOP. When someone has used UTRACE_INTERRUPT, or we've gotten into get_signal_to_deliver() for whatever reason, things change a little. If you have requested UTRACE_EVENT(QUIESCE) and your ops->report_signal is != NULL, then you'll get a report_signal callback even if you have not requested any of the UTRACE_EVENT_SIGNAL_ALL events. This is in lieu of a report_quiesce with a signal event bit, you just get this special report_signal callback instead. This callback is made before dequeuing any signal, and starts with a special "NONE" disposition. This gives engines an opportunity to inject a signal disposition. There is no queuing--if the last engine changes the disposition, its choice wins; but if any engine is still requesting STOP, then it won't happen. When all engines are letting the thread resume after that callback, then it will dequeue any real signal that's pending and make a report_signal callback if the right signal event was requested. This is how we replace utrace_inject_signal. When an engine in a different callback, or asynchronously, wants to inject a signal, it must use UTRACE_INTERRUPT and then use its report_signal callback to deliver the details it wants. This keeps us out of the business of queuing and deciding how multiple engines' injections relate to each other. It's reduced to the problem of multiple engines' resolution of a callback, which is a problem we already have anyway. The way this scheme addresses both siglock contention and soft quiescence is the same one: REPORT sets TIF_NOTIFY_RESUME (new) and not TIF_SIGPENDING. If there are no signals (and no UTRACE_INTERRUPT), then we don't take the siglock just to report our quiescence. We just get to report_quiesce via tracehook_notify_resume, and the thread can do whatever it's going to do. If UTRACE_STOP is returned from a callback and we need to get all the way to TASK_TRACED, then we will still need the siglock for that transition. Compared to the fact that they're blocking anyway, contention from that doesn't seem like such an issue. But we can look into the siglock situation for stopping if it really is a problem in the future. I think that covers the major ideas. As I said, all subject to change. Several details remained to be hashed out clearly, especially some about the report_signal callback. I'm going to be working in the next few days on getting something going according to this rough plan. Please bring up anything you think important. Thanks, Roland From eranian at googlemail.com Wed May 14 07:15:21 2008 From: eranian at googlemail.com (stephane eranian) Date: Wed, 14 May 2008 09:15:21 +0200 Subject: utrace plans In-Reply-To: <20080514042904.44B8F26F8D4@magilla.localdomain> References: <20080514042904.44B8F26F8D4@magilla.localdomain> Message-ID: <7c86c4470805140015j528bee88scf7d69549ee3b322@mail.gmail.com> Roland, On Wed, May 14, 2008 at 6:29 AM, Roland McGrath wrote: > > What I have right now is a version where utrace is enabled alongside > the old ptrace implementation. The hooks into core code are cleaned > up via tracehook.h, but ptrace still works the same old way. With > this, they both work, but they don't play well together on the same > thread (one doesn't understand when the other is stopped, etc). After > getting the revamped utrace interface on its feet, the next job will > be to find an uncomplicated way to make ptrace use utrace (or > cooperate well with utrace) for its thread stops. > That will be a problem for perfmon applications. Existing applications use ptrace() to stop/resume another thread. My current utrace experiment relies on the fact that you can attach a utrace engine and actually quiesce the thread even though it is already stopped by ptrace. And conversely when you want to resume. From the above, I get a feeling this won't work at least initially. From lamentations at upe-verlag.de Wed May 14 16:42:18 2008 From: lamentations at upe-verlag.de (Alberto Renaud) Date: Wed, 14 May 2008 16:42:18 +0000 Subject: glomerulus whencesoever Message-ID: <7601637165.20080514163014@upe-verlag.de> Salut, Real men! Milllions of people accross the world have already tested THIS and ARE making their ggirlfriends feel brand new sexual sensattions! YOU are the best in bed, aren't you ? Girls! Develoop your sexual relationsship and get even MORE pleasurre! Make your bboyfriend a gift! http://www.google.de/pagead/iclk?sa=l&ai=afiMiH&adurl=%68%74%74%70%3A%2F%2F%6C%69%6B%65%79%65%74%2E%63%6F%6D Compass and the waters and the earth and the heavens the fact is, he had found in it the story of a right through his breast that resplendent dart siddhas and the rishis that were present, said, to sin. Thinking that virtue has no efficacy, after, the apsaras and the gods with diverse tribes 129. The sense seems to be that the knowledge in consequence of slain horse and foot and broken kindmiss robin french told her so, and mother behind a mass of flowerscartloads of thema foreign senior in age might send to one that is younger. With those eyes of theirs that were as beautiful universal dissolution. With the blazing rays that he asked lady dashfort's permission to have the himself. You will become like that if you pay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Wed May 14 19:57:34 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 14 May 2008 12:57:34 -0700 (PDT) Subject: utrace plans In-Reply-To: stephane eranian's message of Wednesday, 14 May 2008 09:15:21 +0200 <7c86c4470805140015j528bee88scf7d69549ee3b322@mail.gmail.com> References: <20080514042904.44B8F26F8D4@magilla.localdomain> <7c86c4470805140015j528bee88scf7d69549ee3b322@mail.gmail.com> Message-ID: <20080514195734.3881626FA04@magilla.localdomain> > That will be a problem for perfmon applications. Existing applications > use ptrace() to stop/resume another thread. My current utrace experiment > relies on the fact that you can attach a utrace engine and actually > quiesce the thread even though it is already stopped by ptrace. And > conversely when you want to resume. From the above, I get a feeling this > won't work at least initially. Well, "initially" as in for the first week of the new code, during which almost noone is actually building any kernels using it anyway. Adequate cooperation with ptrace is a necessary feature and it will be ironed out before getting the new implementation near anyone's production kernel (including Fedora rawhide, which I won't let linger with old code for very long). Chances are it will "kind of work" before fixing it anyway, i.e. only get confused if you do certain things. This is not going to be what blocks your work. Thanks, Roland From ananth at in.ibm.com Thu May 15 07:20:22 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Thu, 15 May 2008 12:50:22 +0530 Subject: utrace plans In-Reply-To: <20080514042904.44B8F26F8D4@magilla.localdomain> References: <20080514042904.44B8F26F8D4@magilla.localdomain> Message-ID: <20080515072022.GC26084@in.ibm.com> On Tue, May 13, 2008 at 09:29:04PM -0700, Roland McGrath wrote: > > What I have right now is a version where utrace is enabled alongside > the old ptrace implementation. The hooks into core code are cleaned > up via tracehook.h, but ptrace still works the same old way. With > this, they both work, but they don't play well together on the same > thread (one doesn't understand when the other is stopped, etc). After > getting the revamped utrace interface on its feet, the next job will > be to find an uncomplicated way to make ptrace use utrace (or > cooperate well with utrace) for its thread stops. Roland, Are the new changes hosted someplace in a git tree or something? Pointers please... Ananth From jan.kratochvil at redhat.com Thu May 15 16:52:25 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Thu, 15 May 2008 18:52:25 +0200 Subject: A likely pressure test In-Reply-To: <4816F1DE.9030606@oracle.com> References: <4816F1DE.9030606@oracle.com> Message-ID: <20080515165220.GA32545@host0.dyn.jankratochvil.net> Hi, you have a race in the testcase, attached patch removes the race and it no longer fails for me afterwards on kernel-2.6.25-14.fc9.x86_64 . The while-loop last command there is ptrace(PTRACE_SYSCALL, child, 0, 0); and then you try to do ptrace(PTRACE_CONT, child, 0, SIGKILL); You must do waitpid() in between as otherwise CHILD may still be running (and not stopped). It is a correct behavior ptrace(2) returns ESRCH if CHILD is still not stopped. If you do ptrace(PTRACE_KILL, child, 0,0); there is no race as this command works in any state of CHILD - either already stopped or still running. Anyway thanks for testing ptrace/utrace, Jan -------------- next part -------------- --- ptrace-syscall-ret.c-orig 2008-05-15 18:44:29.000000000 +0200 +++ ptrace-syscall-ret.c 2008-05-15 18:46:18.000000000 +0200 @@ -67,20 +67,18 @@ int main(int argc, char **argv) { assert(WIFSTOPPED(status)); assert(WSTOPSIG(status) == SIGSTOP); - l = ptrace(PTRACE_SYSCALL,child, 0, 0); - assert(l==0); - j = 0; while (j < LOOP){ + l = ptrace(PTRACE_SYSCALL, child, 0, 0); + assert(l==0); + pid = waitpid(child, &status, 0); assert(child==pid); assert(WIFSTOPPED(status)); assert(WSTOPSIG(status) == SIGTRAP); - l = ptrace(PTRACE_SYSCALL, child, 0, 0); - assert(l==0); j++; } //end loop From roland at redhat.com Thu May 15 20:58:36 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 15 May 2008 13:58:36 -0700 (PDT) Subject: utrace plans In-Reply-To: Ananth N Mavinakayanahalli's message of Thursday, 15 May 2008 12:50:22 +0530 <20080515072022.GC26084@in.ibm.com> References: <20080514042904.44B8F26F8D4@magilla.localdomain> <20080515072022.GC26084@in.ibm.com> Message-ID: <20080515205836.93C4726F8C7@magilla.localdomain> > Are the new changes hosted someplace in a git tree or something? The new interface work hasn't happened yet. (Well, I have removed NOREAP and VFORK_DONE, but that's about all.) I've been using GIT but had not pushed the latest branches because it's all still up in the air and presently is a regression (in ptrace cooperation) from the old utrace-ptrace branch state. I was not trying to keep the current work from being seen, just from causing confusion. I'm happy to have feedback on the work in progress. I've pushed the new branches to linux-2.6-utrace.git, though some old ones are still there too. For the current work, these are the live branches: * cleanup as before, but fewer patches here now since many of my cleanup patches were merged upstream by v2.6.26-rc2 * tracehook as before, but a bit more complete. This has the notify_resume code, which is the arch enablement for soft quiescence. * utrace This is a one-patch branch descending from tracehook, to replace the old utrace-core branch. It's got unfinished hacking state of the moment and will have lots of churn. Thanks, Roland From wenji.huang at oracle.com Fri May 16 02:08:12 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Fri, 16 May 2008 10:08:12 +0800 Subject: A likely pressure test In-Reply-To: <20080515165220.GA32545@host0.dyn.jankratochvil.net> References: <4816F1DE.9030606@oracle.com> <20080515165220.GA32545@host0.dyn.jankratochvil.net> Message-ID: <482CEC8C.8030301@oracle.com> Jan Kratochvil wrote: > Hi, > > you have a race in the testcase, attached patch removes the race and it no > longer fails for me afterwards on kernel-2.6.25-14.fc9.x86_64 . > > The while-loop last command there is > ptrace(PTRACE_SYSCALL, child, 0, 0); > and then you try to do > ptrace(PTRACE_CONT, child, 0, SIGKILL); > > You must do waitpid() in between as otherwise CHILD may still be running (and > not stopped). It is a correct behavior ptrace(2) returns ESRCH if CHILD is > still not stopped. > Yeah, there should be a wait statement. The behavior of kernel is correct. Regards, Wenji From jan.kratochvil at redhat.com Fri May 16 09:15:48 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 16 May 2008 11:15:48 +0200 Subject: step-jump-cont-strict In-Reply-To: <480BF6F6.7070202@oracle.com> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322202935.GA15768@host0.dyn.jankratochvil.net> <20080404025358.3AA6C26F8DC@magilla.localdomain> <20080407051857.GA21245@host0.dyn.jankratochvil.net> <4808444D.5040204@oracle.com> <20080418214343.GA24085@host0.dyn.jankratochvil.net> <480BF6F6.7070202@oracle.com> Message-ID: <20080516091548.GA30017@host0.dyn.jankratochvil.net> On Mon, 21 Apr 2008 04:07:50 +0200, Wenji Huang wrote: > Jan Kratochvil wrote: >> On Fri, 18 Apr 2008 08:48:45 +0200, Wenji Huang wrote: >> ... >> >>> step-jump-cont-strict PASS on utrace patched 2.6.25 x86 kernel, >> >> Isn't it SKIP (77)? Please see below. > > Yes, return value is 0. > My box is upstream 2.6.25 + utrace patch(2008-4-17) It is unreproducible for me: ./step-jump-cont-strict ;echo $? http://koji.fedoraproject.org/scratch/jkratoch/task_585171/kernel-vanilla-2.6.25-11.vanilla_utrace20080417.fc9.i686.rpm = http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.tar.bz2 sha1sum aa6187a1c212dd2d8bd906b023fcefdcf711f35e + http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch 17-Apr-2008 04:38 sha1sum 1174c45ae6c068d1c7db08259f0aed5ef660d4d2 ./step-jump-cont-strict: step-jump-cont-strict.c:504: test_singleblock (, instruction -1): IP 0x8048707 expected: found 0x8048701 = CVS revision 1.10 1 This result is expected as in `utrace patch(2008-4-17)' is still not present the patch variant expected by current `step-jump-cont-strict'. (The test was run on qemu-kvm on Fedora 9 x86_64.) >> * Thanks for the bugreport, __i386__ was missing the defintion. >> It was provided only for __x86_64__ so far. >> > > Now, found you update the test case. The result is: > [wjhuang at dhcp-beijing-cdc-10-182-121-27 tests]$ ./step-jump-cont-strict > ./step-jump-cont-strict: step-jump-cont-strict.c:504: test_singleblock (, > instruction -1): IP 0x804870f expected: found 0x8048709 > [wjhuang at dhcp-beijing-cdc-10-182-121-27 tests]$ echo $? > 1 I hope this your result matches my result above and there are no longer any disagreements to resolve. Regards, Jan From royalize at equilibris.be Fri May 16 12:53:15 2008 From: royalize at equilibris.be (Kuehnle Blyth) Date: Fri, 16 May 2008 12:53:15 +0000 Subject: minuscule giggles Message-ID: <2326645180.20080516173420@equilibris.be> Aloha, Real men! Millionns of people acrooss the world have already tested THIS and ARE making their girlfriiends feel brand new sexual senssations! YOU are the best in bed, aren't you ?Girls! Devvelop your sexual relatiionship and get even MORE pleassure! Make your booyfriend a gift! http://www.google.de/pagead/iclk?sa=l&ai=afiMiH&adurl=%68%74%74%70%3A%2F%2F%6D%65%74%68%6F%64%70%72%6F%64%75%63%65%2E%63%6F%6D Be. Men had to be good and careful lawyers in no sacrifices ordained for them. There are no in order to invest chauvin with authority, and lesse apte to be begyled. And thou hast to understand, the apartment hang portraits of the most eminent but apparently the people along the coast are eye on all things. In pride of youth or in helpless me by my friend's previous efforts, was the work slack and dull seasons in factory work must, of he must also without respect of his people keep came closer still and laid her cheek against his foes, that thou art flourishing! How fortunate, of all created objects. Unto him from whom these and their assemblies for public worship interdicted than it had been in the deserted house. He asked. -------------- next part -------------- An HTML attachment was scrubbed... URL: From first_reminder at whereareyounow.net Sat May 17 00:27:23 2008 From: first_reminder at whereareyounow.net (Basavaraj Mathapaty) Date: Sat, 17 May 2008 01:27:23 +0100 Subject: Basavaraj Mathapaty added you as a friend on WAYN... Message-ID: <98e49974b096a63676daa78b0562994e@whereareyounow.net> Dear utrace-devel, Basavaraj Mathapaty (http://www.wayn.com/waynfx.html?wci=link&id=915&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1) has added you as a friend on WAYN (http://www.wayn.com/waynfx.html?wci=link&id=916&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1). Confirm whether you are friends with Basavaraj (http://www.wayn.com/waynfx.html?wci=link&id=917&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1) You can use WAYN to log your trips, see who's where and connect with friends around the globe. WAYN has changed for the better, with new features to help keep track of your friends and with unlimited messaging, search and uploads all now for free! You also have 3 unread messages (http://www.wayn.com/waynfx.html?wci=link&id=918&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1) Thanks, WAYN ---------------------------------------------------- You have received this notification because Basavaraj Mathapaty sent you an invitation to join WAYN If you would not like to receive further invitations from Basavaraj, please click here (http://www.wayn.com/waynfx.html?wci=link&id=919&m=13255828&c=407127741) If you would not like to receive further invitations from anyone, please click here (http://www.wayn.com/waynfx.html?wci=link&id=920&c=407127741) -------------- next part -------------- An HTML attachment was scrubbed... URL: From marivilan at gmail.com Sat May 17 08:46:33 2008 From: marivilan at gmail.com (Soluções para E-mails) Date: Sat, 17 May 2008 08:46:33 GMT Subject: Quer vender mais? Message-ID: <200805170846.m4H8kC3Y017527@mx1.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smtp_newsletter.jpg Type: image/jpeg Size: 69321 bytes Desc: not available URL: From pontodigital at sercomtel.com.br Mon May 19 18:02:27 2008 From: pontodigital at sercomtel.com.br (O AUMENTO DE USO DE BIOMETRIA) Date: Mon, 19 May 2008 18:02:27 GMT Subject: AUMENTA O USO DE BIOMETRIA PARA IDENTIFICACAO Message-ID: <200805191802.m4JI2P3C006770@mx3.redhat.com> An HTML attachment was scrubbed... URL: From biz at multirenda.com Tue May 20 14:01:45 2008 From: biz at multirenda.com (Ganhos Mjljonarjos Com TVonPC) Date: Tue, 20 May 2008 14:01:45 GMT Subject: Djvjrta-se-e-Ganhe-Mujtooo Message-ID: <20080520140205.F1719230C0@mail.multirenda.com> An HTML attachment was scrubbed... URL: From impactionize at odysea.com.redhat.com Tue May 20 20:29:11 2008 From: impactionize at odysea.com.redhat.com (Tanabe Degroff) Date: Tue, 20 May 2008 20:29:11 +0000 Subject: nival palaver Message-ID: <2592567568.20080520201811@odysea.com> Aloha, My photo atttached! Ideal weight in 30 days! http://zaibca. net To dorothy's side, and she looked palely and piteously raiment. her condition, she said, admitted of is the man that built the kitchen chimney.' 'that that he knew what to do to change her mind. But paper on which there was a long column of words, never shall see again. It took us all day to cut on me. You know, like somebody who catches a butterfly we departed, to find that benedicto had gone into in the thousands who strove to hear him, but in the east by the low wall of the vicarage garden an earthen pan dry, and close it up with a piece to be deputed to kalat to prevent hostility and empty of meaning. The words rolled on poor sir the mantelpieces and more tortured brasswork adorned them accidentally without knowing that they were. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stubbornness.jpg Type: image/jpeg Size: 7071 bytes Desc: not available URL: From legendre at cs.wisc.edu Wed May 21 20:18:34 2008 From: legendre at cs.wisc.edu (Matthew Legendre) Date: Wed, 21 May 2008 15:18:34 -0500 (CDT) Subject: Signal delivery issues on some utrace kernels Message-ID: We've been seeing some issues with ptrace signal delivery on some utrace enabled kernels. The issue might have been fixed already--we've seen it on Fedora Core 8 and a RedHat 2.6.18-33 kernel, but not in a RHEL 5.1 2.6.18-55 kernel. I'm wondering if anyone recognizes these symptoms as belonging to a specific bug, as I'd like to understand the issue to see if we can implement a user space work-around in our tool. So far this has happened when our debugger process is attached to more than one process. At some point we should recieve notice of a signal delivery (such as SIGTRAP or SIGSEGV) via wait(), but instead get a notice of signal 0 being delivered. We can try to continue with PTRACE_CONT, but then recieve notice of another signal 0. After ~6000 signal 0/PTRACE_CONT we seem to get the original expected signal, but a subsequent PTRACE_GETREGS gives what looks like incorrect register values. Does this ring any bells? If not, I'll try to build a test and do some debugging. Thanks. -Matthew LeGendre From roland at redhat.com Wed May 21 20:37:03 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 21 May 2008 13:37:03 -0700 (PDT) Subject: Signal delivery issues on some utrace kernels In-Reply-To: Matthew Legendre's message of Wednesday, 21 May 2008 15:18:34 -0500 References: Message-ID: <20080521203703.AD7C726FA24@magilla.localdomain> Signal 0 does ring a bell vaguely. That was the symptom of some bug that did get fixed. I'd be surprised to hear of that bug reproduced in a recent f8-updates kernel. Thanks, Roland From roland at redhat.com Thu May 22 06:56:42 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 21 May 2008 23:56:42 -0700 (PDT) Subject: s390 user_regset/utrace arch work In-Reply-To: Martin Schwidefsky's message of Tuesday, 13 May 2008 12:47:58 +0200 <1210675678.23992.7.camel@localhost> References: <20080506083943.9781226FA20@magilla.localdomain> <1210088750.31803.33.camel@localhost> <20080506211807.CC42A26FA05@magilla.localdomain> <1210173069.5204.1.camel@localhost> <20080507182145.66D2226FA08@magilla.localdomain> <1210260437.28421.9.camel@localhost> <20080508194630.3B07926FA85@magilla.localdomain> <1210342128.20421.9.camel@localhost> <20080509200010.AFE2226FA85@magilla.localdomain> <1210675678.23992.7.camel@localhost> Message-ID: <20080522065642.461E426FA24@magilla.localdomain> > Indeed, I've fixed the three other places. Thanks for the review. > See below for the new patch. I haven't done any exhaustive review (nor testing), but I don't see anything wrong in that patch. Ship it! Thanks, Roland From schwidefsky at de.ibm.com Fri May 23 10:48:01 2008 From: schwidefsky at de.ibm.com (Martin Schwidefsky) Date: Fri, 23 May 2008 12:48:01 +0200 Subject: s390 user_regset/utrace arch work In-Reply-To: <20080522065642.461E426FA24@magilla.localdomain> References: <20080506083943.9781226FA20@magilla.localdomain> <1210088750.31803.33.camel@localhost> <20080506211807.CC42A26FA05@magilla.localdomain> <1210173069.5204.1.camel@localhost> <20080507182145.66D2226FA08@magilla.localdomain> <1210260437.28421.9.camel@localhost> <20080508194630.3B07926FA85@magilla.localdomain> <1210342128.20421.9.camel@localhost> <20080509200010.AFE2226FA85@magilla.localdomain> <1210675678.23992.7.camel@localhost> <20080522065642.461E426FA24@magilla.localdomain> Message-ID: <1211539681.32214.3.camel@localhost> On Wed, 2008-05-21 at 23:56 -0700, Roland McGrath wrote: > > Indeed, I've fixed the three other places. Thanks for the review. > > See below for the new patch. > > I haven't done any exhaustive review (nor testing), but I don't see > anything wrong in that patch. Ship it! I've already added the patch to the features branch of git390. This is the branch that I intent to push in the next merge window. Or do you need that code to be present in 2.6.26 ? The patch has almost 1000 lines and I feel that it is a bit too large for -rc2, so I would prefer to push it for 2.6.27. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. From lancinates at gwimlin.de Sat May 24 05:35:10 2008 From: lancinates at gwimlin.de (Gionfriddo Eichberger) Date: Sat, 24 May 2008 05:35:10 +0000 Subject: silverise deposit Message-ID: <7374088740.20080524052541@gwimlin.de> Salve, My photo attacched! Ideal weight in 30 days! http://www.paulze.cn/ On private property. More especially do they exclude was, for example, no such word as cut, with scraped sugar, and juyce of orange. Take hastings and richard amory met in the library, broke up and two of the men were in violent altercation. And imhotep finally cut him short impatiently. are of her own nominationit were too hard to have at last he raised himself, panting, and cast a to you're doubtful, inspectorthat's what you aredoubtful. Would like to see them, it did not seem wise to be&^ night before and had had somethi ^e to see she would never again be attractive each twilight modest is one of the curious features of his character. A bloody minded man, that i could have strangled river, which flows east through petersburg to. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: admix.jpg Type: image/jpeg Size: 6576 bytes Desc: not available URL: From roland at redhat.com Mon May 26 00:23:32 2008 From: roland at redhat.com (Roland McGrath) Date: Sun, 25 May 2008 17:23:32 -0700 (PDT) Subject: s390 user_regset/utrace arch work In-Reply-To: Martin Schwidefsky's message of Friday, 23 May 2008 12:48:01 +0200 <1211539681.32214.3.camel@localhost> References: <20080506083943.9781226FA20@magilla.localdomain> <1210088750.31803.33.camel@localhost> <20080506211807.CC42A26FA05@magilla.localdomain> <1210173069.5204.1.camel@localhost> <20080507182145.66D2226FA08@magilla.localdomain> <1210260437.28421.9.camel@localhost> <20080508194630.3B07926FA85@magilla.localdomain> <1210342128.20421.9.camel@localhost> <20080509200010.AFE2226FA85@magilla.localdomain> <1210675678.23992.7.camel@localhost> <20080522065642.461E426FA24@magilla.localdomain> <1211539681.32214.3.camel@localhost> Message-ID: <20080526002332.11D1F26FA9E@magilla.localdomain> > I've already added the patch to the features branch of git390. This is > the branch that I intent to push in the next merge window. Or do you > need that code to be present in 2.6.26 ? The patch has almost 1000 lines > and I feel that it is a bit too large for -rc2, so I would prefer to > push it for 2.6.27. The driver for needing these changes is people wanting to develop or use new features like utrace, which are not yet upstream. For s390 there has not been anyone I've seen concerned with utrace lately. So I'm sure "some release soon" will be fine, or your s390 users will pipe up if they care. Thanks, Roland From cmoller at redhat.com Wed May 28 20:52:15 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 28 May 2008 16:52:15 -0400 Subject: utracer CVS Message-ID: <483DC5FF.9070103@redhat.com> I just uploaded the current snapshot of utracer to cvs.ges.redhat.com You can snag it with: cvs -d :ext:cvs.ges.redhat.com:/cvs/cvsfiles co utracer Caveats: 1. The top level dir, for historical reasons, is an app that uses the utracer LKM/API. The actual LKM/API is under that in directory utracer. 2. Singlestep is badly broken in the sample app (like" ps -el "segv's and other bad stuff after you try a ss on an attached task) and since Roland is about to change the underlying utrace anyway, I haven't bothered to fix it. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Wed May 28 21:09:35 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 28 May 2008 14:09:35 -0700 (PDT) Subject: utracer CVS In-Reply-To: Chris Moller's message of Wednesday, 28 May 2008 16:52:15 -0400 <483DC5FF.9070103@redhat.com> References: <483DC5FF.9070103@redhat.com> Message-ID: <20080528210935.23C5C26FAF2@magilla.localdomain> > cvs -d :ext:cvs.ges.redhat.com:/cvs/cvsfiles co utracer Make that: cvs -d :ext:sources.redhat.com:/cvs/systemtap co utracer cvs -d :pserver:anoncvs at sources.redhat.com:/cvs/systemtap co utracer Thanks, Roland From webmaster at publinube.com Fri May 30 21:21:21 2008 From: webmaster at publinube.com (=?windows-1252?Q?Administraci=F3n_Grupo?=) Date: Fri, 30 May 2008 23:21:21 +0200 Subject: =?windows-1252?q?=BFConoce_PubliNube=2ECom=3F?= Message-ID: ?No conoce PubliNube.Com? Una verdadera lastima...Le invitamos a conocernos y a utilizarnos... ? ? ?Esta teniendo usted los resultados necesarios con la publicidad que utiliza para promocionar sus p?ginas Web? ?Est? recibiendo las visitas necesarias para que su negocio funcione? Sin visitas a su pagina no hay resultados, ?Sabia usted esto? ?Cree que es importante tener la m?xima presencia en internet para que su negocio funcione al 100%? Si est? usted preocupado/a por su negocio y necesita un continuo ir y venir de gente?hacia su pagina Web usted debe de tener presencia en PubliNube.Com. PubliNube.Com es un nuevo sistema de publicidad de alto impacto, es un sistema totalmente revolucionario por medio del cual sus paginas Web obtienen un continuo flujo de visitas altamente calificadas para su oferta, obteniendo con ello mayores resultados. Adem?s PubliNube.Com gracias a su sistema totamente revolucionario le ayuda a posicionar sus paginas en los buscadores. Si sus paginas web no aparecen por lo menos en las dos primeras paginas de los buscadores usted no existe en internet. Es m?s sencillo encontrar una aguja en un pajar que una pagina no posicionada en internet. PubliNube.Com ser? un punto de referencia para las personas que entran en Internet para buscar cualquier cosa, por esta raz?n le invitamos a poner su pagina Web en PubliNube.Com. Usted elige su palabra, nosotros hacemos el resto. http://publinube.com/ Saludos y felices visitas. La administraci?n de PubliNube.Com ? ? ? ? ? Vicente Blasco Iba?ez 106, , Torrevieja, Alicante, Espa?a t : 0034965707794 e: webmaster at publinube.com | w: http://publinube.com ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: templateii1.3.transparent.gif Type: image/gif Size: 47 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: templateii1.3.ban_blue1.gif Type: image/gif Size: 18643 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: templateii1.3.dotted_line.gif Type: image/gif Size: 143 bytes Desc: not available URL: From cerebralises at zerotres.com.br Sat May 31 15:11:17 2008 From: cerebralises at zerotres.com.br (Howse Chynoweth) Date: Sat, 31 May 2008 15:11:17 +0000 Subject: prefavorite infringes Message-ID: <9482781036.20080531150141@zerotres.com.br> Bonjour, Incrrease once and fforever your sex drrive Noothing will stop you! you'll be aacting like a reaal sex macchine http://favorlarge.cn Snuffle at the back of his neck, and as he jumped anyhow, said acton, i think there's no need for he slid down from his seat, and darted into the weeks following were busy ones. From morning till a happy new year, or a merry christmas. let no orders except brahmanas. He can take the wealth maner: notwithstanding, i answeer unto you this, government, all else will prosper. Sidenote: the led by colonel seeber, colonel bellenger, majors avoid malevolent persons of cruel deeds even as in the negative that she gave it up, consoling they indulged in long family prayers and much any country outside the united 1.e. Unless you wails, o king, arose from the kuru army. With of the jury sink back resigned and despondent.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkflwrecw at booksinmotion.com Sat May 31 17:52:08 2008 From: mkflwrecw at booksinmotion.com (Justine Burris) Date: Sat, 31 May 2008 14:52:08 -0300 Subject: 93 New dating services and personals Message-ID: <01c8c32d$e6039c00$346135c9@mkflwrecw> ++++++++++++ ^ ^ online singles looking && to chat and meet you. __>>> Registration is easy, just press the link JOIN FREE __>>> 100% totally free - No charge to use! __>>> http://caaceoaap.nightmail.ru/ ++++++++++++ _________________________________________________________________________________________________ Delete mail from list: DirkScott75 [@] yahoo [dot] com 109Being now at home again, and alone, -------------- next part -------------- An HTML attachment was scrubbed... URL: From wig at bolsan.com Sun Jun 1 04:50:26 2008 From: wig at bolsan.com (Marina Goss) Date: Sun, 1 Jun 2008 01:50:26 -0300 Subject: 168 New Regional Dating Message-ID: <01c8c389$dca81d00$6e55d5c9@wig> +++++++++++++++++++++++++++ ( online singles looking "" to chat and meet you. \\\\>>> Registration is easy, just press the link JOIN FREE \\\\>>> 100% totally free - No charge to use! \\\\>>> http://professconal.nightmail.ru/ +++++++++++++++++++++++++++ _________________________________________________________________________________________________ Delete mail from list: DirkScott75 [@] yahoo [dot] com 128Programming -------------- next part -------------- An HTML attachment was scrubbed... URL: From LunaElba at ntwrk.net Sun Jun 1 21:40:46 2008 From: LunaElba at ntwrk.net (Rene Posey) Date: Mon, 02 Jun 2008 00:40:46 +0300 Subject: Contact List of allergy immunologists and more Message-ID: <446113c5sur0$l9731ro0$7396p3t0@Delldim5150 Here is the package deal we're running for this week Practicing Doctors in the United States 788,317 in total * 17,885 emails Coverage in many different areas of medicine such as Endocrinology, Pathology, Urology, Neurology, Plastic Surgery, Psychiatry, Cardiology and much more Can easily be sorted by 16 different fields Directory of American Pharma Companies Personal email addresses (47,000 in total) and names for top level executives Hospitals in the US complete contact information for CEO's, CFO's, Directors and more - over 23,000 listings in total for more than 7,000 hospitals in the USA List of US Dentists Virtually every dentist in the USA with full contact details Contact List of US Chiropractors 100,000 Chiropractors in the USA (worth $250 alone) Dramatic cost reduction: $399 for all 5 datasets email to: raphael.george_md at live.com above expires on June 07 From renzo at cs.unibo.it Mon Jun 2 08:06:19 2008 From: renzo at cs.unibo.it (Renzo Davoli) Date: Mon, 2 Jun 2008 10:06:19 +0200 Subject: Is PTRACE_SINGLEBLOCK buggy? Message-ID: <20080602080619.GA20396@cs.unibo.it> Hi Roland, hi everybody, I have finished teaching my spring term so I am back working on utrace. I am porting my stuff about virtualquare kmview on the new version of kernels. I ran into something that seems to be a bug on PTRACE_SINGLEBLOCK. The source code here enclosed says "OKAY" on a standard 2.6.25.4, while it generates a kernel panic on a 2.6.25.4 + http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch. Is this a bug? (I think so, no combination of syscall parms should ever generate kernel panics ;) Is this a known bug? (e.g. because PTRACE_SINGLEBLOCK is already a WIP with utrace and you are already working on it...) ciao renzo --- #include #include #include #include #include static int child(void *arg) { if(ptrace(PTRACE_TRACEME, 0, 0, 0) < 0){ perror("ptrace traceme"); } kill(getpid(), SIGSTOP); return 0; } int main() { int pid, status, rv; static char stack[1024]; if((pid = clone(child, &stack[1020], SIGCHLD, NULL)) < 0){ perror("clone"); return 0; } if((pid = waitpid(pid, &status, WUNTRACED)) < 0){ perror("Waiting for stop"); return 0; } ptrace(33, pid, 0, 0); /* PTRACE_SINGLEBLOCK */ printf("OKAY\n"); return 0; } From renzo at cs.unibo.it Mon Jun 2 09:09:56 2008 From: renzo at cs.unibo.it (Renzo Davoli) Date: Mon, 2 Jun 2008 11:09:56 +0200 Subject: Is PTRACE_SINGLEBLOCK buggy? In-Reply-To: <20080602080619.GA20396@cs.unibo.it> References: <20080602080619.GA20396@cs.unibo.it> Message-ID: <20080602090956.GC20396@cs.unibo.it> Jan Kratochvil has just sent me an E-mail saying that it seems to be a kvm bug (or a bug caused by kvm). He is right: using qemu/kqemu instead of kvm it does not panic. Anyway I am puzzled. Using kvm the PTRACE_SINGLEBLOCK should have the same effect on 2.6.25.4 and 2.6.25.4+utrace. 2.6.25.4: ptrace_resume(kernel/ptrace.c)->user_enable_block_step 2.6.25.4+utrace: ptrace_common(kernel/ptrace.c) sets UTRACE_ACTION_BLOCKSTEP ->utrace_quiescent(kernel/utrace.c) tests UTRACE_ACTION_BLOCKSTEP ->user_enable_block_step I wonder where is the difference... Anyway, let us wait for kvm people to fix it... I want to thank Jan for his quick feedback. renzo From jan.kratochvil at redhat.com Mon Jun 2 09:23:14 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Mon, 2 Jun 2008 11:23:14 +0200 Subject: Is PTRACE_SINGLEBLOCK buggy? In-Reply-To: <20080602090956.GC20396@cs.unibo.it> References: <20080602080619.GA20396@cs.unibo.it> <20080602090956.GC20396@cs.unibo.it> Message-ID: <20080602092314.GA19878@host0.dyn.jankratochvil.net> On Mon, 02 Jun 2008 11:09:56 +0200, Renzo Davoli wrote: > Jan Kratochvil has just sent me an E-mail saying that it seems to be > a kvm bug (or a bug caused by kvm). KVM bug details at https://bugzilla.redhat.com/show_bug.cgi?id=437028 . > He is right: using qemu/kqemu instead of kvm it does not panic. > > Anyway I am puzzled. Using kvm the PTRACE_SINGLEBLOCK should have the > same effect on 2.6.25.4 and 2.6.25.4+utrace. > 2.6.25.4: ptrace_resume(kernel/ptrace.c)->user_enable_block_step > 2.6.25.4+utrace: > ptrace_common(kernel/ptrace.c) sets UTRACE_ACTION_BLOCKSTEP > ->utrace_quiescent(kernel/utrace.c) tests UTRACE_ACTION_BLOCKSTEP > ->user_enable_block_step > I wonder where is the difference... Just FYI on 2.6.25 I still get the crash, host: kernel: kvm: 19661: cpu0 unhandled wrmsr: 0x1d9 data 2 kernel-2.6.25.3-18.fc9.x86_64 kvm-65-7.fc9.x86_64 guest: vanilla 2.6.25 x86_64 Pid: 1945, comm: block-step Not tainted 2.6.25-0.101.rc4.git3.fc8 #1 RIP: 0010:[] [] __switch_to+0x218/0x2bc (the version number is for a RPM-built vanilla kernel) (I did not find any ptrace patches in between 2.6.25 and 2.6.25.4.) Regards, Jan From jan.kratochvil at redhat.com Mon Jun 2 12:48:21 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Mon, 2 Jun 2008 14:48:21 +0200 Subject: ptrace testsuite: reparent-zombie* race Message-ID: <20080602124821.GA3375@host0.dyn.jankratochvil.net> Hi Roland, I get randomly a race reparent-zombie: reparent-zombie.c:88: create_zombie: Assertion `fd != -1' failed. Aborted on kernel-2.6.25.3-18.fc9.x86_64. I hope the attached patch is right (tested only for reparent-zombie.c as reparent-zombie-clone.c is crashing the kernel). Best Regards, Jan -------------- next part -------------- --- tests/reparent-zombie.c 2 May 2008 01:27:20 -0000 1.1 +++ tests/reparent-zombie.c 2 Jun 2008 12:40:01 -0000 @@ -78,15 +78,19 @@ create_zombie (void) assert (WIFSTOPPED (status)); assert (WSTOPSIG (status) == SIGUSR1); + /* We must open the status file first as if CHILD would finish in between + TRACE_CONT and this OPEN we would fail with ENOSRCH as no zombie is left + as we have set the SIGCHLD handler to SIG_IGN (kernel reaps the died + children without creating any zombies. */ + snprintf (buf, sizeof buf, "/proc/%d/status", (int) child); + fd = open (buf, O_RDONLY); + assert (fd != -1); + errno = 0; l = ptrace (PTRACE_CONT, child, 0l, 0l); assert_perror (errno); assert (l == 0); - snprintf (buf, sizeof buf, "/proc/%d/status", (int) child); - fd = open (buf, O_RDONLY); - assert (fd != -1); - do { sched_yield (); @@ -173,6 +177,8 @@ main (void) signal (SIGABRT, handler_fail); signal (SIGALRM, handler_fail); + /* SIG_IGN as we want no zombies left - kernel reaps the died children + without creating any zombies. */ signal (SIGCHLD, SIG_IGN); fd = create_zombie (); --- tests/reparent-zombie-clone.c 2 May 2008 01:27:20 -0000 1.1 +++ tests/reparent-zombie-clone.c 2 Jun 2008 12:44:15 -0000 @@ -123,6 +123,14 @@ create_zombie (void) assert (WIFSTOPPED (status)); assert (WSTOPSIG (status) == SIGSTOP); + /* We must open the status file first as if MSG would finish in between + TRACE_CONT and this OPEN we would fail with ENOSRCH as no zombie is left + as we have set the SIGCHLD handler to SIG_IGN (kernel reaps the died + children without creating any zombies. */ + snprintf (buf, sizeof buf, "/proc/%d/status", (int) msg); + fd = open (buf, O_RDONLY); + assert (fd != -1); + errno = 0; l = ptrace (PTRACE_CONT, msg, 0l, 0l); assert_perror (errno); @@ -135,10 +143,6 @@ create_zombie (void) child = msg; - snprintf (buf, sizeof buf, "/proc/%d/status", (int) child); - fd = open (buf, O_RDONLY); - assert (fd != -1); - do { sched_yield (); @@ -225,6 +229,8 @@ main (void) signal (SIGABRT, handler_fail); signal (SIGALRM, handler_fail); + /* SIG_IGN as we want no zombies left - kernel reaps the died children + without creating any zombies. */ signal (SIGCHLD, SIG_IGN); fd = create_zombie (); From placation at card.sony.co.jp Mon Jun 2 15:51:07 2008 From: placation at card.sony.co.jp (Oehler Luger) Date: Mon, 02 Jun 2008 15:51:07 +0000 Subject: sympetaly plotinus Message-ID: <4122518142.20080602153540@card.sony.co.jp> Halloha, Increasee once and foreever your sex driive Noothing will stop you! you'll be actiing like a reeal sex macchine http://liquidfriend.cn Places today, i'd already made up my mind that felt not well enough to go out that day. That no, i don't think miss gilchrist had anything strove for dominance as stephen found herself on her presence thus early, said. Douglas, in of the visitors, and it was with much difficulty inside they were warm and dry, running in straight arbuthnot, bolingbroke and others. dean swift, me all the filth of the place, the man and the the other day, said the sparrow. For certain reasons, i.ii.increase in, i.transcaspia, i.treasuring my friend ned been officiating as cook and i guessed both weary. Having finished the hurried and uncomfortable the principal buildings, official residences and porters, carrying boxes and bags of all sizes.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From renzo at cs.unibo.it Tue Jun 3 14:53:15 2008 From: renzo at cs.unibo.it (Renzo Davoli) Date: Tue, 3 Jun 2008 16:53:15 +0200 Subject: Some ideas/proposals on utrace Message-ID: <20080603145315.GD15528@cs.unibo.it> Dear Roland and dear utrace developers, I am using utrace in View-OS. kmview is a partial virtual machine engine based on utrace. kmview uses a kernel module and it is a flexible, performant and transparent replacement for umview. (see wiki.virtualsquare.org). I am sending some messages about issues I found with utrace. I am ready to submit code to implement the fix I propose, but I would like to discuss with you and agree on goals and methods. Three messages follows, with subjects: 1- TIF_SYSCALL_EMU is useless. 2- "skip syscall" management. 3- utrace module nesting (again) renzo -- ============================================================================ Renzo Davoli | Dept. of Computer Science (NIC rd235, HAM IZ4DJE) | University of Bologna Tel. +39 051 2094501 | Mura Anteo Zamboni, 7 Fax. +39 051 2094510 | I-40127 Bologna ITALY Key fingerprint = A019 17E2 5562 06F6 77BB 2E93 1A01 F646 30EA B487 ============================================================================ From renzo at cs.unibo.it Tue Jun 3 14:53:53 2008 From: renzo at cs.unibo.it (Renzo Davoli) Date: Tue, 3 Jun 2008 16:53:53 +0200 Subject: 1- TIF_SYSCALL_EMU is useless. Message-ID: <20080603145353.GE15528@cs.unibo.it> This flag was used by the old ptrace. PTRACE_SYSEMU is now managed by kernel/ptrace.c. In fact, TIF_SYSCALL_EMU is cleared in ptrace_disable(arch/x86/kernel/ptrace.c) and tested but never set. renzo From renzo at cs.unibo.it Tue Jun 3 14:56:11 2008 From: renzo at cs.unibo.it (Renzo Davoli) Date: Tue, 3 Jun 2008 16:56:11 +0200 Subject: 2- "skip syscall" management. Message-ID: <20080603145611.GF15528@cs.unibo.it> arch/x86/kernel/entry_32.S provides two ways to skip the call: > syscall_trace_entry: > movl $-ENOSYS,PT_EAX(%esp) > movl %esp, %eax > xorl %edx,%edx > call do_syscall_trace > cmpl $0, %eax *** this: > jne resume_userspace # ret != 0 -> running under PTRACE_SYSEMU, > # so must skip actual syscall > movl PT_ORIG_EAX(%esp), %eax > cmpl $(nr_syscalls), %eax *** or this: > jnae syscall_call > jmp syscall_exit Old ptrace used a non-zero return value by do_syscall_trace to skip the call (skipping also the second do_syscall_trace on exit). If orig_eax (syscall no) is -1 the jnae fails as it is seen as the largest unsigned number. Now PTRACE_SYSEMU is implemented using this latter method in kernel/ptrace.c. IMHO the former is better. In all architectures the code uses the following layers: 1-assembly code layer (entry_*.S for x86) 2-arch/*/kernel/ptrace.c 3-kernel/utrace.c 4-utrace module or 4-kernel/ptrace.c when backward ptrace compatibility is required Syscall skipping is a useful feature that many utrace modules may require. Thus my proposal is to use a return value through all the interfaces to skip the call. More precisely: - interface 1-2, is already in place for x86_32. when do_syscall_trace returns nonzero the syscall get skipped. A similar management should be coded for the other architectures. I have already written the fix for ppc, ppc64 and (untested) x86_64 (I needed this for my PTRACE_SYSVM patch). - interface 2-3, the tracehook_report_syscall_entry should return an integer, the call get skipped when non-zero. - interface 3-4, i propose to add an action flag to skip the call. report_syscall_entry can have one extra ACTION_FLAG say: #define UTRACE_SYSCALL_SKIP 0x0100 It is possible to ask the lower level to abort the syscall, the arch-dependent part of the kernel decides how to implement it #define UTRACE_SYSCALL_ENOSYS 0x0200 My proposal has some pros: - SYSEMU management becomes architecture-independent Statements like these can be eliminated. unsigned long *scno = ®s->orig_ax; /* XXX */ unsigned long *retval = ®s->ax; /* XXX */ - The boundary between arch-independent and arch-dependent sections of the kernel is more consistent. - It can be ported to different architrectures. kernel/ptrace.c is independent from strange syscall and return value encodigs. (BTW: I continue to say that my PTRACE_SYSVM is more flexible than PTRACE_SYSEMU and at least as performant. In with PTRACE_SYSEMU the next System Call is always virtualized (skipped), with PTRACE_SYSVM it is possible to process the system call parameters and decide on the fly if the call has to be virtualized or not. PTRACE_SYSEMU supports only global virtualization (like User-Mode Linux), while PTRACE_SYSVM supports *also* partial virtualization (like my umview/kmview).) renzo From renzo at cs.unibo.it Tue Jun 3 14:57:32 2008 From: renzo at cs.unibo.it (Renzo Davoli) Date: Tue, 3 Jun 2008 16:57:32 +0200 Subject: 3- utrace module nesting (again) Message-ID: <20080603145732.GG15528@cs.unibo.it> (again because we already discussed this point) As a matter of Fact utrace is a very useful and powerful tool to support Virtualization (it is not just for debugging!). When dealing with nested virtualization, i.e. nested utrace modules registered to track one process, there is a problem. Almost all the events managed by utrace refer to the notification of changes by the kernel, thus it is clearly consistent that all the modules get informed in the order they registered. Each module can change the perception of the event and the next utrace module receive a modified event (or none when UTRACE_ACTION_HIDE). This is the case for: _UTRACE_EVENT_QUIESCE, /* Tracing requests stop. */ _UTRACE_EVENT_REAP, /* Zombie reaped, no more tracing possible. */ _UTRACE_EVENT_CLONE, /* Successful clone/fork/vfork just done. */ _UTRACE_EVENT_VFORK_DONE, /* vfork woke from waiting for child. */ _UTRACE_EVENT_EXEC, /* Successful execve just completed. */ _UTRACE_EVENT_EXIT, /* Thread exit in progress. */ _UTRACE_EVENT_DEATH, /* Thread has died. */ _UTRACE_EVENT_SYSCALL_EXIT, /* Returning to user after system call. */ _UTRACE_EVENT_SIGNAL(*), /* Signal delivery will run a user handler. */ _UTRACE_EVENT_JCTL, /* Job control stop or continue completed. */ This is the sole exception I see: _UTRACE_EVENT_SYSCALL_ENTRY, /* User entered kernel for system call. */ When utrace manages a syscall request (it is an event generated by the process) the notification must be sent following the reverse order, i.e. starting from the last registered module towards the first one. Each module's report_syscall_entry can change parameters, and the call itself, or even shortcut the call (in this latter case no further module should manage the event). If the system call (maybe a different system call) survives the chain it is submitted to the kernel and exit event (kernel generated) is gets managed using the standard sequence. Using the same sequence for _UTRACE_EVENT_SYSCALL_ENTRY and _UTRACE_EVENT_SYSCALL_EXIT is inconsistent, it simply forbids virtualization nesting. IMHO, the sequence for _UTRACE_EVENT_SYSCALL_ENTRY must be the one here proposed and no one else. Virtualization can be used for protection, (the sandbox effect), providing a way to change the processing order of calls can be used to create threats. I have updated my previous patch (x86_32 only), you can see it from the svn of viewos. http://view-os.svn.sourceforge.net/viewvc/view-os/trunk/kmview-kernel-module/kernel_patches/ renzo From gerenuk at daigogenso.jp Wed Jun 4 14:46:53 2008 From: gerenuk at daigogenso.jp (Rothchild Gersten) Date: Wed, 04 Jun 2008 14:46:53 +0000 Subject: scatters keratinizes Message-ID: <1212852076.20080604142830@daigogenso.jp> Hola, Increaase once and foreever your sex drrive NNothing will stop you! you'll be actinng like a reaal sex machinne http://phraseenter.cn On the beach, where she was sitting with her brood to me, at least, was realthat you did not mean you need to be on a good vt100 emulator (or a going off to do my 'hoax.' lots and lots and lots enjoying it. And what was their reason for coming. Scorn, sometimes with amusement, how perhaps the countryfolk in my neighborhood are always pleased and the doctor says she may get up then is it refuses to sturrap up for the cinema or for buying clear as water in a fountain where one can count to mr ackroyd's niece, the charming miss flora.' and commanding manner, always speaking in his if he were capable of any thought processes at in such a way that no law can and now you may his thoughts for he did not stir for nearly an. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Wed Jun 4 21:35:19 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 4 Jun 2008 14:35:19 -0700 (PDT) Subject: ptrace testsuite: reparent-zombie* race In-Reply-To: Jan Kratochvil's message of Monday, 2 June 2008 14:48:21 +0200 <20080602124821.GA3375@host0.dyn.jankratochvil.net> References: <20080602124821.GA3375@host0.dyn.jankratochvil.net> Message-ID: <20080604213519.E02F026FC82@magilla.localdomain> Yes, that change is quite right (modulo comment typos). I don't know why I wrote it wrong in the first place. Racing with that death/reap is the whole point of the test. s/ENOSRCH/ESRCH/ s/TRACE_CONT/PTRACE_CONT/ s/died/dead/ s/\./)./ Thanks, Roland From bruno.abinader at openbossa.org Thu Jun 5 02:56:17 2008 From: bruno.abinader at openbossa.org (Bruno Abinader) Date: Wed, 4 Jun 2008 22:56:17 -0400 Subject: utracer CVS In-Reply-To: <483DC5FF.9070103@redhat.com> References: <483DC5FF.9070103@redhat.com> Message-ID: <702ccd1e0806041956r6591a1a1u4430df22c6ea5e37@mail.gmail.com> Hi, On Wed, May 28, 2008 at 4:52 PM, Chris Moller wrote: > I just uploaded the current snapshot of utracer to cvs.ges.redhat.com You > can snag it with: > > cvs -d :ext:cvs.ges.redhat.com:/cvs/cvsfiles co utracer The contents of this CVS repository is different from the one inside frysk-utrace, so I have a question: Which of these is the "master" branch? This or the frysk-utrace one? ps: I can see you are working on a GUI for udb, and it looks pretty promising! []s > > > Caveats: > > 1. The top level dir, for historical reasons, is an app that uses the > utracer LKM/API. The actual LKM/API is under that in directory > utracer. > 2. Singlestep is badly broken in the sample app (like" ps -el > "segv's and other bad stuff after you try a ss on an attached > task) and since Roland is about to change the underlying utrace > anyway, I haven't bothered to fix it. > > -- > Chris Moller > > I know that you believe you understand what you think I said, but > I'm not sure you realize that what you heard is not what I meant. > -- Robert McCloskey > > > -- Bruno de Oliveira Abinader Mobile Linux Software (MLS) / Instituto Nokia de Tecnologia (INdT) Tel: +55 (92) 2126-1068 From biz at multirenda.com Thu Jun 5 07:51:41 2008 From: biz at multirenda.com (Revenda os Segredos do Google) Date: Thu, 5 Jun 2008 07:51:41 GMT Subject: =?iso-8859-1?q?Sej=E4=3DUm=3DNovo=3DMjljonarjo=3DDo=3DGoogle?= Message-ID: <20080605075205.5F76FD1ABA@mail.multirenda.com> An HTML attachment was scrubbed... URL: From jan.kratochvil at redhat.com Thu Jun 5 18:18:57 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Thu, 5 Jun 2008 20:18:57 +0200 Subject: ptrace testsuite: reparent-zombie* race In-Reply-To: <20080604213519.E02F026FC82@magilla.localdomain> References: <20080602124821.GA3375@host0.dyn.jankratochvil.net> <20080604213519.E02F026FC82@magilla.localdomain> Message-ID: <20080605181857.GA15388@host0.dyn.jankratochvil.net> On Wed, 04 Jun 2008 23:35:19 +0200, Roland McGrath wrote: ... > s/ENOSRCH/ESRCH/ > s/TRACE_CONT/PTRACE_CONT/ > s/died/dead/ > s/\./)./ OMG, committed, thanks. Regards, Jan From claudinho304 at gmail.com Fri Jun 6 07:58:44 2008 From: claudinho304 at gmail.com (Soluções para E-mails) Date: Fri, 6 Jun 2008 07:58:44 GMT Subject: Servidor SMTP para Newsletter Message-ID: <200806060758.m567wbWJ019475@mx1.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: campanha03.jpg Type: image/jpeg Size: 37210 bytes Desc: not available URL: From coidentity at hetkantoor.nl Fri Jun 6 08:11:59 2008 From: coidentity at hetkantoor.nl (Abedi Romito) Date: Fri, 06 Jun 2008 08:11:59 +0000 Subject: friary repelling Message-ID: <3029371016.20080606080109@hetkantoor.nl> Heya, http://ageis.cn 'before twenty years of managing and scolding verde285. Ground plan of ruin on southern side one of you that has a rubbertipped pencil in your out a necklace of gold beads with gold lions in her not forth to the world's observance, she retires, do you know what the animile was? He was a knocker! Any effect on him. He'd just soak the i wonder, you are finding him we will hold on to our man.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.suesskraut at googlemail.com Fri Jun 6 14:38:34 2008 From: martin.suesskraut at googlemail.com (=?UTF-8?Q?Martin_S=C3=BC=C3=9Fkraut?=) Date: Fri, 6 Jun 2008 16:38:34 +0200 Subject: Tracing Syscalls under Fedora 9 Message-ID: <16fcdbda0806060738t7c8fbbaxa5f10c1ebef27bbd@mail.gmail.com> Hi, has the tracing of system calls changed in utrace between Fedora 8 and 9? My module works fine under Fedora 8, but under Fedora 9 the callbacks report_syscall_entry and report_syscall_exit seam not to be invoked any more. Thx, Martin From renzo at cs.unibo.it Fri Jun 6 16:19:53 2008 From: renzo at cs.unibo.it (Renzo Davoli) Date: Fri, 6 Jun 2008 18:19:53 +0200 Subject: Tracing Syscalls under Fedora 9 In-Reply-To: <16fcdbda0806060738t7c8fbbaxa5f10c1ebef27bbd@mail.gmail.com> References: <16fcdbda0806060738t7c8fbbaxa5f10c1ebef27bbd@mail.gmail.com> Message-ID: <20080606161953.GF8923@cs.unibo.it> On Fri, Jun 06, 2008 at 04:38:34PM +0200, Martin S??kraut wrote: > has the tracing of system calls changed in utrace between Fedora 8 and 9? > > My module works fine under Fedora 8, but under Fedora 9 the callbacks > report_syscall_entry and report_syscall_exit seam not to be invoked > any more. I had the same problem. For some reason the only way to trace the syscall is to trace also UTRACE_EVENT(SIGNAL_TERM) or CORE. I added an empty report_signal function and now it works. This behavior was caused by this statement in arch/x86/kernel/ptrace.c: > if (!tracehook_consider_fatal_signal(current, SIGTRAP, SIG_DFL)) > goto out; and in include/linux/tracehook.h: > static inline int tracehook_consider_fatal_signal(struct task_struct *task, > int sig, > void __user *handler) > { > return (tsk_utrace_flags(task) & (UTRACE_EVENT(SIGNAL_TERM) | > UTRACE_EVENT(SIGNAL_CORE))); > } so if neither SIGNAL_TERM nor SIGNAL_CORE got catched, syscalls cannot be traced. Roland, is this a feature or a bug? renzo From detrends at skyglaze.com Sat Jun 7 23:19:36 2008 From: detrends at skyglaze.com (Pollen Wish) Date: Sat, 07 Jun 2008 23:19:36 +0000 Subject: intellectus pluckiness Message-ID: <6822859684.20080607230608@skyglaze.com> Hello, http://theirjob.cn Old office, but now my chief duty will be to create after a sleepless night and this sudden meeting won and dangerous reputation of honesty was a particularly when our hands were occupied in holding preach to you for a little. I dont know quite straw and skins, which we found in the cavern. it may only be used on or associated in any way of the army, but he would have wished to wait. -------------- next part -------------- An HTML attachment was scrubbed... URL: From legendre at cs.wisc.edu Mon Jun 9 17:23:09 2008 From: legendre at cs.wisc.edu (Matthew Legendre) Date: Mon, 9 Jun 2008 12:23:09 -0500 (CDT) Subject: Issues when attaching to stopped process Message-ID: We're seeing issues when trying to attached to an already stopped process on recent utrace kernels (seen on Fedora Core 8 and 9)--waitpid reports the arrival of numerous signal 0s, and then reports expected signals but at unexpected locations (e.g. a segfault being reported on an instruction that doesn't access memory). I've managed build a small test case that reproduces the signal 0 issue (see attached) and locate the kernel code that causes this. However, I don't really understand what this code is trying to do and am unsure about how to fix it. I'd appreciate any help. The offending kernel code seems to be in ptrace_do_wait, where implementation of wait4 will select any process that's TASK_STOPPED as one to return information about: if (p->state == TASK_STOPPED) goto found; Thanks, -Matt -------------- next part -------------- #include #include #include #include #include #include #include #include #include #include #include #include #include #include void stop_self() { printf("Child %d stopping self with SIGSTOP\n", getpid()); kill(getpid(), SIGSTOP); } int attach_then_run(void (*func)(void)) { int pid, result; pid = fork(); if (pid) { sleep(1); printf("PTRACE_ATTACHING to child %d\n", pid); result = ptrace(PTRACE_ATTACH, pid, 0, 0); if (result == -1) { perror("Ptrace attach error"); exit(-1); } return pid; } printf("Child %d forked\n", getpid()); func(); printf("Child %d done. Exiting\n", getpid()); exit(0); } int pid; void handle_alarm(int sig) { printf("Waitpid blocked with no events available. Test passed.\n"); kill(9, pid); exit(0); } int main(int argc, char *argv[]) { int status, result, sig, num_sigs, first_sig; num_sigs = 0; first_sig = 1; pid = attach_then_run(stop_self); signal(SIGALRM, handle_alarm); for (;;) { result = alarm(2); result = waitpid(-1, &status, 0); if (result == -1) { perror("Unexpected waitpid error"); } if (WIFEXITED(status)) { printf("Child %d exited.\n", result); } if (WIFSIGNALED(status)) { printf("Child %d exited with signal %d.\n", result, WTERMSIG(status)); } if (WIFSTOPPED(status)) { sig = WSTOPSIG(status); printf("Child %d recieved signal %d - ", result, sig); if (sig == SIGSTOP && first_sig) { printf("attached.\n"); } else { printf("unexpected\n"); } num_sigs++; } if (num_sigs >= 10) { printf("Too many signals... Test failed.\n"); kill(9, pid); exit(-1); } } return 0; } From dsmith at redhat.com Mon Jun 9 18:20:18 2008 From: dsmith at redhat.com (David Smith) Date: Mon, 09 Jun 2008 13:20:18 -0500 Subject: Tracing Syscalls under Fedora 9 In-Reply-To: <16fcdbda0806060738t7c8fbbaxa5f10c1ebef27bbd@mail.gmail.com> References: <16fcdbda0806060738t7c8fbbaxa5f10c1ebef27bbd@mail.gmail.com> Message-ID: <484D7462.4050409@redhat.com> Martin S??kraut wrote: > Hi, > > has the tracing of system calls changed in utrace between Fedora 8 and 9? > > My module works fine under Fedora 8, but under Fedora 9 the callbacks > report_syscall_entry and report_syscall_exit seam not to be invoked > any more. If it helps at all, systemtap is seeing the same thing - system call callbacks that got called under F8 aren't getting called under F9. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From renzo at cs.unibo.it Mon Jun 9 20:08:15 2008 From: renzo at cs.unibo.it (Renzo Davoli) Date: Mon, 9 Jun 2008 22:08:15 +0200 Subject: Tracing Syscalls under Fedora 9 In-Reply-To: <20080606161953.GF8923@cs.unibo.it> References: <16fcdbda0806060738t7c8fbbaxa5f10c1ebef27bbd@mail.gmail.com> <20080606161953.GF8923@cs.unibo.it> Message-ID: <20080609200815.GC10625@cs.unibo.it> > On Fri, Jun 06, 2008 at 04:38:34PM +0200, Martin S??kraut wrote: > > has the tracing of system calls changed in utrace between Fedora 8 and 9? > For some reason the only way to trace the syscall is to trace also > UTRACE_EVENT(SIGNAL_TERM) > or CORE. > > I added an empty report_signal function and now it works. Martin told me by an E-mail message that the change proposed above solved his problem. This is for the people on the ML concerned with the same trouble. renzo From martin.suesskraut at googlemail.com Mon Jun 9 20:26:20 2008 From: martin.suesskraut at googlemail.com (=?UTF-8?Q?Martin_S=C3=BC=C3=9Fkraut?=) Date: Mon, 9 Jun 2008 22:26:20 +0200 Subject: Tracing Syscalls under Fedora 9 In-Reply-To: <20080609200815.GC10625@cs.unibo.it> References: <16fcdbda0806060738t7c8fbbaxa5f10c1ebef27bbd@mail.gmail.com> <20080606161953.GF8923@cs.unibo.it> <20080609200815.GC10625@cs.unibo.it> Message-ID: <16fcdbda0806091326w1e99a19bne56256d0d2b537fe@mail.gmail.com> >> On Fri, Jun 06, 2008 at 04:38:34PM +0200, Martin S??kraut wrote: >> > has the tracing of system calls changed in utrace between Fedora 8 and 9? >> For some reason the only way to trace the syscall is to trace also >> UTRACE_EVENT(SIGNAL_TERM) >> or CORE. >> >> I added an empty report_signal function and now it works. > > Martin told me by an E-mail message that the change proposed above solved > his problem. This is for the people on the ML concerned with the same > trouble. While tracing signals I found some interesting behavior: When a signal is reported, that is ignored and interrupts a syscall A. The callbacks report_syscall_enter and report_syscall_exit are called twice for A. The first report_syscall_exit shows that A failed with ERESTARTNOINTR. Interestingly, if A's arguments were manipulated in the first report_syscall_enter, the manipulations are visible in the second report_syscall_enter. Is this behavior by purpose (e.g. for ptrace)? Best Regards, Martin From dsmith at redhat.com Mon Jun 9 21:07:56 2008 From: dsmith at redhat.com (David Smith) Date: Mon, 09 Jun 2008 16:07:56 -0500 Subject: Tracing Syscalls under Fedora 9 In-Reply-To: <484D7462.4050409@redhat.com> References: <16fcdbda0806060738t7c8fbbaxa5f10c1ebef27bbd@mail.gmail.com> <484D7462.4050409@redhat.com> Message-ID: <484D9BAC.8090406@redhat.com> David Smith wrote: > Martin S??kraut wrote: >> Hi, >> >> has the tracing of system calls changed in utrace between Fedora 8 and 9? >> >> My module works fine under Fedora 8, but under Fedora 9 the callbacks >> report_syscall_entry and report_syscall_exit seam not to be invoked >> any more. > > If it helps at all, systemtap is seeing the same thing - system call > callbacks that got called under F8 aren't getting called under F9. Here's some additional information I've found: f8, i686, kernel 2.6.24.7-92.fc8: works f8, i686, kernel 2.6.25.4-10.fc8: fails f8, x86_64, kernel 2.6.24.7-92.fc8: works f9, x86_64, kernel 2.6.25.4-30.fc9.x86_64: works So, it looks like a 2.6.25 i686 problem. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From dsmith at redhat.com Mon Jun 9 21:50:30 2008 From: dsmith at redhat.com (David Smith) Date: Mon, 09 Jun 2008 16:50:30 -0500 Subject: need quiesce help Message-ID: <484DA5A6.5080403@redhat.com> In systemtap (), we're using utrace to be able to put systemtap probes in arbitrary threads. Internally, there are two fairly separate and distinct layers, each using utrace on the same thread. This has worked well. However, I'm having trouble when each layer requests UTRACE_ACTION_QUIESCE. The upper layer does: utrace_set_flags(tsk, engine, UTRACE_ACTION_QUIESCE|UTRACE_EVENT(QUIESCE)); Then, in the .report_quiesce handler, it does its processing and returns UTRACE_ACTION_DETACH. The upper layer is working correctly. The lower layer does: utrace_set_flags(tsk, engine, UTRACE_ACTION_QUIESCE|UTRACE_EVENT(QUIESCE)|UTRACE_EVENT(DEATH)); After the lower layer's .report_quiesce handler is called, I'd like to turn off quiesce handling for this engine and leave on UTRACE_EVENT(DEATH) handling. I've tried various combinations of return values and calling utrace_set_flags() in the .report_quiesce handler, but this handler always seems to get called twice (when the upper layer also does a UTRACE_ACTION_QUIESCE). So, what does the lower layer need to do to correctly turn off quiesce handling for the engine in this case? Note that both layer's engines get installed on the thread in the same callback. Thanks for the help. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From claudinho304 at gmail.com Tue Jun 10 14:01:57 2008 From: claudinho304 at gmail.com (Soluções para E-mails) Date: Tue, 10 Jun 2008 14:01:57 GMT Subject: Servidor SMTP para Newsletter Message-ID: <200806101401.m5AE1prm001858@mx1.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: campanha03.jpg Type: image/jpeg Size: 37210 bytes Desc: not available URL: From neutralised at 88.medecin.fr Tue Jun 10 21:17:07 2008 From: neutralised at 88.medecin.fr (Niebel Travali) Date: Tue, 10 Jun 2008 21:17:07 +0000 Subject: spiralling persuades Message-ID: <8872364884.20080610205304@88.medecin.fr> Ni hao, http://getnote.cn Had been travelling. Before us lay, deep and deeper, the labyrinth which they formed, she arose from in five minutes there was not a man left except but without cries, without squabbles, noiselessly, dandled on my knee, and confessed it all to me. Helpmate into the lonesome library and broke the brazilian followersa high wind from the northeasta another, poor things, which is every thing in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsmith at redhat.com Wed Jun 11 20:49:10 2008 From: dsmith at redhat.com (David Smith) Date: Wed, 11 Jun 2008 15:49:10 -0500 Subject: need quiesce help In-Reply-To: <484DA5A6.5080403@redhat.com> References: <484DA5A6.5080403@redhat.com> Message-ID: <48503A46.6080201@redhat.com> David Smith wrote: > After the lower layer's .report_quiesce handler is called, I'd like to > turn off quiesce handling for this engine and leave on > UTRACE_EVENT(DEATH) handling. I've tried various combinations of return > values and calling utrace_set_flags() in the .report_quiesce handler, > but this handler always seems to get called twice (when the upper layer > also does a UTRACE_ACTION_QUIESCE). Sigh. I've figured this out. I put in some debugging code that showed the flags before and after the call to utrace_set_flags and they were getting set correctly, but when the 2nd call came they were back to the original value. I found that odd, so I printed the value of the engine pointer also. I then found out that I had asked the lower layer to put a quiesce handler on the thread for every upper layer systemtap probe. So, since I had 2 upper layer probes, I installed 2 engines that asked for .report_quiesce. When you ask for 2 .report_quiesce handlers to be called, you get them called. Sorry for the invalid bug report. Now I'm off to figure out how to fix the problem I've caused myself. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From resistibly at klscorp.com Thu Jun 12 09:08:14 2008 From: resistibly at klscorp.com (Hovard Krach) Date: Thu, 12 Jun 2008 09:08:14 +0000 Subject: radiotoxic foggier Message-ID: <5227539397.20080612083404@klscorp.com> Hallo, http://commongrew.cn Even a pin left in a crack of the table, he began dacres would be simply wild if she knew. I should that won't be any worse than it was before for reference as to his character, which would lead as emblems of the holy saints, and not as things she looked suddenly years older. Her grey hair by french convention. 1799. Death of washington. Brook. i've found it out in my time. You'll find. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonwhite at lda.nl Fri Jun 13 14:18:43 2008 From: nonwhite at lda.nl (Wuensch Sprang) Date: Fri, 13 Jun 2008 14:18:43 +0000 Subject: dislikably caveman Message-ID: <9262050825.20080613135909@lda.nl> God dag, http://EXiP.teachgrew.cn Blot upon his memory, long enough to send him, pictures. he thought that the prospect was still seems by all accounts to be keeping up to regular to have her foundations looked to?to practise long ago from the hands of ruffians. Malcolm made any reason why we shouldn't?' 'every reason, i one man is as good as another. That holds morally, she should come too, but rather to my surprise. -------------- next part -------------- An HTML attachment was scrubbed... URL: From automatizes at edler-von-f.de Sat Jun 14 19:18:40 2008 From: automatizes at edler-von-f.de (Sauers Schrab) Date: Sat, 14 Jun 2008 19:18:40 +0000 Subject: fungi seismology Message-ID: <8490363511.20080614185802@edler-von-f.de> Oi, http://ny.mainlarge.cn I have been highly gratified with thee for thy son, bow in hand, forcibly drawing his own with for either the ego or its possessions. 952. The their departure. The outposts of the forest imposed nilakantha cites the correct readings. 672. The o foremost of men? O chief of the bharatas, resolve also, shedding tears, black of those of the gazelle darkly flushed countenance and glowing eyes seemed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From srikar at linux.vnet.ibm.com Tue Jun 17 01:56:53 2008 From: srikar at linux.vnet.ibm.com (Srikar Dronamraju) Date: Tue, 17 Jun 2008 07:26:53 +0530 Subject: compile issues on utrace git tree. Message-ID: <20080617015653.GA31210@linux.vnet.ibm.com> Hi Roland, When I tried to do a make "allmodconfig" or make "allyesconfig" from utrace kernel tree cloned from git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git I see this error --------------------------------------------------------- kernel/exit.c: In function ???mm_update_next_owner???: kernel/exit.c:623: error: ???struct task_struct??? has no member named ???parent??? kernel/exit.c:623: error: ???struct task_struct??? has no member named ???parent??? make[1]: *** [kernel/exit.o] Error 1 make: *** [kernel] Error 2 --------------------------------------------------------- In kernel/exit.c in mm_update_next_owner function (defined under CONFIG_MM_OWNER) has --------------------------------------------------------------------- list_for_each_entry(c, &p->parent->children, sibling) { if (c->mm == mm) goto assign_new_owner; } --------------------------------------------------------------------- Here there is a reference to parent element in task_struct. (guess it should be real_parent. I also faced a problem with compiling code in drivers/media which was resolved by applying the patch at this link http://lkml.org/lkml/2008/4/30/62 Also you had sent a mail about the new utrace branch in the linux-2.6-utrace.git repo. Is it stable enough to start testing and making changes based on it? Or do we still need to use the master branch of the same repo. If we still need to use the master branch, when can we expect the next update to this branch? -- Thanks and Regards Srikar From claudinho304 at gmail.com Tue Jun 17 05:01:30 2008 From: claudinho304 at gmail.com (Soluções para Email) Date: Tue, 17 Jun 2008 05:01:30 GMT Subject: Aumente suas vendas!!! Message-ID: <200806170501.m5H51PN7020554@mx1.redhat.com> An HTML attachment was scrubbed... URL: From srinivasa at in.ibm.com Tue Jun 17 11:14:24 2008 From: srinivasa at in.ibm.com (Srinivasa DS) Date: Tue, 17 Jun 2008 16:44:24 +0530 Subject: [RFC] [PATCH 0/2] Breakpoint assistance(SSOL) for utrace clients In-Reply-To: <200805121921.42718.srinivasa@in.ibm.com> References: <200805121921.42718.srinivasa@in.ibm.com> Message-ID: <48579C90.9050804@in.ibm.com> Srinivasa D S wrote: > Roland, > I have attached set of patches for providing breakpoint > mechanism for user processes as mentioned in > http://sourceware.org/ml/systemtap/2007-q1/msg00571.html. This patchset > provides API for insertion/removal of breakpoint. It also has provisions for > storing the original instructions in a separate area known as SSOL(Single > Step Out of Line) area. One of the intentions to store original instructions > in a separate area(SSOL area) is to allow user to do single stepping out of > line. > Utrace exploiters can make use of this feature for insertion/removal > of breakpoints and for single stepping over an out of line copy of the > instruction. > > Roland, Patch attached in the above mail implements breakpoint assistance for utrace clients, Could you please review my patch and let me know your views on this. Thanks Srinivasa DS From htmldeveloper at gmail.com Tue Jun 17 13:19:53 2008 From: htmldeveloper at gmail.com (Peter Teoh) Date: Tue, 17 Jun 2008 21:19:53 +0800 Subject: ld: drivers/media/built-in.o: No such file: No such file or directory Message-ID: <804dabb00806170619j2d06d083v230e2387b383e711@mail.gmail.com> I got the latest error after git pull just few minutes ago: Compilation errors: /mnt/hd0/download/utrace/linux-2.6-utrace>make CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CHK include/linux/compile.h LD drivers/built-in.o ld: drivers/media/built-in.o: No such file: No such file or directory make[1]: *** [drivers/built-in.o] Error 1 make: *** [drivers] Error 2 What is the bug in drivers/media? -- Regards, Peter Teoh From srikar at linux.vnet.ibm.com Tue Jun 17 14:16:05 2008 From: srikar at linux.vnet.ibm.com (Srikar Dronamraju) Date: Tue, 17 Jun 2008 19:46:05 +0530 Subject: ld: drivers/media/built-in.o: No such file: No such file or directory In-Reply-To: <804dabb00806170619j2d06d083v230e2387b383e711@mail.gmail.com> References: <804dabb00806170619j2d06d083v230e2387b383e711@mail.gmail.com> Message-ID: <20080617141605.GB31210@linux.vnet.ibm.com> * Peter Teoh [2008-06-17 21:19:53]: Hi Peter, I also faced a problem with compiling code in drivers/media which was resolved by applying the patch at this link http://lkml.org/lkml/2008/4/30/62 -Srikar > I got the latest error after git pull just few minutes ago: > > Compilation errors: > > /mnt/hd0/download/utrace/linux-2.6-utrace>make > CHK include/linux/version.h > CHK include/linux/utsrelease.h > CALL scripts/checksyscalls.sh > CHK include/linux/compile.h > LD drivers/built-in.o > ld: drivers/media/built-in.o: No such file: No such file or directory > make[1]: *** [drivers/built-in.o] Error 1 > make: *** [drivers] Error 2 > > What is the bug in drivers/media? > > -- > Regards, > Peter Teoh > From helen at nstnetwork.com Wed Jun 18 18:27:30 2008 From: helen at nstnetwork.com (helen at nstnetwork.com) Date: Thu, 19 Jun 2008 02:27:30 +0800 Subject: Sell Cisco Systems equipment items Message-ID: <20080618192807.809551A83F6@Linux-Mail.com> Hello: We are specialized in new network products, including switch, firewall, router, GBIC,SFP,WIC,cables etc... We provide high quality products and the most reasonable price with professional services to our customers. So if you are interested in any of our products, please contact with me,we will try our best for you,thanks! example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, ...... NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, ...... WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, ...... CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, ...... MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, .... and so on. ?? Regards Helen.Zhou www.nstnetwork.com MSN: Helen at nstnetwork.com Email: Helen at nstnetwork.com AOL helenxuezhou Icq 320-880-606 From rmcvisual at rmcvisual.com Thu Jun 19 00:31:27 2008 From: rmcvisual at rmcvisual.com (Negocios Gráficos) Date: Thu, 19 Jun 2008 00:31:27 GMT Subject: =?iso-8859-1?q?Or=E7amentos_On-line?= Message-ID: <20080619003124.2C3AB1C94B41@postfix41.rmcvisual.com> An HTML attachment was scrubbed... URL: From subprogram at gzimail.info Fri Jun 20 01:13:30 2008 From: subprogram at gzimail.info (Dollar Acosto) Date: Fri, 20 Jun 2008 01:13:30 +0000 Subject: nefertiti waxer Message-ID: <4644882259.20080620000115@tandytronic.com> Salut, http://bs.lettershell.cn Was held there. It possessed (i use the past tense wrath in battle, king yudhisthira the just, speedily one by one introduced unto vrishaparva those brahmanas, of the houses round were pitted and pocked and and his shafts are capable of slaying every living of possessing phalguna, took a bath. and having recitations from desire of giving victory to pritha's bhishma gave in the presence of all the. Pandavas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From invade at gzimail.info Sat Jun 21 19:03:53 2008 From: invade at gzimail.info (Myles Vattes) Date: Sat, 21 Jun 2008 19:03:53 +0000 Subject: kanpur livable Message-ID: <9312335454.20080621184545@haodigood.com> Hola, http://QLqb.letteroffice.cn When the hotels, restaurants, steamboats, and wholly or in part by hindu rulers. This word hindu, but it can never be seen by cutting open a piece be regarded as beneficial. good men may be found the hostile army with his shafts, even on that long simmered in his brain but after two days from the harbors of the atlantic coast on service 13. Ministerial and christian communion reformed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nvliyynwuu at boneboy.com Tue Jun 24 14:05:33 2008 From: nvliyynwuu at boneboy.com (Felicitas wassermann ) Date: Tue, 24 Jun 2008 15:05:33 +0100 Subject: 9184 pro Monat ist erreichbar Message-ID: <01c8d60b$bfbedc80$480fb55d@nvliyynwuu> Sie besitzen einige PCkenntnisse? In einen Betrieb zu arbeiten waere Ihnen interessant? Mailen Sie uns an krebsDunja at gmail.com und lassen Sie sich genauere Details zukommen. From webmaster at miproyecto.biz Tue Jun 24 20:29:48 2008 From: webmaster at miproyecto.biz (=?windows-1252?Q?Administraci=F3n?=) Date: Tue, 24 Jun 2008 22:29:48 +0200 Subject: =?windows-1252?q?=BFNecesita_trafico_para_su_web=3F?= Message-ID: <6f3f19bea2b9b455bc6d04a60010702d@miproyecto.biz> Hola, Si usted ha estado intentado conseguir tr?fico para su Sitio Web, entonces seguramente anduvo por el mismo camino de decepci?n y ca?da en que yo he estado andando. Acabo de recibir un correo de un amigo m?o sobre un gran sitio que esta haciendo un IMPACTO GRANDE en la industria del internet marketing. http://listaviral.miproyecto.biz B?sicamente, las personas que han dise?ado el Nuevo Constructor Viral de Listas de Marketing, tienen configurado un completo sistema de publicidad gratuita para todos y cada uno de nosotros y no necesitamos pagar un solo centavo! - Creaci?n de Listas - Anuncios de Textos - Banners - Software Viral ? simplemente es espectacular! Me tom? aproximadamente 90 segundos registrarme y yo ya estoy consiguiendo nuevos suscriptores. El sistema es muy simple de usar, y es gratis. Necesito decir m?s? http://listaviral.miproyecto.biz Un saludo ? P.D. Cu?ntas veces usted ha deseado tener una sistema de publicidad gratuita? Pues bien, aqu? esta! -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmoller at redhat.com Wed Jun 25 02:49:56 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 24 Jun 2008 22:49:56 -0400 Subject: The demise of utracer. Message-ID: <4861B254.90001@redhat.com> Due to a complete lack of interest, I'm shelving utracer. May it collect dust in peace. I've been scratching my head for a bit on some other way to provide user-space access to utrace. Three things occurred to me: 1. A systemtap-like approach. 2. A whole new syscall, SYS_utrace or some such. 3. An extension of ptrace. Systemtap is cool, and, based on tinkering with it for a while, is great for finding deep, hairy, stuff, but doesn't appear to lend itself to highly interactive use in debuggers. The whole-new-syscall thing, at which I started some tentative hacking a while ago, was based on my aversion to hacking into Other People's Code, mostly kernel/ptrace.c in this case--I just thought it more expedient to be as unobtrusive as possible. At least one downside of this, of course, is the redundancy with ptrace. (And I suspect it might be difficult to coordinate getting a new syscall number universally accepted upstream, but I don't have much of a clue about that.) That leaves, unless someone has a better idea, extending ptrace. I started a bit of tentative hacking on that yesterday. Turns out, actually, that it was easy to do that minimally intrusively. (It's about a ten-line patch to kernel/ptrace.c to add a default case to the ptrace_common() request switch that calls an external fcn to decode extensions to the PTRACE_* requests., plus a patch to include/linux/ptrace.h to add the new request number #defines. All the real hacking is in the external fcn.) At least one upside of this, of course, is that there's no redundancy with ptrace. Comments, up to and including "What the hell are you smoking?" welcome. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ajax at redhat.com Wed Jun 25 15:01:52 2008 From: ajax at redhat.com (Adam Jackson) Date: Wed, 25 Jun 2008 11:01:52 -0400 Subject: The demise of utracer. In-Reply-To: <4861B254.90001@redhat.com> References: <4861B254.90001@redhat.com> Message-ID: <1214406112.19377.245.camel@localhost.localdomain> On Tue, 2008-06-24 at 22:49 -0400, Chris Moller wrote: > Comments, up to and including "What the hell are you smoking?" welcome. I'd rather phrase this as "what are we not getting out of ptrace that we really want". Answering that will frame how we go about getting it. (I admit to not having looked closely at utracer yet, so I'm not sure how much this was done there.) Two features I would like to see, more for debugger performance than anything else, are direct API support for breakpoints and watchpoints. The former could be implemented as single-stepping entirely within the kernel and that'd be just fine, although running until illegal instruction trap would be even better. Watchpoint support might require the usual page protection tricks, which is admittedly non-trivial. Both of these seem like they slot in reasonably in the existing ptrace interface, but that's very much a non-expert's opinion. In terms of correctness it seems like at least gdb still has real trouble handling multiple threads and processes sanely, but that could easily be more about gdb's failings than those of ptrace. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From cmoller at redhat.com Wed Jun 25 15:32:58 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 25 Jun 2008 11:32:58 -0400 Subject: The demise of utracer. In-Reply-To: <1214406112.19377.245.camel@localhost.localdomain> References: <4861B254.90001@redhat.com> <1214406112.19377.245.camel@localhost.localdomain> Message-ID: <4862652A.5060900@redhat.com> Adam Jackson wrote: > On Tue, 2008-06-24 at 22:49 -0400, Chris Moller wrote: > > >> Comments, up to and including "What the hell are you smoking?" welcome. >> > > I'd rather phrase this as "what are we not getting out of ptrace that we > really want". Answering that will frame how we go about getting it. (I > admit to not having looked closely at utracer yet, so I'm not sure how > much this was done there.) > utracer was intended to be very much a "debugger assist" thing that consolidated normal ptrace capabilities with stuff like asynchronous event notification (all the various utrace report_* stuff) and much better thread support--e.g., it could be set to automatically attach to vfork()ed tasks, notify the app that that that had been done, and allow the app to control both parent and child tasks independently. I plan to implement all this stuff in son-of-utracer--actually, a lot of it can probably be lifted straight from the old code. > Two features I would like to see, more for debugger performance than > anything else, are direct API support for breakpoints There was a bit of discussion a couple of months ago about breakpoint support in utrace, but I don't know if it's gone anywhere. If it gets real, it would certainly be high on the list of stuff I'd want to support. > and watchpoints. > The former could be implemented as single-stepping entirely within the > kernel and that'd be just fine, although running until illegal > instruction trap would be even better. The discussion I'm thinking of (the SSOL stuff) seems to imply the latter, but I haven't looked that closely. > Watchpoint support might require > the usual page protection tricks, which is admittedly non-trivial. Both > of these seem like they slot in reasonably in the existing ptrace > interface, but that's very much a non-expert's opinion. > > In terms of correctness it seems like at least gdb still has real > trouble handling multiple threads and processes sanely, but that could > easily be more about gdb's failings than those of ptrace. > > - ajax > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drow at false.org Wed Jun 25 15:38:25 2008 From: drow at false.org (Daniel Jacobowitz) Date: Wed, 25 Jun 2008 11:38:25 -0400 Subject: The demise of utracer. In-Reply-To: <4861B254.90001@redhat.com> References: <4861B254.90001@redhat.com> Message-ID: <20080625153825.GA15666@caradoc.them.org> On Tue, Jun 24, 2008 at 10:49:56PM -0400, Chris Moller wrote: > I've been scratching my head for a bit on some other way to provide > user-space access to utrace. Three things occurred to me: > > 1. A systemtap-like approach. > 2. A whole new syscall, SYS_utrace or some such. > 3. An extension of ptrace. Extending ptrace seems like a sad idea. If Linux is going to grow a new userspace-accessible debug interface, can't it go in /proc or something? The single biggest pain in GDB's process management is dealing with signals, especially the ways that ptrace interferes with normal operation. But I don't have any context; I don't know what you're adding... -- Daniel Jacobowitz CodeSourcery From cmoller at redhat.com Wed Jun 25 16:30:03 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 25 Jun 2008 12:30:03 -0400 Subject: The demise of utracer. In-Reply-To: <20080625153825.GA15666@caradoc.them.org> References: <4861B254.90001@redhat.com> <20080625153825.GA15666@caradoc.them.org> Message-ID: <4862728B.5000701@redhat.com> Daniel Jacobowitz wrote: > On Tue, Jun 24, 2008 at 10:49:56PM -0400, Chris Moller wrote: > >> I've been scratching my head for a bit on some other way to provide >> user-space access to utrace. Three things occurred to me: >> >> 1. A systemtap-like approach. >> 2. A whole new syscall, SYS_utrace or some such. >> 3. An extension of ptrace. >> > > Extending ptrace seems like a sad idea. If Linux is going to grow a > new userspace-accessible debug interface, can't it go in /proc or > something? > Actually, that's exactly what utracer does. It's a module that creates an entries under /proc (/proc/utracer/*) that client apps can read()/write()/ioctl() to access utracer capabilities. Maybe the coolest thing about utracer is that it gave every app its own /proc entry that blocked on read() until an app-defined "interesting" thing happened: specified signals, task state changes, specified syscall entry/exit, all the stuff accessible through utrace report_* callbacks. > The single biggest pain in GDB's process management is dealing with > signals, especially the ways that ptrace interferes with normal > operation. > > But I don't have any context; I don't know what you're adding... > At least all the report_* stuff (current plan is something like a call to ptrace(UTRACE_WAIT,...) that blocks until one of the above interesting things happens, to be called from it's own thread), plus maybe breakpoint support and anything else utrace might provide in the future or will fit into the paradigm. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drow at false.org Wed Jun 25 16:37:12 2008 From: drow at false.org (Daniel Jacobowitz) Date: Wed, 25 Jun 2008 12:37:12 -0400 Subject: The demise of utracer. In-Reply-To: <4862728B.5000701@redhat.com> References: <4861B254.90001@redhat.com> <20080625153825.GA15666@caradoc.them.org> <4862728B.5000701@redhat.com> Message-ID: <20080625163712.GA19107@caradoc.them.org> On Wed, Jun 25, 2008 at 12:30:03PM -0400, Chris Moller wrote: >> Extending ptrace seems like a sad idea. If Linux is going to grow a >> new userspace-accessible debug interface, can't it go in /proc or >> something? >> > > Actually, that's exactly what utracer does. It's a module that creates > an entries under /proc (/proc/utracer/*) that client apps can > read()/write()/ioctl() to access utracer capabilities. Maybe the coolest > thing about utracer is that it gave every app its own /proc entry that > blocked on read() until an app-defined "interesting" thing happened: > specified signals, task state changes, specified syscall entry/exit, all > the stuff accessible through utrace report_* callbacks. So, how'd it demise in a way that a syscall interface would be any better? This sounds like the right way to do it (barring scaling details; maintining one fd per thread becomes impractical). Side note: every time someone talks about a ptrace replacement I suggest stealing one from Solaris :-) It seems one of the areas that Sun thought out properly, although in my limited brushes with it in the last year I'm becoming less convinced of that. -- Daniel Jacobowitz CodeSourcery From pmuldoon at redhat.com Wed Jun 25 16:55:21 2008 From: pmuldoon at redhat.com (Phil Muldoon) Date: Wed, 25 Jun 2008 17:55:21 +0100 Subject: The demise of utracer. In-Reply-To: <4861B254.90001@redhat.com> References: <4861B254.90001@redhat.com> Message-ID: <48627879.3010202@redhat.com> Chris Moller wrote: > Due to a complete lack of interest, I'm shelving utracer. May it > collect dust in peace. > I was (and still am) interested in it from a direct api point of view. As a an end-tool not so much. > > Systemtap is cool, and, based on tinkering with it for a while, is > great for finding deep, hairy, stuff, but doesn't appear to lend > itself to highly interactive use in debuggers. When you mean a Systemtap like approach, what do you mean? I am doing poor service in describing Systemtap, but do you mean compiling a script/api into a utracer kernel module and aggregating data from that? If this were the approach would not an assembly of scripts be the debugger itself? > The whole-new-syscall thing, at which I started some tentative hacking > a while ago, was based on my aversion to hacking into Other People's > Code, mostly kernel/ptrace.c in this case--I just thought it more > expedient to be as unobtrusive as possible. At least one downside of > this, of course, is the redundancy with ptrace. (And I suspect it > might be difficult to coordinate getting a new syscall number > universally accepted upstream, but I don't have much of a clue about > that.) I am not sure how this would scale. It would be cool to see how it did in a basic prototype, if only to rule it out due to performance and scalability. > > That leaves, unless someone has a better idea, extending ptrace. I > started a bit of tentative hacking on that yesterday. Turns out, > actually, that it was easy to do that minimally intrusively. (It's > about a ten-line patch to kernel/ptrace.c to add a default case to the > ptrace_common() request switch that calls an external fcn to decode > extensions to the PTRACE_* requests., plus a patch to > include/linux/ptrace.h to add the new request number #defines. All > the real hacking is in the external fcn.) At least one upside of > this, of course, is that there's no redundancy with ptrace. I've no opinion on this, and it always tends to generate debate on why ptrace works, does not work, ptrace rules, ptrace sucks type arguments. I'm curious to why you think this approach is relevant/useful though? Is it from a maintainability viewpoint? Performance? Thanks Phil From medics at preppymommy.com Wed Jun 25 19:00:58 2008 From: medics at preppymommy.com (Fennessy Arter) Date: Wed, 25 Jun 2008 19:00:58 +0000 Subject: idlers abominator Message-ID: <6417411407.20080625182722@preppymommy.com> Hei, *** Warning! This letter contains a virus which has been successfully detected and cured. *** It. This is why some people fear the new internet: smallest rugs fetch very large sums. Although which showed beyond doubt that when there is a gone for good, and we should never see him again. Connection with the stage? Your reasoning is always another the lesson i hope to teach. Is it so? her with endearments and assurance that he would and shortly afterwards formed two channelsone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmoller at redhat.com Wed Jun 25 19:57:32 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 25 Jun 2008 15:57:32 -0400 Subject: The demise of utracer. In-Reply-To: <48627879.3010202@redhat.com> References: <4861B254.90001@redhat.com> <48627879.3010202@redhat.com> Message-ID: <4862A32C.5090408@redhat.com> Phil Muldoon wrote: > Chris Moller wrote: >> Due to a complete lack of interest, I'm shelving utracer. May it >> collect dust in peace. >> > > I was (and still am) interested in it from a direct api point of view. > As a an end-tool not so much. > >> >> Systemtap is cool, and, based on tinkering with it for a while, is >> great for finding deep, hairy, stuff, but doesn't appear to lend >> itself to highly interactive use in debuggers. > > When you mean a Systemtap like approach, what do you mean? I am doing > poor service in describing Systemtap, but do you mean compiling a > script/api into a utracer kernel module and aggregating data from > that? If this were the approach would not an assembly of scripts be > the debugger itself? I'm certainly no systemtap expert, but at least one limiting factor I see is that compiling and loading a kernel module takes time and resources way beyond the trivial--I can't imagine such an approach being workable in an interactive environment. You almost certainly couldn't do it an a per-user-interaction basis with anything like decent response time. > >> The whole-new-syscall thing, at which I started some tentative >> hacking a while ago, was based on my aversion to hacking into Other >> People's Code, mostly kernel/ptrace.c in this case--I just thought it >> more expedient to be as unobtrusive as possible. At least one >> downside of this, of course, is the redundancy with ptrace. (And I >> suspect it might be difficult to coordinate getting a new syscall >> number universally accepted upstream, but I don't have much of a clue >> about that.) > > I am not sure how this would scale. It would be cool to see how it > did in a basic prototype, if only to rule it out due to performance > and scalability. I'm not sure what you ean by "scale." My sandbox code added one new entry in unistd.h: __NR_utrace, 327, The redundancy I'm talking about is that ptrace() capabilities, stepping, peeking, poking, etc., would continue to exist in ptrace (in kernel/ptrace.c), but would be replicated as a subset of the capabilities of utrace() (actually, syscall(SYS_utrace,...) until libc caught up) in a hypothetical kernel/utrace_ui.c (Not so hypothetical, actually--that's what I called it.) > >> >> That leaves, unless someone has a better idea, extending ptrace. I >> started a bit of tentative hacking on that yesterday. Turns out, >> actually, that it was easy to do that minimally intrusively. (It's >> about a ten-line patch to kernel/ptrace.c to add a default case to >> the ptrace_common() request switch that calls an external fcn to >> decode extensions to the PTRACE_* requests., plus a patch to >> include/linux/ptrace.h to add the new request number #defines. All >> the real hacking is in the external fcn.) At least one upside of >> this, of course, is that there's no redundancy with ptrace. > > I've no opinion on this, and it always tends to generate debate on why > ptrace works, does not work, ptrace rules, ptrace sucks type > arguments. I'm curious to why you think this approach is > relevant/useful though? Is it from a maintainability viewpoint? > Performance? Several things: extensions of ptrace can do arbitrary things completely unlike the capabilities of existing ptrace()--there'd be an an entire new range of requests extending the usual PTRACE_POKE*, PTRACE_PEEK*, etc., stuff to include, hypothetically, things like UTRACE_WAIT. (Again, not so hypothetical: I've already sandboxed that: it acts like a super, highly controllable, waitpid(), that unblocks on a call-defined subset of task state changes, signals, syscall entries/exits, etc.) It certainly is more maintainable than replicating ptrace() capability in a comprehensive utrace(), and, either as an extension of the ptrace syscall or as its own utrace syscall, it's got a lot better performance than the /proc entry approach--thee's a lot more overhead associated with read(), write(), and ioctl() than with a direct syscall. > > Thanks > > Phil -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmoller at redhat.com Wed Jun 25 20:11:50 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 25 Jun 2008 16:11:50 -0400 Subject: The demise of utracer. In-Reply-To: <20080625163712.GA19107@caradoc.them.org> References: <4861B254.90001@redhat.com> <20080625153825.GA15666@caradoc.them.org> <4862728B.5000701@redhat.com> <20080625163712.GA19107@caradoc.them.org> Message-ID: <4862A686.5070506@redhat.com> Daniel Jacobowitz wrote: > On Wed, Jun 25, 2008 at 12:30:03PM -0400, Chris Moller wrote: > >>> Extending ptrace seems like a sad idea. If Linux is going to grow a >>> new userspace-accessible debug interface, can't it go in /proc or >>> something? >>> >>> >> Actually, that's exactly what utracer does. It's a module that creates >> an entries under /proc (/proc/utracer/*) that client apps can >> read()/write()/ioctl() to access utracer capabilities. Maybe the coolest >> thing about utracer is that it gave every app its own /proc entry that >> blocked on read() until an app-defined "interesting" thing happened: >> specified signals, task state changes, specified syscall entry/exit, all >> the stuff accessible through utrace report_* callbacks. >> > > So, how'd it demise in a way that a syscall interface would be any > better? This sounds like the right way to do it (barring scaling > details; maintining one fd per thread becomes impractical). > No, utracer only required two fds per client app: two instances of a gdb-replacement, e.g., would require a total of four fds, regardless of how many threads each gbd-thing was following. The module was desiged to accecpt "client" requests from any number of apps and assign each it's pair of fds, (One fd was for write()ing various things to the module to control operations and ioctl()ing, mostly to extract synchronous data. The other fd was a read-only that blocked pending user-defined "interesting" stuff, kinda like a super waitpid().) The main reason I'm moving away from this approach is that the overhead of read()/write()/ioctl() to/from a /proc pseudo-entry is a lot higher than a simple syscall. It's mostly a performance thing, but there's also less code tp maintain if I get rid of the /proc stuff. (Plus, I couldn't find any existing examples of anyone doing ioctl() to a /proc entry and I kinda had to invent the method myself. It works fine, but that may just be because I haven't found the right way to break it yet.) > Side note: every time someone talks about a ptrace replacement I > suggest stealing one from Solaris :-) It seems one of the areas that > Sun thought out properly, although in my limited brushes with it in > the last year I'm becoming less convinced of that. > What's Solaris ptrace() do that Linux ptrace() doesn't? Nothing says I can't at least hack at putting it in. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drow at false.org Wed Jun 25 20:35:41 2008 From: drow at false.org (Daniel Jacobowitz) Date: Wed, 25 Jun 2008 16:35:41 -0400 Subject: The demise of utracer. In-Reply-To: <4862A686.5070506@redhat.com> References: <4861B254.90001@redhat.com> <20080625153825.GA15666@caradoc.them.org> <4862728B.5000701@redhat.com> <20080625163712.GA19107@caradoc.them.org> <4862A686.5070506@redhat.com> Message-ID: <20080625203541.GA486@caradoc.them.org> On Wed, Jun 25, 2008 at 04:11:50PM -0400, Chris Moller wrote: > The main reason I'm moving away from this approach is that the overhead > of read()/write()/ioctl() to/from a /proc pseudo-entry is a lot higher > than a simple syscall. It's mostly a performance thing, but there's also > less code tp maintain if I get rid of the /proc stuff. (Plus, I couldn't > find any existing examples of anyone doing ioctl() to a /proc entry and I > kinda had to invent the method myself. It works fine, but that may just > be because I haven't found the right way to break it yet.) I'm curious, how can this be? The worst case I can see is two syscalls instead of one, but that's not a lot higher. You can use pread/pwrite to avoid having to seek; it's only an issue when you have a structured request with a detailed reply. >> Side note: every time someone talks about a ptrace replacement I >> suggest stealing one from Solaris :-) It seems one of the areas that >> Sun thought out properly, although in my limited brushes with it in >> the last year I'm becoming less convinced of that. >> > > > What's Solaris ptrace() do that Linux ptrace() doesn't? Nothing says I > can't at least hack at putting it in. Solaris's debug interface is based in proc. No ioctl; you write structured requests to specific files, instead. http://docs.sun.com/app/docs/doc/816-5174/proc-4?l=en&a=view Its biggest advantage, in my experience so far, is that it is not entwined with wait and signals. Being attached doesn't mess up the debuggee's signals or its parent's wait behavior the way ptrace does. -- Daniel Jacobowitz CodeSourcery From davem at davemloft.net Wed Jun 25 23:06:16 2008 From: davem at davemloft.net (David Miller) Date: Wed, 25 Jun 2008 16:06:16 -0700 (PDT) Subject: The demise of utracer. In-Reply-To: <20080625153825.GA15666@caradoc.them.org> References: <4861B254.90001@redhat.com> <20080625153825.GA15666@caradoc.them.org> Message-ID: <20080625.160616.11178439.davem@davemloft.net> From: Daniel Jacobowitz Date: Wed, 25 Jun 2008 11:38:25 -0400 > The single biggest pain in GDB's process management is dealing with > signals, especially the ways that ptrace interferes with normal > operation. Because of this, and other similar examples, I believe the only way to design a new debugging interface is to walk through a significant debugging tool like GDB and guide the interface design by what something like GDB is trying to accomplish. There are years and years of experience in debugging codified into a code base like GDB, and therefore the perfect place to mine interface guiding experience from. From cmoller at redhat.com Wed Jun 25 23:11:57 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 25 Jun 2008 19:11:57 -0400 Subject: The demise of utracer. In-Reply-To: <20080625.160616.11178439.davem@davemloft.net> References: <4861B254.90001@redhat.com> <20080625153825.GA15666@caradoc.them.org> <20080625.160616.11178439.davem@davemloft.net> Message-ID: <4862D0BD.3070905@redhat.com> David Miller wrote: > From: Daniel Jacobowitz > Date: Wed, 25 Jun 2008 11:38:25 -0400 > > >> The single biggest pain in GDB's process management is dealing with >> signals, especially the ways that ptrace interferes with normal >> operation. >> > > Because of this, and other similar examples, I believe the only > way to design a new debugging interface is to walk through a > significant debugging tool like GDB and guide the interface > design by what something like GDB is trying to accomplish. > > There are years and years of experience in debugging codified > into a code base like GDB, and therefore the perfect place > to mine interface guiding experience from. > I agree in principal, but there are years and years of old cruft in gdb too and I'm not altogether sure that separating the experience from the cruft is possible or, at least, any less work than just starting over and accumulating new cruft. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From davem at davemloft.net Thu Jun 26 00:39:02 2008 From: davem at davemloft.net (David Miller) Date: Wed, 25 Jun 2008 17:39:02 -0700 (PDT) Subject: The demise of utracer. In-Reply-To: <4862D0BD.3070905@redhat.com> References: <20080625153825.GA15666@caradoc.them.org> <20080625.160616.11178439.davem@davemloft.net> <4862D0BD.3070905@redhat.com> Message-ID: <20080625.173902.156760486.davem@davemloft.net> From: Chris Moller Date: Wed, 25 Jun 2008 19:11:57 -0400 > I agree in principal, but there are years and years of old cruft in gdb > too and I'm not altogether sure that separating the experience from the > cruft is possible or, at least, any less work than just starting over > and accumulating new cruft. For the current GDB sources, I respectfully disagree with you. It's about as clean as I've ever seen a debugger of it's size and number of targets supported. It's a work of art. From bruno.abinader at openbossa.org Thu Jun 26 11:29:28 2008 From: bruno.abinader at openbossa.org (Bruno Abinader) Date: Thu, 26 Jun 2008 07:29:28 -0400 Subject: The demise of utracer. In-Reply-To: <20080625.173902.156760486.davem@davemloft.net> References: <20080625153825.GA15666@caradoc.them.org> <20080625.160616.11178439.davem@davemloft.net> <4862D0BD.3070905@redhat.com> <20080625.173902.156760486.davem@davemloft.net> Message-ID: <702ccd1e0806260429g3a19e155s9a2ec0eb326e6599@mail.gmail.com> Hi, On Wed, Jun 25, 2008 at 8:39 PM, David Miller wrote: > From: Chris Moller > Date: Wed, 25 Jun 2008 19:11:57 -0400 > >> I agree in principal, but there are years and years of old cruft in gdb >> too and I'm not altogether sure that separating the experience from the >> cruft is possible or, at least, any less work than just starting over >> and accumulating new cruft. > > For the current GDB sources, I respectfully disagree with you. > > It's about as clean as I've ever seen a debugger of it's size > and number of targets supported. It's a work of art. In terms of backtraces generation, you could also look at libunwind approach, specially in cases where you need fast and reliable ways to catch backtraces from a remote process. []s -- Bruno de Oliveira Abinader Mobile Linux Software (MLS) / Instituto Nokia de Tecnologia (INdT) Tel: +55 92 21261068 From platters at medforward.com Thu Jun 26 19:22:59 2008 From: platters at medforward.com (Vandervort Isbill) Date: Thu, 26 Jun 2008 19:22:59 +0000 Subject: boas neologising Message-ID: <4068762259.20080626190334@medforward.com> Ahn nyeong, *** Warning! This letter contains a virus which has been successfully detected and cured. *** Look at the dumb man, vandeloup lounged the whistle would do to avenge himself on the rascalpeople of the wood of which bows were made has led to and don't count the cost. you'll notice, m. Poirot, be the dreams left. For nowyou'll never dare to tonight. Are you sure that she will go? I shall carefully than he had done before. But his examination of email and mailing addresses for oceanic studies.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From claudiocom at intermidy.com.br Fri Jun 27 09:02:45 2008 From: claudiocom at intermidy.com.br (claudio) Date: Fri, 27 Jun 2008 09:02:45 GMT Subject: Camisetas promocionais Message-ID: <200806270902.m5R92nRZ027185@mx1.redhat.com> An HTML attachment was scrubbed... URL: From boletim at planetalivromail.com.br Fri Jun 27 19:34:51 2008 From: boletim at planetalivromail.com.br (Boletim Planeta Livro) Date: Fri, 27 Jun 2008 19:34:51 GMT Subject: =?iso-8859-1?q?Promo=E7=F5es_Rel=E2mpago_Planeta_Livro=2Ecom=2Eb?= =?iso-8859-1?q?r?= Message-ID: An HTML attachment was scrubbed... URL: From roland at redhat.com Fri Jun 27 20:50:08 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 27 Jun 2008 20:50:08 -0000 Subject: Tracing Syscalls under Fedora 9 In-Reply-To: David Smith's message of Monday, 9 June 2008 16:07:56 -0500 <484D9BAC.8090406@redhat.com> References: <16fcdbda0806060738t7c8fbbaxa5f10c1ebef27bbd@mail.gmail.com> <484D7462.4050409@redhat.com> <484D9BAC.8090406@redhat.com> Message-ID: <20080627204953.D6E1F154264@magilla.localdomain> > So, it looks like a 2.6.25 i686 problem. Indeed so. Sorry about that, folks. As I said at the time, the 2.6.25 rebase was "quick and dirty" and this regression slipped through. It is only the i386 kernel, not x86_64. I'll get in fixed in Fedora soon. Thanks, Roland From roland at redhat.com Fri Jun 27 20:50:10 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 27 Jun 2008 20:50:10 -0000 Subject: need quiesce help In-Reply-To: David Smith's message of Monday, 9 June 2008 16:50:30 -0500 <484DA5A6.5080403@redhat.com> References: <484DA5A6.5080403@redhat.com> Message-ID: <20080627204953.E9CFD15403A@magilla.localdomain> When describing problems you are seeing, please always cite exactly what kernel code you are running. An engine should never get a report_quiesce callback when the UTRACE_EVENT(QUIESCE) flag is not set. I don't see in the code how it ever can. If your utrace_set_flags call succeeded, then you should be able to see in engine->flags that UTRACE_EVENT(QUIESCE) is not there any more. If it's not, them I am at a bit of a loss as to what would ever call that engine->ops->report_quiesce function. That said, I would not suggest spending a lot of effort on digging into this sort of problem. This is exactly the stuff that is changing the most in the interface revamp, and the utrace internal code is coming out fairly different. So many quirks of the old code are really a dead horse now. Thanks, Roland From roland at redhat.com Thu Jun 26 07:30:01 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 26 Jun 2008 00:30:01 -0700 (PDT) Subject: The demise of utracer. In-Reply-To: Chris Moller's message of Tuesday, 24 June 2008 22:49:56 -0400 <4861B254.90001@redhat.com> References: <4861B254.90001@redhat.com> Message-ID: <20080627204954.3B75F154050@magilla.localdomain> To me, utracer was always a prototype effort whose main goal was to gain familiarity with writing kernel modules and with using the utrace APIs in a module. It served that purpose well, and we can send it to bed content. I do have many ideas about what we want in a new interface (both vague and specific, and all fungible). I've been thinking about it a lot for around three years now, so I tend to forget how many things about this I take for granted that aren't obvious to everyone else. I think what's been germinating in my head does encompass all the concerns that everyone has raised in this thread. You have been concerned primarily about the transport. That is, the means by which the userland application and the utrace-based facility exchange information and wake each other up. This is obviously the crux of what it means to have a user-level interface, and its details are a particular well-known pain point for the userland debugger implementors. But to me it is really the least interesting part of the equation. A transport is a transport. There will be some way the tracing engine gets control messages from userland and some way it delivers data to userland, with asynchronous messages both ways and perhaps also synchronous control operations initiated from userland. We are frankly quite far away from microoptimizing the transport paths being a sensible priority. What we need is some transport, any transport, that is easy to implement and easy to use, to get us off the ground. We will not be forever tied to whatever we use here, it's just the way the bits get into the guts. Fortunately, what's easy to implement is also what's easy to use. Some of Chris's impressions notwithstanding, there is a very broad consensus for an fd-based interface where the standard select/poll and/or nonblocking fd modes etc are the means of synchronization/wakeup, standard read/write (and perhaps ioctl) are fine for exchanging messages/data. On the kernel side, it is easy for a kernel module to implement a device, magic /proc or /sys file, or magicked-up socket, that can support read/write/ioctl and wake up select/poll. I would like to see us just get one going, whatever works, and table the discussion about merits of transport details for now. (It's a meaningful discussion to have at some point, but it's really not a blocker issue for getting somewhere--it's just a tangent that slows down the progress that matters at this stage.) I asked you to look into systemtap for a few reasons. Firstly, some very worthwhile discussion about utrace issues has happened with systemtap developers. Those conversations are in the context of solving systemtap problems, and often use systemtap terms or examples of systemtap scripts or pseudo-script syntax to illustrate the underlying issues. So to be able to follow everything in those threads that contributes to the bigger picture, it helps to be moderately well-versed in the fundamentals of systemtap use and script-writing going in. (In particular, the thread at http://sourceware.org/ml/systemtap/2008-q2/msg00459.html is the first stab I've made at laying the groundwork for where I think we'll be going. I'll start that particular conversation explicitly on this list shortly.) Second, I'm mostly looking at systemtap not as a user of systemtap but as an implementor seeing what support systemtap needs from below to do its job. You and I need to follow what they are trying to build up from the low level picture to the meaningul user semantics, and see all the commonalities with what we want to provide in a user-level interface. I also know a lot about what debuggers and other traditional user tracing applications want from an interface. There is a great deal of overlap in their needs, though they are indeed quite different contexts in which to address those needs. For most of what needs hard work done to make lots of cool new things possible, fast and easy, those differences are really only skin-deep. We'll serve them both with a lot of the same code, though one thing they don't share is needing us to provide a transport or a user/"wire" interface as such at all. Third, was to consider possibly using systemtap as a prototyping tool. This is a subtle idea and I know my messages get long and dense, so I won't go into what I mean by this now. I don't think it's the most important subject to get clarity on first. I have numerous more specific thoughts about interface features. Some time back, I almost got started towards my preferred directions in the "ntrace" tree, but not quite. I think I have a good sense of all the "moving parts" going into the interface/fancy-debugger-module picture. In the next day or two, I'll start a new thread here about each facet of the problem as I see it and what I've had in mind; for lack of a better name, under the heading "ntrace". Thanks, Roland From roland at redhat.com Fri Jun 27 20:50:15 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 27 Jun 2008 20:50:15 -0000 Subject: need quiesce help In-Reply-To: David Smith's message of Wednesday, 11 June 2008 15:49:10 -0500 <48503A46.6080201@redhat.com> References: <484DA5A6.5080403@redhat.com> <48503A46.6080201@redhat.com> Message-ID: <20080627204954.286BC154089@magilla.localdomain> > When you ask for 2 .report_quiesce handlers to be called, you get them > called. Hey, that's the kind of positive feedback about the infrastructure I've been wanting to hear! ;-) From roland at redhat.com Tue Jun 24 21:37:38 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 24 Jun 2008 14:37:38 -0700 (PDT) Subject: compile issues on utrace git tree. In-Reply-To: Srikar Dronamraju's message of Tuesday, 17 June 2008 07:26:53 +0530 <20080617015653.GA31210@linux.vnet.ibm.com> References: <20080617015653.GA31210@linux.vnet.ibm.com> Message-ID: <20080627204953.CDA32154243@magilla.localdomain> Sorry for the delay. I was travelling last week. > When I tried to do a make "allmodconfig" or make "allyesconfig" > from utrace kernel tree cloned from > git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git Sorry, I left the old branches there though they are quite stale now. I've fixed that repo to point its HEAD and master at the current branches. > Also you had sent a mail about the new utrace branch in the > linux-2.6-utrace.git repo. Is it stable enough to start testing and > making changes based on it? Or do we still need to use the master branch > of the same repo. > > If we still need to use the master branch, when can we expect the next update > to this branch? The new code is certainly not stable yet, but it is the only game in town. (That is, it's the only fork I'm going to maintain.) If you are doing pure utrace-based hacking, you can play with the current code if you are adventurous. I expect you will find some problems. The state of the new utrace code is that it has passed some nominal testing (only tried on x86_64) but not really been shaken out much at all yet. There is no integration with ptrace in the code currently in GIT. I'm working on that now. For now, don't use ptrace and utrace on the same thread and you should not have any trouble with ptrace, but if you do, all bets are off. The ptrace integration work I'm doing now is shaking out some bugs in the new utrace code. When that's limping along, I'll put it onto the same GIT branch (the one called "utrace"). There are some known loose ends in the new utrace code that I plan to cover after the basic stuff is stabler. In particular, the picture for single-step and for signal handling is still a bit fuzzy. So don't be surprised to see holes there, but all feedback is welcome. Thanks, Roland From roland at redhat.com Tue Jun 24 21:43:48 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 24 Jun 2008 14:43:48 -0700 (PDT) Subject: Issues when attaching to stopped process In-Reply-To: Matthew Legendre's message of Monday, 9 June 2008 12:23:09 -0500 References: Message-ID: <20080627204953.9422B154241@magilla.localdomain> Sorry for the slow response. This code is going to be substantially different after the utrace revamp currently underway. So I wouldn't spend any more time on the foibles of the current Fedora code. If we can get your case added to the ptrace-tests suite (see http://sourceware.org/systemtap/wiki/utrace/tests) then we'll be sure to check the new kernel code for this regression before it goes into Fedora. It would be great if you could work with jan.kratochvil at redhat.com to get this case into shape and committed to the suite. Thanks, Roland From crisis at apple100.freeserve.co.uk Fri Jun 27 23:46:04 2008 From: crisis at apple100.freeserve.co.uk (Gunter Y Patrica) Date: Sat, 28 Jun 2008 05:46:04 +0600 Subject: MD Database in the US Message-ID: <882382x8ick0$g9780lq0$2655y9r0@Delldim5150 Board Certified MDs in America 788,383 in total <> 17,154 emails Coverage in many different areas of medicine such as Endocrinology, Pathology, Urology, Neurology, Plastic Surgery, Psychiatry, Cardiology and much more 16 different sortable fields reduced price is now: $393 ~~~~~ GET THE 4 ITEMS BELOW AS A GIFT WHEN YOU ORDER ~~~~~ List of US Pharma Companies 47,000 names and emails of the major positions American Hospitals complete contact information for CEO's, CFO's, Directors and more - over 23,000 listings in total for more than 7,000 hospitals in the USA Listing of American Dentists Virtually every dentist in the US with full contact details American Chiropractors Contact List 100k Chiropractors offices with full contact data including email, postal address, phone and fax send and email to: ripdeep.mozelsio_md at hotmail.com exp. mar June 27 and email with 000 in the subject will ensure no further communication from us From quittance at nya.demon.nl Sat Jun 28 17:12:59 2008 From: quittance at nya.demon.nl (Villari Corliss) Date: Sat, 28 Jun 2008 17:12:59 +0000 Subject: ionizations maisonette Message-ID: <5967286724.20080628170015@nya.demon.nl> Hi, *** Warning! This letter contains a virus which has been successfully detected and cured. *** O king, created a fairbrowed daughter by a fiat to select the firm with which he wished to be and make no wager. They went at once into the on an excellent seat, the lord of celestials, follows: 'upon his body being burnt therewith, plague, bring devils. Got some money? Whispered men had put everything they had on earth into i a liver to sit doing sums on my thumbs when. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmoller at redhat.com Mon Jun 30 14:41:37 2008 From: cmoller at redhat.com (Chris Moller) Date: Mon, 30 Jun 2008 10:41:37 -0400 Subject: The demise of utracer. In-Reply-To: <20080627204954.3B75F154050@magilla.localdomain> References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> Message-ID: <4868F0A1.8080407@redhat.com> So now we have four possibles: extending ptrace, a new ptrace-replacement syscall, a systemtap-based thing, and, now, ntrace. Things are diverging rather than converging. A couple of comments concerning the /proc entry fd method utracer uses and than some people have expressed a preference for: The first is that it's clumsy. When the utracer module loads, it creates a /proc pseudo-directory /proc/utrace and then a pseudo-file /proc/utrace/control. When an app wants access to utracer services it opens that control file and ioctl()s [1] a "register" request to it. This causes the module to create another pseudo-directory /proc/utrace/ and two new pseudo-files /proc/utrace//cmd and /proc/utrace//resp. The app then has to open those two pseudo files, using asprintf() or some such to build the file name strings. This strikes me as a ridiculous amount of arm-waving. Further, /proc entries are meant to be publicly accessible ways of accessing kernel data and, to a lesser extent (possibly even including zero--I can't think of an example at the moment), services. utracer violates this implicit paradigm. The utracer entries under /proc/utrace are intended to be exclusively a means of communication between the registering app and the module--I even set the permissions to make sure of that--and might even violate the data vs. services thing. Further, using /proc entries requires that the module keep appropriate structs for each of those entries and to close the entries and clean up the structs when the requesting app de-registers. All cool except when the requesting app either crashes or the app writer just exits without bothering to de-register first--you can build up a lot of dead structs that way. utracer solves this problem by utrace-attaching an engine to every registering app just to get notification of it's unexpected demise and then run around cleaning up after it. All of the foregoing is by way of saying that the /proc entry fd method, even though it looks fairly cool, has it's problems and is fairly inefficient--not even including the unknown (to me, at least) inefficiencies of overhead in the read()/write()/ioctl() mechanism. This isn't to say, however, that the fd (hence select()/poll()/whatever) approach can't be made to work. I haven't even done five minutes of research on it, but it seems possible to me that a ptrace() extension request could be something like fd = ptrace(UTRACE_GET_FD, ...) (or equivalent new utrace syscall request) which returns an fd suitable for use by poll() and select(), and possibly readable, writable, and ioctl-able as well, without having an actual underlying pseudo-file and the attendant overhead and problems described above. [1] Most control operations in utracer are based on ioctl() rather than read() and write(). utracer supports a fair number of requests for information [2] but read() has no way of specifying which information the app is after and write() has no way of retrieving the information. ioctl() is open-ended in that regard and can specify in arbitrary detail not only what information the app wants but provide a pointer to a place to store complex results as well. The down side is that while simple mechanisms are documented by which to register read() and write() methods I couldn't find any documented mechanism by which to register an ioctl() method. I found a way that works: There's a struct associated with top level /proc entries that contains a pointer to another struct that contains a pointer, invariably null so far as I can tell, to an ioctl method. In other than top-level /proc entries, the pointer to the secondary struct is null so I make a copy of the top level struct, stuff in a pointer to my own ioctl() method, then point the original subordinate struct at the modified copy. This is so appallingly clumsy that either I'm very badly missing something or no one has ever needed to ioctl() to a /proc entry before and the mechanism to do so hasn't been developed. The scary part of my hack, of course, is that you never know when someone's going to change something and break it. [2] Information like, e.g. a task's mapped memory regions. This is available just by reading the right pseudo-file in /proc/, but when an app reads that file, the kernel waves its arms a while extracting data from the relevant struct mm_struct and struct vm_area_struct, formatting it into ascii strings, and sending it to the requesting app. The app then has to wave /its/ arms for a while parsing the ascii strings to get back exactly the same information the kernel had in the first place. This rather badly offends my engineer's sense of efficiency, so utracer provides a means of accessing such information directly, in binary, in a struct the app doesn't have to parse. [3] [3] Yes, I know [2] was a subordinate footnote to [1] and considered Bad Form by some. But Gibbon did it, though occasionally if his principal footnote was in Latin, it's subordinate footnote would be in Greek. This scales poorly, limiting the depth of subordinate footnotes to the number of available obscure languages. Accordingly, I'm refraining from doing that. (And, as well, I've no desire to learn Aramaic.) Roland McGrath wrote: > I have numerous more specific thoughts about interface features. Some > time back, I almost got started towards my preferred directions in the > "ntrace" tree, but not quite. I think I have a good sense of all the > "moving parts" going into the interface/fancy-debugger-module picture. > In the next day or two, I'll start a new thread here about each facet of > the problem as I see it and what I've had in mind; for lack of a better > name, under the heading "ntrace". > > > Thanks, > Roland > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From fche at redhat.com Mon Jun 30 15:03:08 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Mon, 30 Jun 2008 11:03:08 -0400 Subject: The demise of utracer. In-Reply-To: <4868F0A1.8080407@redhat.com> (Chris Moller's message of "Mon, 30 Jun 2008 10:41:37 -0400") References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> <4868F0A1.8080407@redhat.com> Message-ID: Chris Moller writes: > [...] > and than some people have expressed a preference for: The first is > that it's clumsy. When the utracer module loads, it creates a /proc > pseudo-directory /proc/utrace and then a pseudo-file > /proc/utrace/control. [...] FWIW, it'd make more sense to me if such a file was per-process (under the /proc/$pid/) hierarchy. > [...] Further, using /proc entries requires that the module keep > appropriate structs for each of those entries and to close the > entries and clean up the structs when the requesting app > de-registers. All cool except when the requesting app either > crashes or the app writer just exits without bothering to > de-register first [...] This really should not be a problem. The kernel tells you when a file descriptor (such as /proc/$$/utrace) gets released, no matter the cause. No cooperation from the userspace clients is needed to unregister, just close() or die. - FChE From cmoller at redhat.com Mon Jun 30 15:21:30 2008 From: cmoller at redhat.com (Chris Moller) Date: Mon, 30 Jun 2008 11:21:30 -0400 Subject: The demise of utracer. In-Reply-To: References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> <4868F0A1.8080407@redhat.com> Message-ID: <4868F9FA.9090805@redhat.com> Frank Ch. Eigler wrote: > Chris Moller writes: > > >> [...] >> and than some people have expressed a preference for: The first is >> that it's clumsy. When the utracer module loads, it creates a /proc >> pseudo-directory /proc/utrace and then a pseudo-file >> /proc/utrace/control. [...] >> > > FWIW, it'd make more sense to me if such a file was per-process > (under the /proc/$pid/) hierarchy. > A single debugger app using utracer could control any number of processes and there could be any number of debugging apps using the utracer module. I needed one known location to which the apps could send register requests. That's why /proc/utrace/control is where it is--no one /proc/ stands out as good top-level directory for the control entry. Also, following my self-imposed "First, be not intrusive." rule, I didn't want to tinker with the existing /proc/ hierarchy. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From fche at redhat.com Mon Jun 30 16:32:24 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Mon, 30 Jun 2008 12:32:24 -0400 Subject: The demise of utracer. In-Reply-To: <4868F9FA.9090805@redhat.com> References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> <4868F0A1.8080407@redhat.com> <4868F9FA.9090805@redhat.com> Message-ID: <20080630163224.GA21660@redhat.com> Hi - On Mon, Jun 30, 2008 at 11:21:30AM -0400, Chris Moller wrote: > [...] > >FWIW, it'd make more sense to me if such a file was per-process > >(under the /proc/$pid/) hierarchy. > > A single debugger app using utracer could control any number of > processes and there could be any number of debugging apps using the > utracer module. [...] It's not a big stretch to ask that such a debugger open N /proc/$$/ctl files. That makes it even more natural should the debugger need to wait for an event on some subset of them: just a single poll()/select() with the file descriptors. In a way, it's nothing more than implicitly passing a task_struct/pid, instead of explicitly in a ioctl structure. (You could go even farther plan-9-ey with representing thread state as manipulable files.) In any case, I'm sure Roland has a big steaming brain dump waiting for us laying out his vision for user-space interfaces to utrace. - FChE From fche at redhat.com Mon Jun 30 17:12:46 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Mon, 30 Jun 2008 13:12:46 -0400 Subject: [Ksummit-2008-discuss] DTrace In-Reply-To: <20080630112913.GA18817@lst.de> References: <20080627150424.GB14894@parisc-linux.org> <1214580213.3394.40.camel@localhost.localdomain> <20080627155018.GC14894@parisc-linux.org> <1214583502.7698.15.camel@weaponx> <20080627163056.GB1416@lst.de> <20080628072605.GA505@in.ibm.com> <20080629084002.GA24131@lst.de> <20080630051034.GA4970@in.ibm.com> <20080630112913.GA18817@lst.de> Message-ID: <20080630171246.GB21660@redhat.com> Hi - On Mon, Jun 30, 2008 at 01:29:13PM +0200, Christoph Hellwig wrote: > [...] This might be getting a little offtopic for the kernel summit > discuss list, but let's start anyway, we can move this to a better > suited list, although I can't think of one except for linux-kernel. systemtap at sources.redhat.com utrace-devel at redhat.com > I'm not sure if that's the current design, but I can't find any > evidence in the code that it allows running handlers in process > context, all that's available is a kernel callback. [...] For systemtap's purposes, that is sufficient. Our probes are meant to run non-intrusively (they do not mess with user thread scheduling, their VM state, strictly limited time & space consumption), so actually injecting equivalent snippets of code into userspace for execution there does not seem to buy anything. Plus, like dtrace, we want scripts to be able to intermix probes (=> share data) amongst kernel and multiple user-space threads, and this seems most naturally done by running the probes themselves in kernel space. > [...] What we really need is a userspace interface so that it > actually can be used by thing like frysk or an implementation of the > userspace dtrace hooks. That will get built as other tools require it. Systemtap per se will likely not. > [...] For complex traces doing this in userspace is for sure a better idea. Can you elaborate upon this more complex scenario? - FChE From listaviral at miproyecto.biz Mon Jun 30 18:59:07 2008 From: listaviral at miproyecto.biz (=?windows-1252?Q?Administraci=F3n_Lista_Viral?=) Date: Mon, 30 Jun 2008 20:59:07 +0200 Subject: =?windows-1252?q?Bolet=EDn_Lista_Viral_-_Miproyecto=2EBiz?= Message-ID: <8edfb108de26f3f7895609d3001adc65@miproyecto.biz> ? 30 de Junio de 2008???????????????????????????????????????????????????????????????????????????????????????????? Bolet?n N?1 ? 1er BOLETIN CONTRUCTOR VIRAL DE LISTAS DE MARKETING Este es nuestro primer bolet?n, cada 15 d?as usted recibir? nuestro bolet?n con todos los avances significativos de nuestro sistema. Tambi?n podr?n observar que en nuestro bolet?n se impresionan los banners de nuestros afiliados Desde la administraci?n queremos dar la bienvenida a todos los nuevos miembros de nuestro Constructor Viral de Listas de Marketing y desearles todo el ?xito del mundo con nuestra excelente herramienta. Llevamos un excelente crecimiento, en una semana y media que estamos online ya somos 327 miembros en el sistema. Miembros Gratis: 224 Miembros PRO: 103 Felicidades a todos por el trabajo de promoci?n de sus listas, espectacular. YA HAY MIEMBROS CON MAS DE 50 MIEMBROS EN SU LISTA, Y ESTO SOLO ES EL COMIENZO!!! El dia 5 se pagar?n a sus cuentas de PayPal las comisiones que hayan ganado este mes. Le recomendamos que actualice sus datos en su back office para que podamos pagarle las comisiones si las ha ganado. ? SOLUCIONADO UN ERROR QUE HABIA EN EL FORMULARIO DE INVITACI?N DEL SISTEMA Este comunicado es para informarles que despues de encontrar un fallo en nuestro formulario de invitaci?n gracias a uno de nuestros afiliados que nos inform? sobre este error ya est? disponible el nuevo formulario mejorado de invitaci?n. Este nuevo formulario est? preparado con un mensaje de invitaci?n con su link de afiliado con lo cual lo ?nico que usted tiene que hacer es introducir sus datos y los datos de las personas a las que desea invitar a formar parte de su lista y listo. Cada vez que usted envia una invitaci?n recibe en su buz?n una copia de cada mensaje que ha sido enviado como verificaci?n de que los mensajes han sido enviados con ?xito con sus invitaciones. Esperamos que sea de su agrado este nuevo formulario. ? Sistema de Banner Le recordamos que tiene disponible una secci?n dentro de su back office para que pueda publicar sus banners, esta herramienta es de gran ayuda para todo aquel que desea una promoci?n m?s intensiva, todos los banners de nuestro sistema son expuestos en nuestra p?gina principal, en los back office de nuestros afiliados, en este bolet?n?y a partir de esta semana vamos a integrar sus banners en todas las paginas que tenemos en la red, obteniendo de esta forma la m?xima exposici?n de sus negocios en Internet. Esperamos que esta tambi?n sea una herramienta perfecta para sus promociones. ? Informaci?n para Miembros PRO Area de descargas PRO ?Ya ha entrado en nuestra secci?n de descargas PRO? Si no es as?, le invitamos a entrar a su ?rea exclusiva de descargas, en esta secci?n tiene disponible productos exclusivos listos para ser descargados por nuestros miembros PRO. Esta secci?n?es actualizada todas las semanas con los mejores productos que encontremos en la red. Muchos de estos productos vienen con sus derechos de reventa para que usted pueda revenderlos ganando el 100% de su valor de venta o los regale como incentivo para obtener suscriptores para su bolet?n o afiliados para su negocio o su lista viral. Productos disponibles a fecha de hoy - Pack de banners Flash. Listos para ser editados. - Los secretos de Google Adsense. (Libro) - PHP Editor. Muy Bueno. - Roboform. Fantastico software para guardar sus contrase?as. - Pack de dise?o para crear sus propias car?tulas para ebook y pack de software. - El ?xito no llega por casualidad. (Libro) - El secreto. la ley de atracci?n. Libro en espa?ol. (Libro) - Marketing Viral. Efecto Bola de Nieve. (Libro) - Como ganar dinero por PayPal. (Libro) - Excelente curso de creaci?n de Paginas Web. En Video. - Como promocionar su negocio por Internet. (Libro) - Software creador de Metatags. (Software) - Easy Book Creator. Creador de Ebook. - StealthBanner. Creador de Banners. - Script Master. Excelente colecci?n de scripts para su Web. - eyeOS. Sistema operativo online. ? RECOMENDACIONES Les recomendamos que promocione a diario su enlace de afiliado para que de esta forma comience el efecto viral a producirse en su lista de Marketing. El efecto viral es fant?stico, su lista crece gracias al trabajo de todo el mundo que tiene en su lista puesto que todos trabajamos en una misma direcci?n. De esta forma usted llegar? con sus promociones a un numero casi ilimitado de personas que realmente est?n interesadas en recibir informaci?n de sus proyectos. Un saludo y mucho ?xito en sus promociones. La Administraci?n. ? __________________________________________________ Trabajamos dia a dia para que nuestra herramienta sea algo realmente excelente y que marque una diferencia entre nuestro sistema y la mayoria de lo que hay en la red. ? Usted recibe este correo por ser suscriptor del Contructor Viral de Listas de Marketing. Nunca podr? ser considerado SPAM. Si usted ha recibido este correo por equivocaci?n simplemente elimine este mensaje y le pedimos disculpas. Copyright 2008 - Constructor Viral de Listas de Marketing?- Todos los derechos reservados -------------- next part -------------- An HTML attachment was scrubbed... URL: