From acro3451 at tss.com.ar Tue Jan 1 15:04:00 2008 From: acro3451 at tss.com.ar (Pls check this new site) Date: Tue, 1 Jan 2008 10:04 -0500 Subject: www.locucionintegral.com.ar Message-ID: <200801011605.m01G56c7014402@mx3.redhat.com> Please see this site in Subject -------------- next part -------------- An HTML attachment was scrubbed... URL: From acro3451 at tss.com.ar Wed Jan 2 07:43:00 2008 From: acro3451 at tss.com.ar (Pls check this new site) Date: Wed, 2 Jan 2008 02:43 -0500 Subject: www.electronicspurchase.com Message-ID: <200801020750.m027oFoJ031953@mx3.redhat.com> Please see this site in Subject -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Wed Jan 2 08:10:56 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 2 Jan 2008 00:10:56 -0800 (PST) Subject: Probably typo In-Reply-To: Wenji Huang's message of Friday, 21 December 2007 17:26:29 +0800 <476B86C5.7070407@oracle.com> References: <476B86C5.7070407@oracle.com> Message-ID: <20080102081056.E00CB26F9A0@magilla.localdomain> Thanks for the report. I have fixed those nits in the 2.6-current, 2.6.23, and 2.6.18 patch sets. However, please note that the arch code in that set (mostly what's in the regset patches) is now more or less dead. The user_regset work now upstream in -mm has replaced this part of the utrace patches. That version of the code already does not have these problems. Thanks, Roland From roland at redhat.com Wed Jan 2 08:20:02 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 2 Jan 2008 00:20:02 -0800 (PST) Subject: Some minor problems in patch - 2 In-Reply-To: Wenji Huang's message of Saturday, 29 December 2007 16:55:41 +0800 <47760B8D.2080000@oracle.com> References: <47760B8D.2080000@oracle.com> Message-ID: <20080102082002.B568B26F9A0@magilla.localdomain> > Found some minor problems in latest utrace patch. Please report distinct issues in separate threads. Please use meaningful subject lines specific to the problem at hand. I'll respond here to the trivial items: > 1. ****** > arch/ia64/ia32/sys_ia32.c I agree with your assessment that there's a typo there. But I will leave that to the ia64 port's maintainers to resolve. > 4. ******* > linux-2.6/include/linux/ptrace.h I fixed the comment typo. > For i386, PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP are defined two times. (Identically, which is kosher.) But it was indeed unintentional. I fixed it. > 6. ******* > linux-2.6/include/asm-avr32/tracehook.h > +#define ARCH_HAS_SINGLE_STEP 1 > > Maybe like others: > > +#define ARCH_HAS_SINGLE_STEP (1) The difference doesn't matter. The file came as it stands from the author of that port. As I do not even compile for that machine, I have not touched it at all. Thanks, Roland From roland at redhat.com Wed Jan 2 08:37:35 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 2 Jan 2008 00:37:35 -0800 (PST) Subject: tracehook interface style In-Reply-To: Wenji Huang's message of Saturday, 29 December 2007 16:55:41 +0800 <47760B8D.2080000@oracle.com> References: <47760B8D.2080000@oracle.com> Message-ID: <20080102083735.1C73426F9A0@magilla.localdomain> > 2. ******* > tracehook_inhibit_wait_stopped, tracehook_inhibit_wait_zombie, tracehook_inhibit_wait_continued have same > parameter and function body. How about to merge them into one? > > 3. ******* > There are some unused parameters in tracehook_report_clone_complete, tracehook_report_vfork_done, tracehook_report_handle_signal. > To keep good interface ? Perhaps I should clarify the intent of the interfaces. Your questions suggest an impression that their purpose is just to meet the immediate needs of the utrace code they call. The rationale behind these interfaces is that the core code (what calls tracehook_*) should not need to change in the future, regardless of many kinds changes in the details of tracing support. Hence, the guiding principle is that the callers supply all the information that is particularly convenient to get at that place, in case it is relevant and helpful to the tracing support. That way, the callers won't be required to adapt to new calling signatures whenever we want to tweak the tracing infrastructure. That information includes which code path in do_wait the call is from, as well as the pointers passed (and now unused) in those calls you mentioned. (Because these are actually inlines, any unused parameters compile away completely. If any core code calling tracehook functions were ever to change so that one of these items were no longer already on hand, then we would change the tracehook signature to keep it a natural and painless call for the core code to make.) Since these things are on hand, and certainly potentially relevant to that tracehook call's topic, they are parameters to the tracehook functions. We can change tracehook.h repeatedly as we work on the tracing support, while never again bothering the maintainers of the core code that makes that tracehook call. Thanks, Roland From shaohua.li at intel.com Wed Jan 2 08:52:27 2008 From: shaohua.li at intel.com (Shaohua Li) Date: Wed, 02 Jan 2008 16:52:27 +0800 Subject: Some minor problems in patch - 2 In-Reply-To: <20080102082002.B568B26F9A0@magilla.localdomain> References: <47760B8D.2080000@oracle.com> <20080102082002.B568B26F9A0@magilla.localdomain> Message-ID: <1199263947.15355.1.camel@sli10-desk.sh.intel.com> On Wed, 2008-01-02 at 16:20 +0800, Roland McGrath wrote: > > Found some minor problems in latest utrace patch. > > Please report distinct issues in separate threads. > Please use meaningful subject lines specific to the problem at hand. > > I'll respond here to the trivial items: > > > 1. ****** > > arch/ia64/ia32/sys_ia32.c > > I agree with your assessment that there's a typo there. > But I will leave that to the ia64 port's maintainers to resolve. Yes, this is correct. Thanks for the finding, please merge. Thanks, Shaohua From wenji.huang at oracle.com Wed Jan 2 09:14:58 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Wed, 02 Jan 2008 17:14:58 +0800 Subject: tracehook interface style In-Reply-To: <20080102083735.1C73426F9A0@magilla.localdomain> References: <47760B8D.2080000@oracle.com> <20080102083735.1C73426F9A0@magilla.localdomain> Message-ID: <477B5612.5030008@oracle.com> An HTML attachment was scrubbed... URL: From ResearchDirector at stocktipnews-info.com Thu Jan 3 19:46:04 2008 From: ResearchDirector at stocktipnews-info.com (Flaherty Special Situation Research) Date: Thu, 3 Jan 2008 13:46:04 -0600 Subject: Bob Flaherty's Favorite Stock for 2008 Message-ID: <200801031946.m03Jk95B011941@mx3.redhat.com> An HTML attachment was scrubbed... URL: From roland at redhat.com Mon Jan 7 07:29:54 2008 From: roland at redhat.com (Roland McGrath) Date: Sun, 6 Jan 2008 23:29:54 -0800 (PST) Subject: [perfmon2] perfmon2 merge news In-Reply-To: Frank Ch. Eigler's message of Saturday, 15 December 2007 10:54:41 -0500 References: <20071119.050843.48408777.davem@davemloft.net> <18242.900.101842.261763@cargo.ozlabs.ibm.com> <20071119224845.GA27766@frankl.hpl.hp.com> <20071119.165313.163834190.davem@davemloft.net> <20071213160004.GC6740@frankl.hpl.hp.com> <20071214210709.GE9577@frankl.hpl.hp.com> Message-ID: <20080107072954.841DD26F9A4@magilla.localdomain> Sorry I didn't respond about this sooner. I trimmed the CC list and added the utrace-devel list, which is the place for picayune details of using the utrace interface. > While I see no single call, it can be synthesized from a sequence of > them: utrace_attach, utrace_set_flags (... UTRACE_ACTION_QUESCE ...), > then waiting for a callback. Roland, is there a more compact way? No, the interface is fundamentally asynchronous, because that's the natural lowest-level expression of the underlying reality. The kernel has a plethora of fancy synchronization mechanisms you can combine with the asynchronous utrace interface. Below is a trivial test module illustrating how you could write the stateless, blocking interfaces Stephane asked for. (This works as is on Fedora kernels with "insmod stop-thread.ko pid=; rmmod stop-thread".) As you can see, it is very simple (the actual utrace-using code is no longer than the test module boilerplate). I don't think stateless calls like these are really what anyone wants to be using. In real cases, you're going to be stopping and starting the same thread many times, not just once. It should be far more efficient and convenient to do utrace_attach once the first time you start dealing with a thread, and just use utrace_set_flags calls to stop and start it several times. You probably have your own data structures for this thread anyway, and you can hold the engine pointer there. If you do, you may also have some synchronization for those data structures already. So your callbacks can use whatever fits your code best, not just complete(). (You just need to do utrace_detach before you abandon your data structure, if that's before the thread gets passed to release_task.) If you are going for efficiency, then you probably actually want a more asynchronous model anyway. You are ping-ponging context switches to wait for it to stop, get notified and wake up, tweak the thread, wake it up, and get back to running. With utrace, you can set up your data structures with what needs to go into the thread and poke it with UTRACE_ACTION_QUIESCE; it runs your callback, which looks at your data structures, updates itself, and then clears QUIESCE, so it goes back to running in its new condition. If your control logic needs to wait for all threads to have done their self-updates, you can have the callback do a count-down to wake you up before it goes back to running. Thanks, Roland --- #include #include #include #include #include MODULE_DESCRIPTION("test module"); MODULE_LICENSE("GPL"); static void stopper_reap(struct utrace_attached_engine *engine, struct task_struct *tsk) { complete_all(engine->data); } static u32 stopper_quiesce(struct utrace_attached_engine *engine, struct task_struct *tsk) { complete(engine->data); // UTRACE_ACTION_NEWSTATE here would make us resume immediately, // having woken our stopper. return UTRACE_ACTION_RESUME; } static const struct utrace_engine_ops stopper_ops = { .report_quiesce = stopper_quiesce, .report_reap = stopper_reap, }; int stop_thread(struct task_struct *t, void **data) { DECLARE_COMPLETION_ONSTACK(done); struct utrace_attached_engine *engine; int ret; engine = utrace_attach(t, UTRACE_ATTACH_CREATE, &stopper_ops, &done); if (IS_ERR(engine)) return PTR_ERR(engine); // if we were already attached before, setting flags like this // with UTRACE_ACTION_QUIESCE set is all it takes to make t stop ret = utrace_set_flags(t, engine, UTRACE_ACTION_QUIESCE | UTRACE_EVENT(QUIESCE) | UTRACE_EVENT(REAP)); if (!ret) ret = wait_for_completion_interruptible(&done); if (ret) (void) utrace_detach(t, engine); else *data = engine; return ret; } void resume_thread(struct task_struct *t, void *data) { // to just resume it but stay attached: //utrace_set_flags(t, data, UTRACE_EVENT(QUIESCE) | UTRACE_EVENT(REAP)); (void) utrace_detach(t, data); } static int target_pid; module_param_named(pid, target_pid, int, 0); static int __init init_test(void) { struct task_struct *t; int ret; void *cookie; rcu_read_lock(); t = find_task_by_pid(target_pid); if (t) get_task_struct(t); rcu_read_unlock(); if (t == NULL) { printk("cannot find PID %d\n", target_pid); return -ESRCH; } ret = stop_thread(t, &cookie); if (ret) printk("failed with %d on PID %d, state %lu\n", ret, target_pid, t->state); else { printk("stopped PID %d, state %lu; letting it go\n", target_pid, t->state); resume_thread(t, cookie); printk("resumed PID %d, state %lu\n", target_pid, t->state); } WARN_ON(atomic_dec_and_test(&t->usage)); return ret; } static void __exit exit_test(void) { } module_init(init_test); module_exit(exit_test); From roland at redhat.com Mon Jan 7 08:56:39 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 7 Jan 2008 00:56:39 -0800 (PST) Subject: user_regset ports, get moving! Message-ID: <20080107085639.099FC26F9A4@magilla.localdomain> Happy New Year, everybody! For the turning of the winter season (and right before vacation), I finished the first stage of the new integration plan in https://www.redhat.com/archives/utrace-devel/2007-November/msg00009.html See the thread starting at http://lkml.org/lkml/2007/12/20/69 (There was also an earlier thread on lkml about arch_has_single_step.) All the generic and x86 code is now in the x86's maintainers' mm tree: git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git branch "mm" This is folded into the -mm patch series, but you can only see the details of the individual patches from the GIT tree (or the mailing list threads). This means the x86 maintainers are happy with it, and I hope this will be going into 2.6.25; noone has complained of it breaking any other arch in -mm. I also did the powerpc work and posted it upstream (same thread), but have gotten no feedback yet. So now it's time to get other arch ports in shape. As I mentioned before, I want to get out of the middle of it ASAP and have someone on this mailing list become the arch advocate for each arch. Now is the time to step forward. Please post here if you are taking the lead in the effort for a particular arch to get user_regset changes accepted by upstream arch maintainers. (I am the arch advocate for x86.) To get started with your arch maintainers, point them to the aforementioned lkml thread (was also on linux-arch). If they already maintain a post-2.6.24 arch tree that goes into -mm, then the x86.git patch in -mm is all the baseline they need. If not, the first several patches in that thread are the generic ones, and only those are required to start working on arch code. (If the changes now in the x86-mm tree get into mainline soon after 2.6.24, then it will be easy for all arch maintainers.) To see an example of what an arch's changes look like, the powerpc patches in that thread are a good reference. For all the machines that had utrace ports done before, you can reuse most of that work (utrace-regset-yourcpu patch primarily). The signatures of the functions and all the names have changed, but it's about the same as the utrace_regset code. Or, it may be a good opportunity to clean up the arch code incrementally in the process and write the new accessors more organically. That's what I did for x86 and powerpc, where there turned out to be very little cut&paste from the utrace-regset patch. Figure out what your arch maintainers want to see. Feel free to CC me on your user_regset patches, but send them to the appropriate upstream arch mailing lists and not to utrace-devel. If you have feedback/questions about the generic user_regset patches I posted on lkml/linux-arch, please follow up there (and to me directly), and not on utrace-devel. The user_regset changes are now independent of utrace, and can stand alone on the kernel scene. I have not done for user_regset an equivalent to ptrace_layout_segment and related helpers, and might not do that same thing at all. For the user_regset work, I would start first with the regset accessors and making CORE_DUMP_USE_REGSET work. If your arch maintainers are liking that ok, then you can move on to cleaning up the ptrace requests incrementally (and/or switching to arch_ptrace and/or compat_arch_ptrace). For most everyone, e.g. GETFPREGS is simple. If your arch has some hairy legacy ptrace layouts that don't lend themselves to cleanup using the user_regset accessors, then talk to me (on lkml) about more helpers that might make it easier on your arch code. As soon as at least the generic and x86 changes have gone into Linus's tree, I will stop maintaining any arch patches in the utrace patch series. Instead, the utrace code will be based on the user_regset code (and arch_has_single_step) and will only compile on an arch where user_regset has been implemented fully. I hope we'll have several other arch ports ready to merge by then too. Thanks, Roland From editora at cerebroecomunicacao.com.br Sun Jan 6 12:06:24 2008 From: editora at cerebroecomunicacao.com.br (Cérebro & Comunicação - Desenvolvimento Pessoal) Date: Sun, 6 Jan 2008 12:06:24 GMT Subject: agenda de cursos atualizada: janeiro / fevereiro 2008. Message-ID: <200801080129.m081Td2k002780@mx3.redhat.com> An HTML attachment was scrubbed... URL: From eranian at googlemail.com Mon Jan 14 06:17:08 2008 From: eranian at googlemail.com (stephane eranian) Date: Mon, 14 Jan 2008 07:17:08 +0100 Subject: [perfmon2] perfmon2 merge news In-Reply-To: <20080107072954.841DD26F9A4@magilla.localdomain> References: <20071119.050843.48408777.davem@davemloft.net> <18242.900.101842.261763@cargo.ozlabs.ibm.com> <20071119224845.GA27766@frankl.hpl.hp.com> <20071119.165313.163834190.davem@davemloft.net> <20071213160004.GC6740@frankl.hpl.hp.com> <20071214210709.GE9577@frankl.hpl.hp.com> <20080107072954.841DD26F9A4@magilla.localdomain> Message-ID: <7c86c4470801132217y4961d26dl4d887ca3d99a8adb@mail.gmail.com> Roland, Thanks for spending some time writing a simple code example. That helps me understand what's involved here. On Jan 7, 2008 8:29 AM, Roland McGrath wrote: > I don't think stateless calls like these are really what anyone wants to > be using. In real cases, you're going to be stopping and starting the > same thread many times, not just once. It should be far more efficient > and convenient to do utrace_attach once the first time you start dealing > with a thread, and just use utrace_set_flags calls to stop and start it > several times. You probably have your own data structures for this It is necessary to block the thread each time the monitoring tool wants to access its PMU state. So, yes the block, modify, unblock sequence would be needed multiple times. You would want to minize the cost of it as much as possible. So if it is possible to do part of the work once and keep it *without* execution overhead, then that would be great. There is indeed a data structure for the PMU state in which I could easily stick a pointer to the utrace data structure. > thread anyway, and you can hold the engine pointer there. If you do, you > may also have some synchronization for those data structures already. So > your callbacks can use whatever fits your code best, not just complete(). > (You just need to do utrace_detach before you abandon your data > structure, if that's before the thread gets passed to release_task.) > > If you are going for efficiency, then you probably actually want a more > asynchronous model anyway. You are ping-ponging context switches to wait > for it to stop, get notified and wake up, tweak the thread, wake it up, I do need something that is synchronous, i.e., when I invoke it the caller remains blocked until the monitored thread is off its CPU. The unblock call can be asynchronous. > and get back to running. With utrace, you can set up your data > structures with what needs to go into the thread and poke it with > UTRACE_ACTION_QUIESCE; it runs your callback, which looks at your data > structures, updates itself, and then clears QUIESCE, so it goes back to > running in its new condition. If your control logic needs to wait for > all threads to have done their self-updates, you can have the callback do > a count-down to wake you up before it goes back to running. > Yes, I would need something like that. Now, in which kernel version can I expect to have the utrace engine? I am willing to try it out. Thanks. From editora at cerebroecomunicacao.com.br Mon Jan 14 06:35:03 2008 From: editora at cerebroecomunicacao.com.br (Cérebro & Comunicação - Desenvolvimento Pessoal) Date: Mon, 14 Jan 2008 06:35:03 GMT Subject: =?iso-8859-1?q?curso_de_Controle_Mental=3A_apostila_+_3_CD=B4s?= =?iso-8859-1?q?=2E?= Message-ID: <200801160744.m0G7iuZT029125@mx3.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: frase_02.gif Type: image/gif Size: 2880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img_logo_chat.gif Type: image/gif Size: 9049 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img_newsletter2.gif Type: image/gif Size: 13753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: yellow.gif Type: image/gif Size: 1292 bytes Desc: not available URL: From peddey at arcpo.com Tue Jan 15 23:53:08 2008 From: peddey at arcpo.com (Violet Banks) Date: Thu, 16 Jan 2008 02:53:08 +0300 Subject: Ring Bible Message-ID: <01c857ea$ec912c80$052cddd5@peddey> It's a system that works http://gexafuhi06555.googlepages.com/index.html From ClaudiaMeier74 at web.de Sat Jan 19 23:13:01 2008 From: ClaudiaMeier74 at web.de (meier claudia) Date: Sun, 20 Jan 2008 00:13:01 +0100 Subject: Hallo nochmal Message-ID: Hallo super kostenloser online TV sender auf http://www.doenertreff.de ausserdem kannst du hier leute aus deiner umgebung kennenlernen http://adultfriendfinder.com/go/g869222-pmo gruss From ananth at in.ibm.com Tue Jan 22 09:37:27 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Tue, 22 Jan 2008 15:07:27 +0530 Subject: incremental arch work In-Reply-To: <20071121042919.738AC26F8BE@magilla.localdomain> References: <1195004137.3856.48.camel@dyn9047018096.beaverton.ibm.com> <20071121023058.0D5C526F8BE@magilla.localdomain> <20071121042919.738AC26F8BE@magilla.localdomain> Message-ID: <20080122093727.GA26608@in.ibm.com> On Tue, Nov 20, 2007 at 08:29:19PM -0800, Roland McGrath wrote: > Here are the steps I have in mind. I think this work should be pretty well > clear to merge upstream without much controversy. Basically, this is the > arch parts now done in the tracehook and regset patches, with a little > sugar. Several of these steps can be done in parallel and merged upstream > independently. ... > Once upstream arch code has merged all the steps above, there will be no > more arch changes--or very nearly none, anyway--required to work with a > later merging of utrace or something else like it. I've thought about > ways to be more incremental about the core changes, too. But if we can > get the ball rolling with the arch changes and get a majority of upstream > arch trees converted over, that will be a first big win. Now that code related to most of the steps you outlined in this thread are scheduled to be pushed upstream (thanks a ton for the work!), from a (!ptrace) utrace client point of view, the two major remaining components would be the tracehooks and the engine infrastructure. We have quite a bit of code in the uprobes codebase that would be of interest to the larger utrace-client community. These include: - Breakpoint assistance (including single-stepping out of line) - Quiescing all threads of a process. >From a utrace-client (and long term maintenance perspective), we'd like to factor these out. (It'd also make the uprobes codebase much leaner). - What'd be your suggestions on that front? Do we just base these off of the current utrace engine infrastructure? - Are the tracehooks and engines the next targets upstream? Possibly 2.6.26? - Do you have any changes in mind from a utrace-client perspective that we need to be cognizant of? Please advise. Ananth From j.blaise71 at yahoo.com Tue Jan 22 15:00:25 2008 From: j.blaise71 at yahoo.com (Joyce Blaise) Date: 22 Jan 2008 07:00:25 -0800 Subject: ASSISTANCE NEEDED URGENTLY. Message-ID: <200801221500.m0MF0U89012333@mx3.redhat.com> You are invited to "ASSISTANCE NEEDED URGENTLY.". By your host Joyce Blaise: Greetings, I am Joyce Blaise the only duaghter of late Mr. and Mrs. James Blaise My Father was a very wealthy cocoa merchant in Abidjan ,the economic capital of Ivory coast, My Father was poisoned to dearth by his business associates so now I am in a problems here in my country right now.Plz i am seeking for your urgent help to transfer US$10.5 millions into your bank account for investment purpose.15% is for your help.Contact me for more details.Email:blaisejoyce0 at mailbox.co.za J Blaise Date: Tuesday January 22, 2008 Time: 2:00 pm - 3:00 pm (GMT +00:00) Location: Reply Me On This ID: blaisejoyce0 at mailbox.co.za Guests: * virtualtraining at redhat.com * phil-list-owner at redhat.com * phil-list at redhat.com * rhn-satellite-users-owner at redhat.com * rhn-satellite-users at redhat.com * valhalla-list-owner at redhat.com * valhalla-list at redhat.com * taroon-list-owner at redhat.com * taroon-list at redhat.com * utrace-devel-owner at redhat.com * utrace-devel at redhat.com * linux-cachefs-owner at redhat.com * linux-cachefs at redhat.com * tux-list-owner at redhat.com * tux-list at redhat.com * video4linux-list-owner at redhat.com * video4linux-list at redhat.com * testing-dev-list-owner at redhat.com * testing-dev-list at redhat.com * xquery-cpp-api-list-owner at redhat.com * xquery-cpp-api-list at redhat.com * fedora-india-owner at redhat.com * zoot-list-owner at redhat.com * zoot-list at redhat.com * libvirt-cim-owner at redhat.com * libvirt-cim at redhat.com * redhat-ccm-list-owner at redhat.com * redhat-ccm-list at redhat.com * testing-commits-list-owner at redhat.com * testing-commits-list at redhat.com * fedora-india at redhat.com * fedora-fonts-bugs-list-owner at redhat.com * fedora-fonts-bugs-list at redhat.com * fedora-list-owner at redhat.com * fedora-i18n-list-owner at redhat.com * fedora-music-list-owner at redhat.com * fedora-i18n-list at redhat.com * fedora-trans-list at redhat.com * fedora-laptop-list-owner at redhat.com * fedora-legacy-list-owner at redhat.com * fedora-package-announce-owner at redhat.com * fedora-ocaml-list-owner at redhat.com * fedora-package-announce at redhat.com * fedora-qa-list-owner at redhat.com * fedora-package-review-owner at redhat.com * fedora-kernel-list-owner at redhat.com * fedora-relnotes-content-owner at redhat.com * fedora-sparc-owner at redhat.com * fedora-perl-devel-list-owner at redhat.com * fedora-trans-hi-owner at redhat.com * fedora-security-list-owner at redhat.com * fedora-triage-list-owner at redhat.com * fedora-trans-list-owner at redhat.com * fedora-trans-ja-owner at redhat.com * fedora-trans-bn_in-owner at redhat.com * fedora-trans-ja at redhat.com * fedora-trans-bg-owner at redhat.com * gov-sec-owner at redhat.com * fedora-advisory-board-owner at redhat.com * fedora-advisory-board at redhat.com * func-list-owner at redhat.com * fedora-trans-ar-owner at redhat.com * guinness-list-owner at redhat.com invitation_add_to_your_yahoo_calendar: http://calendar.yahoo.com/?v=60&ST=20080122T140000%2B0000&TITLE=ASSISTANCE+NEEDED+URGENTLY.&DUR=0100&VIEW=d&DESC=Greetings,%0d%0a%0d%0aI+am+Joyce+Blaise+the+only+duaghter+of+late+Mr.+and+Mrs.+James+Blaise+My+Father+was+a+very+wealthy+cocoa+merchant+in+Abidjan+,the+economic+capital+of+Ivory+coast,+My+Father+was+poisoned+to+dearth+by+his+business+associates+so+now+I+am+in+a+problems+here+in+my+country+right+now.Plz+i+am+seeking+for+your+urgent+help+to+transfer+US$10.5+millions+into+your+bank+account+for+investment+purpose.15%25+is+for+your+help.Contact+me+for+more+details.Email%3ablaisejoyce0 at mailbox.co.za%0d%0a%0d%0aJ+Blaise&in_loc=Reply+Me+On+This+ID%3a+blaisejoyce0 at mailbox.co.za&TYPE=10 Copyright ? 2008 All Rights Reserved www.yahoo.com Privacy Policy: http://privacy.yahoo.com/privacy/us Terms of Service: http://docs.yahoo.com/info/terms/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Wed Jan 23 02:30:41 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 22 Jan 2008 18:30:41 -0800 (PST) Subject: incremental arch work In-Reply-To: Ananth N Mavinakayanahalli's message of Tuesday, 22 January 2008 15:07:27 +0530 <20080122093727.GA26608@in.ibm.com> References: <1195004137.3856.48.camel@dyn9047018096.beaverton.ibm.com> <20071121023058.0D5C526F8BE@magilla.localdomain> <20071121042919.738AC26F8BE@magilla.localdomain> <20080122093727.GA26608@in.ibm.com> Message-ID: <20080123023041.1D27326FA0A@magilla.localdomain> > Now that code related to most of the steps you outlined in this thread are > scheduled to be pushed upstream (thanks a ton for the work!), from a As yet this is only entirely true for x86. While I have also done and posted the work for powerpc, it still needs an advocate to secure the upstream powerpc maintainers' commitment to fold it in. (And more testing, and probably to unbreak kexec.) For all other machines, including the ones for which utrace support was implemented before, the new form of porting work (user_regset) remains to be done. > - Breakpoint assistance (including single-stepping out of line) I have written before in some detail about how I think this would ideally be factored out. That is just about entirely orthogonal to the utrace interface. (There's no reason it couldn't have been done already.) > - Quiescing all threads of a process. I am skeptical that this alone will be something to factor out in a useful way as an isolated facility. (That's not to say there is anything to stop someone taking a whack at it. Experimentation is good.) I've discussed the subject before. We can get into it later, when someone is actually doing something about it. > - What'd be your suggestions on that front? Do we just base these off of > the current utrace engine infrastructure? The work of making the instruction-copying facility into nice modular pieces is not going to be affected very much by the utrace interface details even if they were to change a lot. I do not anticipate any really drastic changes to the character of the utrace interface. If you write to what we have today, I don't think there will ever be a great deal of work involved in adjusting to however it comes out in the end. > - Are the tracehooks and engines the next targets upstream? Possibly > 2.6.26? I don't want to speculate about when patches might be accepted upstream before I even have them composed. We are indeed just about to the next major phase now. We will really be there when user_regset patches go into Linus's tree, which we expect in the 2.6.25 merge window after 2.6.24 goes out. This next phase is, frankly, not yet planned out in much detail. The overall plan is to be very incremental, giving upstream small chunks that are easy to digest. This will require slower work than simply forward-porting the utrace patch set after the user_regset integration. At every point, new changes will not break existing functionality. New code will be enabled only by new config options. Each arch must continue to work unchanged using the old default config options, though it will only be possible to build using new options on an arch that has done the user_regset work. I think what this will mean for me initially is to focus on some cleanup work in the upstream core ptrace and signals code. This is tangential to integrating utrace per se, but it is the right thing for upstream to get some incremental improvements. Then I will start incrementally teasing out the ptrace tendrils into all corners of the kernel, consolidating them in places like tracehook.h and ptrace.h with coherent entry points (the same sorts of things that are in utrace-tracehook.patch, but we'll see exactly how it comes out). Unlike what utrace-tracehook.patch does, this work will leave the old ptrace implementation machinery intact, though some of it moved around and wrapped in more inlines. I don't think that much will be especially controversial. At that point any new thing can be done touching the rest of the kernel as little as utrace-core.patch does. That at the very least makes it much easier to maintain an experimental patch set relative to the upstream tree. > - Do you have any changes in mind from a utrace-client perspective that > we need to be cognizant of? The only things akin to specific plans I have in mind are those I've discussed before and that are already on the TODO list. In particular, the "engine interaction issues" area comes to mind. (See https://www.redhat.com/archives/utrace-devel/2007-August/msg00024.html and https://www.redhat.com/archives/utrace-devel/2007-September/msg00001.html for detailed background.) This is something we are already pretty sure we need to revamp, so hashing that out before preparing something for submission seems like a good idea. Working on a well-heeled breakpoint facility that manages in the presence of other engines both to work right and not to confuse the other engines would is a fine way to pin down the concrete details of those interface changes. It's altogether possible that many other things will change in the course of ironing out the code upstream. Off hand the kind of changes that seem most likely aside from cosmetic things are in the handling of allocation and data structure lifetimes. Those are important things, but usually not big parts of how the client code is organized to use the interface. I don't think you need to worry about them ahead of time. To be honest, I think strong development of things exploiting utrace heavily will have more effect on how the interface mutates to get merged upstream than vice versa. Proving the utility and need for certain interface details concretely by using them enough to care about the subtleties gets more traction (and hones better interfaces) than any amount of pontification I might muster. Thanks, Roland From BancoPosta at poste.it Wed Jan 23 13:03:17 2008 From: BancoPosta at poste.it (BancoPosta at poste.it) Date: Wed, 23 Jan 2008 08:03:17 -0500 Subject: Poste errore di cliente - aggiornamento richiesto Message-ID: An HTML attachment was scrubbed... URL: From adobriyan at sw.ru Wed Jan 23 14:48:38 2008 From: adobriyan at sw.ru (Alexey Dobriyan) Date: Wed, 23 Jan 2008 17:48:38 +0300 Subject: Bunch of utrace crashes Message-ID: <20080123144837.GB6044@localhost.sw.ru> Hi, Roland. utrace patch against 2.6.24-rc8 kernel reasonably quickly oopses in the following way: BUG: unable to handle kernel paging request at virtual address f54ffa34 printing eip: c10492cc *pdpt = 0000000000003001 *pde = 0000000001747067 *pte = 00000000354ff000 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC Modules linked in: af_packet nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state nf_conntrack ipt_REJECT iptable_filter ip_tables xt_tcpudp ip6t_REJECT ip6table_filter ip6_tables x_tables cpufreq_ondemand loop sr_mod k8temp cdrom hwmon Pid: 23705, comm: expl_ptratt Not tainted (2.6.24-rc8-utrace #4) EIP: 0060:[] EFLAGS: 00210282 CPU: 0 EIP is at get_utrace_lock_attached+0x3c/0xb0 EAX: f5ea5590 EBX: f6836c88 ECX: f5ea5590 EDX: 00000002 ESI: f54ff590 EDI: f54ff590 EBP: f5e41830 ESP: f73cde10 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process expl_ptratt (pid: 23705, ti=f73cd000 task=f5ea5590 task.ti=f73cd000) Stack: 00000002 00000001 c1049290 f6836c88 f5e41830 f54ff590 f5ea5fc0 c104a41b f6836c88 f5ea5590 f5ea5fc0 f5ea5fc0 c104d7c2 00000002 00000001 c104d762 00000000 00000000 f6836ca0 f60ace58 00000009 f5ea5590 f73cdf10 c102107a Call Trace: [] get_utrace_lock_attached+0x0/0xb0 [] utrace_detach+0x1b/0xc0 [] ptrace_exit+0xb2/0x1b0 [] ptrace_exit+0x52/0x1b0 [] do_exit+0x8a/0x760 [] _spin_unlock_irq+0x20/0x30 [] do_group_exit+0x26/0x70 [] get_signal_to_deliver+0x1f0/0x3e0 [] do_notify_resume+0x93/0x760 [] _spin_unlock_irq+0x20/0x30 [] finish_task_switch+0x5c/0xc0 [] finish_task_switch+0x0/0xc0 [] schedule+0x1f9/0x680 [] _spin_unlock_irq+0x22/0x30 [] sys_ptrace+0x676/0x750 [] work_notifysig+0x13/0x1b [] __kfree_skb+0x8/0x80 ======================= Code: b8 00 6d 2c c1 31 d2 89 5c 24 0c 89 7c 24 14 c7 44 24 08 90 92 04 c1 c7 44 24 04 01 00 00 00 c7 04 24 02 00 00 00 e8 14 51 ff ff <8b> 9e a4 04 00 00 85 db 74 51 83 be 88 00 00 00 20 74 48 8d 7b EIP: [] get_utrace_lock_attached+0x3c/0xb0 SS:ESP 0068:f73cde10 What happens is dangling tsk passed into get_utrace_lock_attached() -- "8b 9e a4 04 00 00" is "mov 0x4a4(%esi),%ebx" which corresponds to ->utrace offset inside task_struct here. Sorry, haven't looked further. Another bug which I _think_, can be triggered is "BUG_ON(tsk->utrace == utrace);" in check_dead_utrace -- it can happen if utrace_clear_tsk() skipped clearing ->utrace pointer in otherwise normal detaching sequence. This can happen, due to utrace->u.live.signal being valid pointer at that time. Now this can happen when execution of resumed task starts: do_notify_resume get_signal_to_deliver tracehook_get_signal utrace_get_signal [utrace pointer found, utrace->lock taken] utrace_quiescent [signal is valid here, put onto live struct utrace without locking] So, ->utrace clearance skipped wake_quiescent check_dead_utrace BUG_ON(tsk->utrace == utrace); I can't reproduce this on -rc8 at will, but I don't see anything that prevents above race as well. Probably window for #1 far wider :-( From adobriyan at sw.ru Wed Jan 23 14:51:49 2008 From: adobriyan at sw.ru (Alexey Dobriyan) Date: Wed, 23 Jan 2008 17:51:49 +0300 Subject: Bunch of utrace crashes In-Reply-To: <20080123144837.GB6044@localhost.sw.ru> References: <20080123144837.GB6044@localhost.sw.ru> Message-ID: <20080123145149.GC6044@localhost.sw.ru> > do_notify_resume > get_signal_to_deliver > tracehook_get_signal > utrace_get_signal > [utrace pointer found, utrace->lock taken] "not taken", of course. > utrace_quiescent From jkenisto at us.ibm.com Thu Jan 24 00:21:53 2008 From: jkenisto at us.ibm.com (Jim Keniston) Date: Wed, 23 Jan 2008 16:21:53 -0800 Subject: Fwd: uprobed multithreaded app serializes in signal-handling code Message-ID: <1201134113.3875.25.camel@dyn9047018096.beaverton.ibm.com> To be notified of breakpoint and single-step traps, uprobes currently uses a utrace report_signal callback. Per the data below, maybe we need to intercept the trap before it turns into a signal -- preferably via a new utrace event callback. I think this is already on Roland's TODO list (and discussed on a July 23, 2007 conference call). Anyway, here's some motivation. Jim Keniston -------- Forwarded Message -------- From: jkenisto at us dot ibm dot com Reply-To: sourceware-bugzilla at sourceware.org To: systemtap at sources.redhat.com Subject: [Bug uprobes/5660] New: uprobed multithreaded app serializes in signal-handling code Date: 23 Jan 2008 00:49:07 -0000 Uprobing a multithreaded app on an x86_64 SMP system shows serious serialization of the threads in the kernel's signal-handling code. In the app in question, the child threads just call a dummy function repeatedly; the uprobes module probes the dummy function's entry point. Here's a summary of data reported by oprofile. It shows that with more than one thread running, utrace_get_signal(), get_signal_to_deliver(), and force_sig_info() are the top three consumers of CPU time. I'm guessing that the threads are serializing on task_struct->sighand->siglock (which is shared among tasks of the same process). #CPUs: 4 pct (rank) pct (rank) pct (rank) threads usec/iter** utrace_get_signal get_signal_to_deliver force_sig_info 1* 4.4 12.2% (1) 2.4% (13) < 1% 1 4.0 12.0% (1) 3.5% (7) < 1% 2 9.2 21.4% (1) 13.2% (2) 5.7% (3) 3 19.0 30.9% (1) 24.4% (2) 13.5% (3) 4 29.7 36.7% (1) 25.6% (2) 14.4% (3) *single-thread program -- no parent thread ** Divide by #threads to get usec per probe hit. Percentages are of total kernel+user time. I have no particular reason to think that this problem is specific to x86_64. I've observed poor scaling on multithreaded apps before, but never got around to pointing oprofile at it. I was hoping it was something we could fix in uprobes. :-| From roland at redhat.com Thu Jan 24 03:51:24 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Jan 2008 19:51:24 -0800 (PST) Subject: Fwd: uprobed multithreaded app serializes in signal-handling code In-Reply-To: Jim Keniston's message of Wednesday, 23 January 2008 16:21:53 -0800 <1201134113.3875.25.camel@dyn9047018096.beaverton.ibm.com> References: <1201134113.3875.25.camel@dyn9047018096.beaverton.ibm.com> Message-ID: <20080124035124.98CA726F9FD@magilla.localdomain> That's an entirely different sort of motivation than any of the ones I've had. :-) In fact, I might not necessarily have avoided siglock synchronization in the utrace "extension event" facility I've described for future work, if this had not come to my attention. So that is good to consider. It might be worthwhile to pin down more definitively how things are working in your case. I don't think we can be sure right away what its primary issue is. It is not just the use of a SIGTRAP signal for a machine event that's the issue if siglock serialization is the problem. The main means of getting some notification work done at a safe place is setting TIF_SIGPENDING so that we'll get into utrace_get_signal. Since that flag is overloaded for "check the signal queues" as well as "check in with utrace", setting it now means that the thread will always be obligated to take and release the siglock at least once before it can return to user mode. So e.g. threads responding to a request to become quiescent, even when report_quiesce clears the action flag and they never need to sleep, all hit the siglock bottleneck. Untying from TIF_SIGPENDING is something I expect eventually to fall out of the development path. (It relates to the "soft-quiesce" feature.) But I'd expected that probably after the extension events. Anyway, more to think about. Thanks, Roland From ClaudiaMeier74 at web.de Thu Jan 24 04:06:16 2008 From: ClaudiaMeier74 at web.de (meier claudia) Date: Thu, 24 Jan 2008 05:06:16 +0100 Subject: ich nochmal Message-ID: Hallo nochmal also der neue online TV Sender ist auf http://www.doenertreff.de echt super .. mario barth michael mittermeier.. usw und hammer musik die single seite wo ich gesagt habe ist auf http://adultfriendfinder.com/go/g869222-pmo oder auf http://adultfriendfinder.com/go/p409433 einfach mal anmelden ach ja funny Bilder gibt es auf http://www.doenertreff.de/doenertreff/Babys.htm oder http://www.doenertreff.de/doenertreff/Tiere.htm oder optische t?uschungen http://www.doenertreff.de/doenertreff/Tauschungen.htm einfach mal anschauen..... gru? PS: gr?? alle von mir, ach ja und werbebanner f?r deine Homepage, mit denen du Geld Verdienen kannst, und die auch wirklich ausbezahlen, oder wenn Du ?ber 1000 Besucher in der Stunde willst!! das alles findest du auf http://www.doenertreff.de/besuchertausch echt gut!!!!! From sachinp at in.ibm.com Thu Jan 24 08:33:31 2008 From: sachinp at in.ibm.com (Sachin P. Sant) Date: Thu, 24 Jan 2008 14:03:31 +0530 Subject: Fw: Re: incremental arch work] Message-ID: <47984D5B.6010505@in.ibm.com> Hi Roland, Ananth forwarded me this mail as it has some mention of kexec. In this posting you mentioned that the recent regset changes you are planning might break kexec. Could you elaborate on this ? Also will these changes break kexec only on powerpc or other arch also ? Thanks -Sachin ----- Forwarded message from Roland McGrath ----- From: Roland McGrath To: ananth at in.ibm.com Cc: utrace-devel Subject: Re: incremental arch work Date: Tue, 22 Jan 2008 18:30:41 -0800 (PST) > Now that code related to most of the steps you outlined in this thread are > scheduled to be pushed upstream (thanks a ton for the work!), from a As yet this is only entirely true for x86. While I have also done and posted the work for powerpc, it still needs an advocate to secure the upstream powerpc maintainers' commitment to fold it in. (And more testing, and probably to unbreak kexec.) For all other machines, including the ones for which utrace support was implemented before, the new form of porting work (user_regset) remains to be done. > - Breakpoint assistance (including single-stepping out of line) I have written before in some detail about how I think this would ideally be factored out. That is just about entirely orthogonal to the utrace interface. (There's no reason it couldn't have been done already.) > - Quiescing all threads of a process. I am skeptical that this alone will be something to factor out in a useful way as an isolated facility. (That's not to say there is anything to stop someone taking a whack at it. Experimentation is good.) I've discussed the subject before. We can get into it later, when someone is actually doing something about it. > - What'd be your suggestions on that front? Do we just base these off of > the current utrace engine infrastructure? The work of making the instruction-copying facility into nice modular pieces is not going to be affected very much by the utrace interface details even if they were to change a lot. I do not anticipate any really drastic changes to the character of the utrace interface. If you write to what we have today, I don't think there will ever be a great deal of work involved in adjusting to however it comes out in the end. > - Are the tracehooks and engines the next targets upstream? Possibly > 2.6.26? I don't want to speculate about when patches might be accepted upstream before I even have them composed. We are indeed just about to the next major phase now. We will really be there when user_regset patches go into Linus's tree, which we expect in the 2.6.25 merge window after 2.6.24 goes out. This next phase is, frankly, not yet planned out in much detail. The overall plan is to be very incremental, giving upstream small chunks that are easy to digest. This will require slower work than simply forward-porting the utrace patch set after the user_regset integration. At every point, new changes will not break existing functionality. New code will be enabled only by new config options. Each arch must continue to work unchanged using the old default config options, though it will only be possible to build using new options on an arch that has done the user_regset work. I think what this will mean for me initially is to focus on some cleanup work in the upstream core ptrace and signals code. This is tangential to integrating utrace per se, but it is the right thing for upstream to get some incremental improvements. Then I will start incrementally teasing out the ptrace tendrils into all corners of the kernel, consolidating them in places like tracehook.h and ptrace.h with coherent entry points (the same sorts of things that are in utrace-tracehook.patch, but we'll see exactly how it comes out). Unlike what utrace-tracehook.patch does, this work will leave the old ptrace implementation machinery intact, though some of it moved around and wrapped in more inlines. I don't think that much will be especially controversial. At that point any new thing can be done touching the rest of the kernel as little as utrace-core.patch does. That at the very least makes it much easier to maintain an experimental patch set relative to the upstream tree. > - Do you have any changes in mind from a utrace-client perspective that > we need to be cognizant of? The only things akin to specific plans I have in mind are those I've discussed before and that are already on the TODO list. In particular, the "engine interaction issues" area comes to mind. (See https://www.redhat.com/archives/utrace-devel/2007-August/msg00024.html and https://www.redhat.com/archives/utrace-devel/2007-September/msg00001.html for detailed background.) This is something we are already pretty sure we need to revamp, so hashing that out before preparing something for submission seems like a good idea. Working on a well-heeled breakpoint facility that manages in the presence of other engines both to work right and not to confuse the other engines would is a fine way to pin down the concrete details of those interface changes. It's altogether possible that many other things will change in the course of ironing out the code upstream. Off hand the kind of changes that seem most likely aside from cosmetic things are in the handling of allocation and data structure lifetimes. Those are important things, but usually not big parts of how the client code is organized to use the interface. I don't think you need to worry about them ahead of time. To be honest, I think strong development of things exploiting utrace heavily will have more effect on how the interface mutates to get merged upstream than vice versa. Proving the utility and need for certain interface details concretely by using them enough to care about the subtleties gets more traction (and hones better interfaces) than any amount of pontification I might muster. Thanks, Roland ----- End forwarded message ----- From roland at redhat.com Thu Jan 24 08:46:03 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jan 2008 00:46:03 -0800 (PST) Subject: Bunch of utrace crashes In-Reply-To: Alexey Dobriyan's message of Wednesday, 23 January 2008 17:48:38 +0300 <20080123144837.GB6044@localhost.sw.ru> References: <20080123144837.GB6044@localhost.sw.ru> Message-ID: <20080124084603.AADD026F9FD@magilla.localdomain> Thanks very much for the report, Alexey. I've trimmed the CC since I don't think the wider kernel community is interested in the internal bugs of a patch that for now is not even submitted for inclusion (and I dislike cross-posting as a rule). > utrace patch against 2.6.24-rc8 kernel reasonably quickly oopses in the > following way: These cases seem to vary widely among configs and machines. The last time I tried, I did not have much luck getting any of the crashes to happen often enough to be able to do much investigation. > Call Trace: > [] get_utrace_lock_attached+0x0/0xb0 > [] utrace_detach+0x1b/0xc0 > [] ptrace_exit+0xb2/0x1b0 > [] ptrace_exit+0x52/0x1b0 > [] do_exit+0x8a/0x760 [...] > What happens is dangling tsk passed into get_utrace_lock_attached() -- > "8b 9e a4 04 00 00" is "mov 0x4a4(%esi),%ebx" which corresponds to > ->utrace offset inside task_struct here. Sorry, haven't looked further. Here's the theory on what's supposed to prevent this one. (Maybe you can see the holes.) ptrace_exit is in rcu_read_lock, doing: list_for_each_safe_rcu(pos, n, &tsk->ptracees) { state = list_entry(pos, struct ptrace_state, entry); error = utrace_detach(state->task, state->engine); RCU should be keeping all task_struct's alive that were alive when we started looking at the list. The other side of the race is release_task, which depending on the test case is called by the task itself, or by another one calling wait. release_task should lead to ptrace_report_reap. If this is true, both state and state->task should be kept valid by RCU. Actually it might instead get to ptrace_report_death and detach itself, or get ptrace_detach'd via detach_zombie, in which case 'state' is already stale. If this is true, then perhaps state->task was already passed to release_task before the rcu_read_lock in ptrace_exit. Do you think that logic is sound? If this latter scenario is what you are hitting, then perhaps it would be fixed by the patch below. But I'm not very confident I really know what's going on in your crash. Thanks, Roland diff --git a/kernel/ptrace.c b/kernel/ptrace.c index b22c1d0..0000000 100644 --- a/kernel/ptrace.c +++ b/kernel/ptrace.c @@ -157,6 +157,14 @@ ptrace_done(struct ptrace_state *state) CHECK_DEAD(state); BUG_ON(state->rcu.func); BUG_ON(state->rcu.next); + /* + * We clear @task here, while we are sure that the task_struct is + * still live, because our caller has to permit its release. + * By RCU rules, this means that inside rcu_read_lock(), + * rcu_dereference(state->task) will always produce either + * a pointer that is being kept alive by RCU, or NULL. + */ + rcu_assign_pointer(state->task, NULL); call_rcu(&state->rcu, ptrace_state_free); } @@ -503,6 +511,7 @@ ptrace_exit(struct task_struct *tsk) do { struct ptrace_state *state; + struct task_struct *p; int error; START_CHECK; @@ -512,7 +521,17 @@ ptrace_exit(struct task_struct *tsk) restart = 0; list_for_each_safe_rcu(pos, n, &tsk->ptracees) { state = list_entry(pos, struct ptrace_state, entry); - error = utrace_detach(state->task, state->engine); + /* + * Here rcu_read_lock() keeps live any task_struct + * that state->task still points to. If state->task + * was cleared already, then state itself is on the + * way to be freed by RCU and we are just seeing a + * stale list element here. + */ + p = rcu_dereference(state->task); + if (unlikely(p == NULL)) + continue; + error = utrace_detach(p, state->engine); BUG_ON(state->parent != tsk); if (likely(error == 0)) { ptrace_state_unlink(state); @@ -525,7 +544,6 @@ ptrace_exit(struct task_struct *tsk) * Since wait_task_inactive might yield, * we must go out of rcu_read_lock and restart. */ - struct task_struct *p = state->task; get_task_struct(p); rcu_read_unlock(); wait_task_inactive(p); @@ -1237,7 +1255,9 @@ ptrace_do_wait(struct task_struct *tsk, rcu_read_lock(); ns = current->nsproxy->pid_ns; list_for_each_entry_rcu(state, &tsk->ptracees, entry) { - p = state->task; + p = rcu_dereference(state->task); + if (unlikely(p == NULL)) + continue; if (pid > 0) { if (task_pid_nr_ns(p, ns) != pid) From roland at redhat.com Thu Jan 24 09:42:33 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jan 2008 01:42:33 -0800 (PST) Subject: Bunch of utrace crashes In-Reply-To: Alexey Dobriyan's message of Wednesday, 23 January 2008 17:51:49 +0300 <20080123145149.GC6044@localhost.sw.ru> References: <20080123144837.GB6044@localhost.sw.ru> <20080123145149.GC6044@localhost.sw.ru> Message-ID: <20080124094233.0C32526F9FD@magilla.localdomain> > Another bug which I _think_, can be triggered is "BUG_ON(tsk->utrace == utrace);" This one has indeed been happening. I've seen it, but still haven't reproduced it sufficiently repeatably to be able to work on it. > in check_dead_utrace -- it can happen if utrace_clear_tsk() skipped > clearing ->utrace pointer in otherwise normal detaching sequence. This > can happen, due to utrace->u.live.signal being valid pointer at that time. > Now this can happen when execution of resumed task starts: > > do_notify_resume > get_signal_to_deliver > tracehook_get_signal > utrace_get_signal > [utrace pointer found, utrace->lock taken] [> "not taken", of course.] > utrace_quiescent > [signal is valid here, put onto live struct utrace without > locking] > > So, ->utrace clearance skipped > wake_quiescent > check_dead_utrace > BUG_ON(tsk->utrace == utrace); > > I can't reproduce this on -rc8 at will, but I don't see anything that > prevents above race as well. Probably window for #1 far wider :-( Again let me conjure the theory on what's supposed to prevent this one, and maybe you will see the holes in the logic (or maybe I will). utrace_detach holds the utrace lock. To be in the remove_engine and wake_quiescent path, quiesce returned 1, meaning it was in TASK_TRACED. After that remove_engine called utrace_clear_tsk, and u.live.signal was set then. The theory is that when check_dead_utrace checks u.live.signal it will match what utrace_clear_tsk saw. When it sees something there, it doesn't take the path to rcu_utrace_free. The BUG_ON hits because the theory does not hold. Since we hold the lock, the only thing waking the target up before us is SIGKILL. When that happens, utrace_quiescent will clear u.live.signal asynchronously without regard to utrace->lock. If this happens after utrace_clear_tsk and before check_dead_utrace, then we hit the anomaly. Do you think that logic is sound? The original theory was based on the expectation that nothing else de-quiesces the target while we hold the lock. I think that's still sound with the exception of SIGKILL. Do you think that is valid otherwise? If this logic does explain the problem, then perhaps it is fixed by the patch below. The comment gives the rationale for why it should cover the SIGKILL scenario. What do you think? Thanks, Roland --- a/kernel/utrace.c +++ b/kernel/utrace.c @@ -1423,6 +1423,23 @@ restart: */ BUG_ON(tsk->utrace != utrace); BUG_ON(utrace->u.live.signal != signal); + if (unlikely(killed)) { + /* + * Synchronize with any utrace_detach that + * might be in progress. It expected us to + * stay quiescent, but SIGKILL broke that. + * Taking this lock here serializes its + * work so that if it had the lock and + * thought we were still in TASK_TRACED, we + * block until it has finished looking at + * utrace. A utrace_detach that gets the + * lock after we release it here will not + * think we are quiescent at all, since we + * are in TASK_RUNNING state now. + */ + spin_lock(&utrace->lock); + spin_unlock(&utrace->lock); + } utrace->u.live.signal = NULL; } From roland at redhat.com Thu Jan 24 09:58:51 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jan 2008 01:58:51 -0800 (PST) Subject: Fw: Re: incremental arch work] In-Reply-To: Sachin P. Sant's message of Thursday, 24 January 2008 14:03:31 +0530 <47984D5B.6010505@in.ibm.com> References: <47984D5B.6010505@in.ibm.com> Message-ID: <20080124095851.9DAA626F9FD@magilla.localdomain> > Ananth forwarded me this mail as it has some mention of kexec. > In this posting you mentioned that the recent regset changes > you are planning might break kexec. > > Could you elaborate on this ? Also will these changes break > kexec only on powerpc or other arch also ? Please see http://lkml.org/lkml/2008/1/18/583 No arch's kexec is affected unless it has removed its ELF_CORE_COPY_REGS macro. My x86 changes in the x86/mm tree did that, but it's now been added back to unbreak kexec. The powerpc patches I posted also remove the macro, but those patches haven't been incorporated anywhere yet anyway; it's simple just not to remove the macro (it's part of patch 10/16 in the powerpc patch series; patch 10 does nothing but remove old code, all of which but this is truly unused). As I mentioned in that lkml message, I think it would be better for kexec to clean up its arch interfaces not to use elf_core_copy_regs at all. There is already machine-specific kexec code that goes through contortions with register values, so it might as well be consolidated into a single set of contortions that produces the final data format (i.e. elf_gregset_t). But there is no big rush to resolve that. The machine-specific macro ELF_CORE_COPY_REGS no longer has any use for core files and it's unsightly to keep it around with that name, but that's all. kexec will not be broken by the user_regset changes when they are merged. If kexec cleaned up, that and user_regset support together would permit each arch to drop the ELF_CORE_COPY_REGS macro and cut down the clutter. Thanks, Roland From roland at redhat.com Thu Jan 24 10:13:54 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jan 2008 02:13:54 -0800 (PST) Subject: [perfmon2] perfmon2 merge news In-Reply-To: stephane eranian's message of Monday, 14 January 2008 07:17:08 +0100 <7c86c4470801132217y4961d26dl4d887ca3d99a8adb@mail.gmail.com> References: <20071119.050843.48408777.davem@davemloft.net> <18242.900.101842.261763@cargo.ozlabs.ibm.com> <20071119224845.GA27766@frankl.hpl.hp.com> <20071119.165313.163834190.davem@davemloft.net> <20071213160004.GC6740@frankl.hpl.hp.com> <20071214210709.GE9577@frankl.hpl.hp.com> <20080107072954.841DD26F9A4@magilla.localdomain> <7c86c4470801132217y4961d26dl4d887ca3d99a8adb@mail.gmail.com> Message-ID: <20080124101354.C69EC26F9FD@magilla.localdomain> > It is necessary to block the thread each time the monitoring tool wants > to access its PMU state. So, yes the block, modify, unblock sequence > would be needed multiple times. You would want to minize the cost of > it as much as possible. So if it is possible to do part of the work once > and keep it *without* execution overhead, then that would be great. > There is indeed a data structure for the PMU state in which I could > easily stick a pointer to the utrace data structure. Having an engine attached with no event reports currently requested should add no overhead at all to the thread's normal execution. In fact, as long as you haven't lately done utrace_set_flags to request something, it should change no code path at all until the task gets passed to release_task. > Now, in which kernel version can I expect to have the utrace engine? > I am willing to try it out. It is available today in Fedora kernels, RHEL5 kernels, and in patches you can build yourself against upstream 2.6.23 or trunk that support several architectures (see http://redhat.com/~roland/utrace/). As to inclusion in an upstream kernel version, that is an ongoing story and you can read other threads on this mailing list about that. (In what upstream kernel version can I expect to have perfmon2, my good man? ;-) Thanks, Roland From sachinp at in.ibm.com Fri Jan 25 11:17:41 2008 From: sachinp at in.ibm.com (Sachin P. Sant) Date: Fri, 25 Jan 2008 16:47:41 +0530 Subject: Fw: Re: incremental arch work] In-Reply-To: <20080124095851.9DAA626F9FD@magilla.localdomain> References: <47984D5B.6010505@in.ibm.com> <20080124095851.9DAA626F9FD@magilla.localdomain> Message-ID: <4799C555.7030704@in.ibm.com> Roland McGrath wrote: >> Ananth forwarded me this mail as it has some mention of kexec. >> In this posting you mentioned that the recent regset changes >> you are planning might break kexec. >> >> Could you elaborate on this ? Also will these changes break >> kexec only on powerpc or other arch also ? >> > > Please see http://lkml.org/lkml/2008/1/18/583 > > No arch's kexec is affected unless it has removed its ELF_CORE_COPY_REGS > macro. My x86 changes in the x86/mm tree did that, but it's now been added > back to unbreak kexec. The powerpc patches I posted also remove the macro, > but those patches haven't been incorporated anywhere yet anyway; it's > simple just not to remove the macro (it's part of patch 10/16 in the > powerpc patch series; patch 10 does nothing but remove old code, all of > which but this is truly unused). > ... > As I mentioned in that lkml message, I think it would be better for kexec > to clean up its arch interfaces not to use elf_core_copy_regs at all. > There is already machine-specific kexec code that goes through contortions > with register values, so it might as well be consolidated into a single set > of contortions that produces the final data format (i.e. elf_gregset_t). > But there is no big rush to resolve that. The machine-specific macro > ELF_CORE_COPY_REGS no longer has any use for core files and it's unsightly > to keep it around with that name, but that's all. > Thanks for the descriptive mail. > kexec will not be broken by the user_regset changes when they are merged. > If kexec cleaned up, that and user_regset support together would permit > each arch to drop the ELF_CORE_COPY_REGS macro and cut down the clutter. > Will try to make necessary modifications for this. Thanks -Sachin From adobriyan at gmail.com Sun Jan 27 13:27:54 2008 From: adobriyan at gmail.com (Alexey Dobriyan) Date: Sun, 27 Jan 2008 16:27:54 +0300 Subject: Bunch of utrace crashes In-Reply-To: <20080124094453.GE6044@localhost.sw.ru> References: <20080124094453.GE6044@localhost.sw.ru> Message-ID: <20080127132754.GB3497@martell.zuzino.mipt.ru> > > in check_dead_utrace -- it can happen if utrace_clear_tsk() skipped > > clearing ->utrace pointer in otherwise normal detaching sequence. This > > can happen, due to utrace->u.live.signal being valid pointer at that time. > > Now this can happen when execution of resumed task starts: > > > > do_notify_resume > > get_signal_to_deliver > > tracehook_get_signal > > utrace_get_signal > > [utrace pointer found, utrace->lock taken] > [> "not taken", of course.] > > utrace_quiescent > > [signal is valid here, put onto live struct utrace without > > locking] > > > > So, ->utrace clearance skipped > > wake_quiescent > > check_dead_utrace > > BUG_ON(tsk->utrace == utrace); > Again let me conjure the theory on what's supposed to prevent this one, > and maybe you will see the holes in the logic (or maybe I will). > > utrace_detach holds the utrace lock. To be in the remove_engine and > wake_quiescent path, quiesce returned 1, meaning it was in TASK_TRACED. > After that remove_engine called utrace_clear_tsk, and u.live.signal was > set then. The theory is that when check_dead_utrace checks u.live.signal > it will match what utrace_clear_tsk saw. When it sees something there, > it doesn't take the path to rcu_utrace_free. The BUG_ON hits because > the theory does not hold. > > Since we hold the lock, the only thing waking the target up before us is > SIGKILL. When that happens, utrace_quiescent will clear u.live.signal > asynchronously without regard to utrace->lock. If this happens after > utrace_clear_tsk and before check_dead_utrace, then we hit the anomaly. > > Do you think that logic is sound? The original theory was based on the > expectation that nothing else de-quiesces the target while we hold the > lock. I think that's still sound with the exception of SIGKILL. > Do you think that is valid otherwise? > > If this logic does explain the problem, then perhaps it is fixed by the > patch below. The comment gives the rationale for why it should cover the > SIGKILL scenario. What do you think? > --- a/kernel/utrace.c > +++ b/kernel/utrace.c > @@ -1423,6 +1423,23 @@ restart: > */ > BUG_ON(tsk->utrace != utrace); > BUG_ON(utrace->u.live.signal != signal); > + if (unlikely(killed)) { > + /* > + * Synchronize with any utrace_detach that > + * might be in progress. It expected us to > + * stay quiescent, but SIGKILL broke that. > + * Taking this lock here serializes its > + * work so that if it had the lock and > + * thought we were still in TASK_TRACED, we > + * block until it has finished looking at > + * utrace. A utrace_detach that gets the > + * lock after we release it here will not > + * think we are quiescent at all, since we > + * are in TASK_RUNNING state now. > + */ > + spin_lock(&utrace->lock); > + spin_unlock(&utrace->lock); > + } > utrace->u.live.signal = NULL; > } How can this fix anything? utrace->u.live.signal was still set to valid on-stack pointer many lines above without any exclusion from utrace_detach(). From roland at redhat.com Sun Jan 27 21:27:09 2008 From: roland at redhat.com (Roland McGrath) Date: Sun, 27 Jan 2008 13:27:09 -0800 (PST) Subject: Bunch of utrace crashes In-Reply-To: Alexey Dobriyan's message of Sunday, 27 January 2008 16:27:54 +0300 <20080127132754.GB3497@martell.zuzino.mipt.ru> References: <20080124094453.GE6044@localhost.sw.ru> <20080127132754.GB3497@martell.zuzino.mipt.ru> Message-ID: <20080127212709.440862700F7@magilla.localdomain> The patch I posted had a braino, but not one apropos to your question. The GIT trees and 2.6-current/ patches have the proper version of that change. > How can this fix anything? utrace->u.live.signal was still set to > valid on-stack pointer many lines above without any exclusion from > utrace_detach(). utrace_detach is excluded by the conventions of "quiescence" synchronization, which is what this piece of the implementation is all about. That is, the remove_engine + wake_quiescent path is excluded because quiesce() will see that the target is not in TASK_TRACED state. So, code that looks at utrace->u.live.signal is excluded up until the set_current_state(TASK_TRACED) happens. quiesce and utrace_quiescent use the siglock to synchronize the check for TASK_TRACED with the transition into TASK_TRACED. I did manage to reproduce the BUG_ON(tsk->utrace == utrace) crash fairly reliably in one setup and diagnose what it was doing. AFAICT it was behaving as I described in my last posting. Synchronization on the way into TASK_TRACED was working fine, as I just described it here. utrace_detach's quiesce call decided the task was quiescent, because it really was in TASK_TRACED. The problem was that the task woke up in parallel due to SIGKILL, and immediately cleared utrace->u.live.signal with no synchronization. The utrace_clear_tsk and check_dead_utrace code expects that change to have been excluded when it thinks the task is quiescent. When that change was made without synchronization and came in between utrace_clear_tsk's check and check_dead_utrace's check, it caused the bookkeeping mismatch that produced the BUG_ON crash. The change I've now made is this: if we did enter TASK_TRACED, then upon waking up, take and release utrace->lock. If and only if we could have been observed to be in TASK_TRACED, then we might still be considered quiescent by the thread that holds utrace->lock. While quiescent, we must not touch our struct utrace. So, use utrace->lock to serialize after anyone who might consider us quiescent. We are already in TASK_RUNNING when we get the lock, so just by releasing it immediately we exclude anyone holding the lock and seeing us as quiescent. At that point, we are no longer quiescent in anyone's eyes, and so it is safe to clear utrace->u.live.signal. In the testing I've been able to do so far, this change is working. (In a setup where the test case crashed within a few minutes before, it ran all night with no problems.) It certainly needs more testing to be confident about the fix. I would very much appreciate your analysis and checking of my logic. The ptrace crash you hit is still unresolved. Since I never did reproduce that particular crash myself, I don't have great confidence in the patch I posted for it. I have not put that patch in yet. I'd be very grateful for any feedback you can give from testing or from reviewing the logic of my change. Thanks, Roland From kris.van.hees at oracle.com Mon Jan 28 20:12:04 2008 From: kris.van.hees at oracle.com (Kris Van Hees) Date: Mon, 28 Jan 2008 15:12:04 -0500 Subject: utrace git repository issues? Message-ID: <20080128201204.GC7325@oracle.com> Are there issues with the GIT repository for utrace? I've tried accessing it at the two locations I can find documented: git://git.fedoraproject.org/git/kernel/roland.git/ and git://git.fedoraproject.org/kernel/roland.git/ Yet neither seems to work, not even over HTTP (change git: into http:). Cheers, Kris From roland at redhat.com Tue Jan 29 01:29:51 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 28 Jan 2008 17:29:51 -0800 (PST) Subject: utrace git repository issues? In-Reply-To: Kris Van Hees's message of Monday, 28 January 2008 15:12:04 -0500 <20080128201204.GC7325@oracle.com> References: <20080128201204.GC7325@oracle.com> Message-ID: <20080129012951.9D88C2700F6@magilla.localdomain> Sorry about that. The fedoraproject.org server setup has morphed several times since I last looked. Noone seems to use my GIT repo, they just use the patches, so they haven't complained and I hadn't noticed that where I've been pushing every day stopped being accessible anywhere. You can now use: git://git.kernel.org/pub/scm/linux/kernel/git/frob/utrace.git/ The branch names are the same, but HEAD points to utrace-ptrace-compat so you'll get the tree you want by default. Note that it's likely that soon I will reorganize the branches as part of the new integration work. I might or might not continue from the same GIT history after that. So if you use GIT to fork your own branch off of mine, then you might have to rebase it later. Thanks, Roland From ananth at in.ibm.com Tue Jan 29 11:26:51 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Tue, 29 Jan 2008 16:56:51 +0530 Subject: incremental arch work In-Reply-To: <20080123023041.1D27326FA0A@magilla.localdomain> References: <1195004137.3856.48.camel@dyn9047018096.beaverton.ibm.com> <20071121023058.0D5C526F8BE@magilla.localdomain> <20071121042919.738AC26F8BE@magilla.localdomain> <20080122093727.GA26608@in.ibm.com> <20080123023041.1D27326FA0A@magilla.localdomain> Message-ID: <20080129112651.GA26391@in.ibm.com> On Tue, Jan 22, 2008 at 06:30:41PM -0800, Roland McGrath wrote: > The only things akin to specific plans I have in mind are those I've > discussed before and that are already on the TODO list. In particular, > the "engine interaction issues" area comes to mind. (See > https://www.redhat.com/archives/utrace-devel/2007-August/msg00024.html and > https://www.redhat.com/archives/utrace-devel/2007-September/msg00001.html > for detailed background.) This is something we are already pretty sure we > need to revamp, so hashing that out before preparing something for > submission seems like a good idea. For atleast the ordering of engine callbacks, we could use notifiers something akin to what we do with kprobes in the kernel. (We had touched upon this topic earlier, see http://sources.redhat.com/ml/systemtap/2006-q3/msg00235.html). But, as you've characterized in the "engine interaction, callback order" thread, this is probably not as straightforward in the utrace case, after all. > Working on a well-heeled breakpoint > facility that manages in the presence of other engines both to work right > and not to confuse the other engines would is a fine way to pin down the > concrete details of those interface changes. One way to simplify matters, atleast in the breakpoint case, maybe, is to just refuse to install breakpoints at virtual addresses whose underlying opcode is that of a breakpoint. In the uprobes code currently, there are checks that refuse uprobe insertion if that is indeed the case. Maybe its a worthwhile feature to incorporate in the factored out breakpoint facility. Ananth From bulten at netmarkpatent.com Tue Jan 29 14:07:48 2008 From: bulten at netmarkpatent.com (NETMARK PATENT) Date: Tue, 29 Jan 2008 16:07:48 +0200 Subject: =?windows-1254?q?T=FCrkiye=27de_Yay=FDnlanan_=DDlk_Ses_Markas=FD?= =?windows-1254?q?_!?= Message-ID: <3842-22008122914747758@ugur> T?rkiye'de Yay?nlanan ?lk Ses Markas? ! Siemens Aktiengesellschaft firmas?n?n notalar ?eklinde olan ses markas? 12.11.2007 tarihli 147 numaral? Resmi Marka B?lteni'nde ilan edildi. Bu marka ba?vurusu T?rkiye'de ilk ses markas? ba?vurusudur. Ses markas?n? TPE'nin bu linkinden dinleyebilirsiniz: http://www.turkpatent.gov.tr/dosyalar/SesMarkasi/SoundMarkSiemens.wav Bluetooth'lu Uzaktan Kumandal? Kaykay Patentli "Groundsurf" bildi?iniz kay kaylar gibi de?il. 3 tekerle?i olan bu kaykay?n ?n tekerle?ine ba?l? bir motor bulunmaktad?r. Bu motorla h?z kontrol edilir. Arka tekerlekler ise y?n vermede y?ksek bir kolayl?k sa?lacak ?ekilde tasarlanm??t?r. Ama bu kaykay?n en ?nemli ?zelli?i ise bluetooth'lu bir cep telefonu ile uzaktan kumanda edilebilir olmas?d?r. Bu ?ekilde fren yap?labilir, h?z? ayarlanabilir. Kaynak: Groundsurf Helva ??in Ba?vuru Yap?l?yor! T?rk k?lt?r?ne ait lokumun tescilinde gecikerek t?m d?nyada sahteleriyle u?ra?mak zorunda kalan ?reticiler, helva i?in erken ?nlem alacak. Tahin, Re?el ve Helva ?reticileri Derne?i ?n?m?zdeki g?nlerde lokum ve helvan?n tescilini almak i?in T?rk Patent Enst?tisi?ne ba?vuracak. Tahin, Re?el ve Helva ?reticileri Derne?i Ba?kan? Necati G?ksu, ?Lokum k?vam?nda bile olmayan j?le gibi ?eyleri T?rk lokumu ad? alt?nda sat?yorlar. Lokumun tescili konusunda ge? kald???m?z? kabul ediyoruz. Ancak ayn? ?eyi helvada da ya?amamak i?in bu kez erken hareket edece?iz? dedi.14.12.2007 Referans Bu bültenleri almak istemiyorsan1z bulten at netmarkpatent.com adresine bo_ bir mail göndermenizi rica ederiz. Böyle bir talebiniz olmad11 sürece düzenli olarak bültenlerimizi alabilirsiniz. NETMARK PATENT T:0212 220 31 20 F:0212 220 74 21 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eranian at googlemail.com Wed Jan 30 10:11:13 2008 From: eranian at googlemail.com (stephane eranian) Date: Wed, 30 Jan 2008 11:11:13 +0100 Subject: [perfmon2] perfmon2 merge news In-Reply-To: <20080124101354.C69EC26F9FD@magilla.localdomain> References: <20071119.050843.48408777.davem@davemloft.net> <20071119224845.GA27766@frankl.hpl.hp.com> <20071119.165313.163834190.davem@davemloft.net> <20071213160004.GC6740@frankl.hpl.hp.com> <20071214210709.GE9577@frankl.hpl.hp.com> <20080107072954.841DD26F9A4@magilla.localdomain> <7c86c4470801132217y4961d26dl4d887ca3d99a8adb@mail.gmail.com> <20080124101354.C69EC26F9FD@magilla.localdomain> Message-ID: <7c86c4470801300211k4d4220fct51c6db137f073eae@mail.gmail.com> Hello Roland, On Jan 24, 2008 11:13 AM, Roland McGrath wrote: > > It is necessary to block the thread each time the monitoring tool wants > > to access its PMU state. So, yes the block, modify, unblock sequence > > would be needed multiple times. You would want to minize the cost of > > it as much as possible. So if it is possible to do part of the work once > > and keep it *without* execution overhead, then that would be great. > > There is indeed a data structure for the PMU state in which I could > > easily stick a pointer to the utrace data structure. > > Having an engine attached with no event reports currently requested should > add no overhead at all to the thread's normal execution. In fact, as long > as you haven't lately done utrace_set_flags to request something, it should > change no code path at all until the task gets passed to release_task. > > > Now, in which kernel version can I expect to have the utrace engine? > > I am willing to try it out. > > It is available today in Fedora kernels, RHEL5 kernels, and in patches you > can build yourself against upstream 2.6.23 or trunk that support several > architectures (see http://redhat.com/~roland/utrace/). As to inclusion in > an upstream kernel version, that is an ongoing story and you can read other > threads on this mailing list about that. (In what upstream kernel version > can I expect to have perfmon2, my good man? ;-) > Okay, I will give it a try for 2.6.24. As for perfmon, I am hoping to start pushing some bits and pieces into 2.6.25. OTOH, there is a lot of things in flux at the moment, utrace vs. ptrace, BTS, some hrtimer stuff, Power. Then I have to look at some of the points people raised on the last LKML discussion regarding versioning of the interface. Busy busy, not counting I have started a new job.... From roland at redhat.com Wed Jan 30 20:22:58 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 30 Jan 2008 12:22:58 -0800 (PST) Subject: user_regset is in! Message-ID: <20080130202258.8935127018F@magilla.localdomain> The generic and x86 code for user_regset went into Linus's kernel tree today, destined for the 2.6.25 release. I'm very grateful to Ingo Molnar, who helped this happen via the x86.git tree. I've also had some positive feedback from the powerpc maintainer, and expect the powerpc user_regset code to go in upstream soon as well. If you are interested in utrace and you ever use an arch other than x86 and powerpc, now is the time to step forward as an arch advocate. If you are not confident you can do the kernel work, it is still a help to be the advocate for your arch and get help writing the code. If you can do the testing and work through some details with me, I will be glad to help out with writing the arch code. This is the first important milestone on the way to get utrace code into the upstream kernel. There is much more hard work ahead. Thanks, Roland From shaohua.li at intel.com Thu Jan 31 03:06:53 2008 From: shaohua.li at intel.com (Shaohua Li) Date: Thu, 31 Jan 2008 11:06:53 +0800 Subject: user_regset is in! In-Reply-To: <20080130202258.8935127018F@magilla.localdomain> References: <20080130202258.8935127018F@magilla.localdomain> Message-ID: <1201748813.25161.6.camel@sli10-desk.sh.intel.com> On Thu, 2008-01-31 at 04:22 +0800, Roland McGrath wrote: > The generic and x86 code for user_regset went into Linus's kernel tree > today, > destined for the 2.6.25 release. I'm very grateful to Ingo Molnar, > who helped > this happen via the x86.git tree. I've also had some positive > feedback from > the powerpc maintainer, and expect the powerpc user_regset code to go > in > upstream soon as well. > > If you are interested in utrace and you ever use an arch other than > x86 and > powerpc, now is the time to step forward as an arch advocate. If you > are > not confident you can do the kernel work, it is still a help to be the > advocate for your arch and get help writing the code. If you can do > the > testing and work through some details with me, I will be glad to help > out > with writing the arch code. > > This is the first important milestone on the way to get utrace code > into the > upstream kernel. There is much more hard work ahead. Hi, I suppose we currently only need do the regset work, right? Attached is the ia64 part, which mostly is a copy-paste of previous utrace patch with some fixes. The issue is we have some duplicate code to access registers. Will you add the ptrace_layout_access API? This could help remove a lot of duplicate code. Thanks, Shaohua -------------- next part -------------- A non-text attachment was scrubbed... Name: utrace-regset-ia64.patch Type: text/x-patch Size: 41138 bytes Desc: not available URL: From adobriyan at sw.ru Thu Jan 31 08:19:44 2008 From: adobriyan at sw.ru (Alexey Dobriyan) Date: Thu, 31 Jan 2008 11:19:44 +0300 Subject: user_regset is in! In-Reply-To: <20080130202258.8935127018F@magilla.localdomain> References: <20080130202258.8935127018F@magilla.localdomain> Message-ID: <20080131081944.GA5425@localhost.sw.ru> On Wed, Jan 30, 2008 at 12:22:58PM -0800, Roland McGrath wrote: > The generic and x86 code for user_regset went into Linus's kernel tree today, > destined for the 2.6.25 release. Why copy_regset_to_user() takes whole "view" (regardless of value of this concept) but not just needed regset? REGSET_XFP is X-FP while all documentation and previous code name it FP-X. From wenji.huang at oracle.com Mon Feb 4 08:36:45 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Mon, 04 Feb 2008 16:36:45 +0800 Subject: About x86_64-gsbase Message-ID: <47A6CE9D.1050900@oracle.com> An HTML attachment was scrubbed... URL: From roland at redhat.com Mon Feb 4 10:03:55 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 4 Feb 2008 02:03:55 -0800 (PST) Subject: About x86_64-gsbase In-Reply-To: Wenji Huang's message of Monday, 4 February 2008 16:36:45 +0800 <47A6CE9D.1050900@oracle.com> References: <47A6CE9D.1050900@oracle.com> Message-ID: <20080204100359.372122701A8@magilla.localdomain> Please do not use HTML mail. Yes, that's nothing we don't know. Thanks, Roland From wenji.huang at oracle.com Tue Feb 5 01:33:10 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Tue, 05 Feb 2008 09:33:10 +0800 Subject: Resend: About x86_64-gsbase Message-ID: <47A7BCD6.6010306@oracle.com> Sorry, the previous mail was sent in HTML without caution. Now, resend: Hi, The bug x86_64-gsbase (http://sourceware.org/systemtap/wiki/utrace/tests) is to read gs_base register through PTRACE_PEEKUSR. It fails in 2.6.24 upstream kernel and utrace patched kernel. Seem that ptrace -> arch_ptrace -> getreg Or ptrace -> arch_ptrace -> ptrace_peekusr -> ptrace_layout_access -> getreg return incorrect value. But I applied the patch in the thread (http://lkml.org/lkml/2007/11/21/82) which had been merged into mainline since 2.6.24-git9 and found the problem gone away. The re-write utrace based on that code should also get rid of the bug. Thanks, Wenji From ananth at in.ibm.com Thu Feb 7 11:36:53 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Thu, 7 Feb 2008 17:06:53 +0530 Subject: user_regset is in! In-Reply-To: <20080130202258.8935127018F@magilla.localdomain> References: <20080130202258.8935127018F@magilla.localdomain> Message-ID: <20080207113653.GB20659@in.ibm.com> On Wed, Jan 30, 2008 at 12:22:58PM -0800, Roland McGrath wrote: > The generic and x86 code for user_regset went into Linus's kernel tree today, > destined for the 2.6.25 release. I'm very grateful to Ingo Molnar, who helped > this happen via the x86.git tree. I've also had some positive feedback from > the powerpc maintainer, and expect the powerpc user_regset code to go in > upstream soon as well. Paul Mackerras has pulled in the regset changes. Should be in Linus' tree tomorrow. Ananth From davem at davemloft.net Thu Feb 7 13:10:00 2008 From: davem at davemloft.net (David Miller) Date: Thu, 07 Feb 2008 05:10:00 -0800 (PST) Subject: user_regset is in! In-Reply-To: <20080207113653.GB20659@in.ibm.com> References: <20080130202258.8935127018F@magilla.localdomain> <20080207113653.GB20659@in.ibm.com> Message-ID: <20080207.051000.105057779.davem@davemloft.net> From: Ananth N Mavinakayanahalli Date: Thu, 7 Feb 2008 17:06:53 +0530 > On Wed, Jan 30, 2008 at 12:22:58PM -0800, Roland McGrath wrote: > > The generic and x86 code for user_regset went into Linus's kernel tree today, > > destined for the 2.6.25 release. I'm very grateful to Ingo Molnar, who helped > > this happen via the x86.git tree. I've also had some positive feedback from > > the powerpc maintainer, and expect the powerpc user_regset code to go in > > upstream soon as well. > > Paul Mackerras has pulled in the regset changes. Should be in Linus' > tree tomorrow. I just asked Linus to pull in sparc regset support from me as well. From roland at redhat.com Thu Feb 7 19:55:45 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 7 Feb 2008 11:55:45 -0800 (PST) Subject: user_regset is in! In-Reply-To: Ananth N Mavinakayanahalli's message of Thursday, 7 February 2008 17:06:53 +0530 <20080207113653.GB20659@in.ibm.com> References: <20080130202258.8935127018F@magilla.localdomain> <20080207113653.GB20659@in.ibm.com> Message-ID: <20080207195545.B1A892701AB@magilla.localdomain> > Paul Mackerras has pulled in the regset changes. Should be in Linus' > tree tomorrow. Indeed, it is in now. Thanks, Roland From roland at redhat.com Thu Feb 7 19:58:26 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 7 Feb 2008 11:58:26 -0800 (PST) Subject: user_regset is in! In-Reply-To: David Miller's message of Thursday, 7 February 2008 05:10:00 -0800 <20080207.051000.105057779.davem@davemloft.net> References: <20080130202258.8935127018F@magilla.localdomain> <20080207113653.GB20659@in.ibm.com> <20080207.051000.105057779.davem@davemloft.net> Message-ID: <20080207195826.8E2A22701AB@magilla.localdomain> > I just asked Linus to pull in sparc regset support from me as well. Thanks a lot, Dave! I did start on it over a weekend and got at least halfway to updated patches that would compile, but then other things pulled me away and I forgot to get back to sparc. I very much appreciate your taking the time to get this in so early! Thanks, Roland From roland at redhat.com Thu Feb 7 21:11:57 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 7 Feb 2008 13:11:57 -0800 (PST) Subject: user_regset is in! In-Reply-To: Alexey Dobriyan's message of Thursday, 31 January 2008 11:19:44 +0300 <20080131081944.GA5425@localhost.sw.ru> References: <20080130202258.8935127018F@magilla.localdomain> <20080131081944.GA5425@localhost.sw.ru> Message-ID: <20080207211157.997972701AB@magilla.localdomain> Sorry for the delay in replying. > Why copy_regset_to_user() takes whole "view" (regardless of value of this > concept) but not just needed regset? To be honest, it was mostly just following the old utrace_regset interface without a great deal of new thought. Part of the original logic there was to discourage direct access to the regset functions without having made the utrace_regset call right before, because it does wait_task_inactive and covers up the implementation details of the important semantics that has. That is not relevant to the integration of user_regset in upstream ptrace, which is probably all that copy_regset_{to,from}_user will ever be for. But I do think this is the more convenient interface. The struct user_regset pointers not directly accessible, so every use would be &...view()->regets[n] anyway. > REGSET_XFP is X-FP while all documentation and previous code name it FP-X. I decided NT_PRXFPREG was the name to follow. I consider the PTRACE_* request names "legacy" rather than a definitive model to follow. Aside from that, the ELF note types (NT_* macros) are the only names around to match that are used in an existing userland API. So I figured following the public name for the implementation functions would probably be the most clear in the long run. Thanks, Roland From roland at redhat.com Thu Feb 7 23:59:02 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 7 Feb 2008 15:59:02 -0800 (PST) Subject: user_regset is in! In-Reply-To: Shaohua Li's message of Thursday, 31 January 2008 11:06:53 +0800 <1201748813.25161.6.camel@sli10-desk.sh.intel.com> References: <20080130202258.8935127018F@magilla.localdomain> <1201748813.25161.6.camel@sli10-desk.sh.intel.com> Message-ID: <20080207235902.314B82701AC@magilla.localdomain> Sorry for the delay. > I suppose we currently only need do the regset work, right? Attached is > the ia64 part, which mostly is a copy-paste of previous utrace patch > with some fixes. The issue is we have some duplicate code to access > registers. Will you add the ptrace_layout_access API? This could help > remove a lot of duplicate code. For ia64, there are three areas that need attention. These three tracks can all go in parallel. The user_regset work itself is the one I'd focus on third, because the other two should be quicker to get merged upstream. On each of these tracks, it's probably best to produce multiple incremental patches that don't break anything along the way (bisect-friendly) to make it easy for the upstream maintainers to digest. 1. arch_has_single_step/arch_has_block_step This is the simplest item, pretty well trivial. Define the macros and the user_*_step entry points. The ia64 ones are really simple, just flipping psr bits, so you might make them inlines in asm/ptrace.h. With that done, you can remove these: case PTRACE_SYSCALL: case PTRACE_CONT: case PTRACE_KILL: case PTRACE_SINGLESTEP: case PTRACE_SINGLEBLOCK: case PTRACE_DETACH: and let ptrace_request handle them. As you can see in the examples from other arch's that have merged this (x86, powerpc, sparc), I would do this as two patches: one that adds the macros/entrypoints, and one that cleans up those ptrace cases. I'd expect those to be accepted upstream by the ia64 maintainers without any trouble. It would be great if you could update the block-step.c test in ptrace-tests (http://sources.redhat.com/cgi-bin/cvsweb.cgi/tests/ptrace-tests/tests/?cvsroot=systemtap) to port it to ia64. It just needs some hand-crafted assembly for ia64 that makes it easy for the test to verify that a block-step happened and not a single-step. You can post a patch for the test here. 2. TIF_RESTORE_RSE It's time to finally get that patch integrated upstream. The arch_ptrace_stop patch has gone into the generic upstream kernel now. So the ia64 patches to use this can go in upstream soon too I hope. With TIF_RESTORE_RSE in place, you can define arch_ptrace_stop. That makes it possible to get rid of find_thread_for_addr and all the associated code. This in turn lets you convert sys_ptrace into an arch_ptrace function. The PTRACE_POKE{TEXT,DATA} cases can be removed and those handled by ptrace_request (in the default case). You still need an ia64-specific case for PTRACE_PEEK{TEXT,DATA} just because of the nonstandard ABI using force_successful_syscall_return. But it can change to use access_process_vm directly and not ia64_peek et al. If I were doing it there would be about six patches to do all that. But work out whatever makes the upstream ia64 folks happy. 3. user_regset The first thing about your patch is that we don't want the DBR/IBR in a user_regset. This is part of the plan that changed between the original utrace porting work and the current development. Those debug registers are not user-visible state in the sense of something a user thread can observe about itself, so they don't really fit. We now plan for those resources to be presented via a higher-level interface, hw_breakpoint. That work still has yet to gel, but it may pick up soon. For now, the only thing you should do is move the old ptrace code for that (now part of access_uarea) cleanly into a function (or get/set pair) just for ptrace's access to debug registers. When it's time to do the hw_breakpoint port, it will just hook in to replace those one or two functions directly. I've concluded that I probably won't port ptrace_layout_access at all. I think ia64 is the only arch that has a really complicated mapping to deal with. So there isn't really the need for it generically. You can take that code and use it in your ia64 arch code if you want to. On ia64 you have two separate layouts that map to strange orderings of parts of regsets, uarea and pt_all_user_regs. But even for that, I don't think I'd do it the table-driven way this time. I can think of other ways to do it. My inclination would be to use some macros so there is just one big macro for each layout, and each gets used once or twice in access_uarea (or functions replacing it) and ptrace_getregs/ptrace_setregs. The layout macro would consist of just the ordered invocations of another macro for each segment of the layout (i.e. one per element in ptrace_layout_access from the old utrace patch). For the PEEKUSR/POKEUSR, that macro would be defined to a switch case for a one-word regset accessor call; for [gs]etregs, perhaps a copy_{from,to}_user_regset call per macro. You can figure out with the upstream ia64 maintainers in how many incremental pieces you want to do all the work. Do whatever they are comfortable with. I've found that many smaller pieces are usually better for me as well as what the maintainers tend to prefer. Given the spaghetti on ia64, it might be easiest to just add new parallel code as your patch does and test it with core dumps before cleaning up ptrace. What's a little iffy about that approach is that the register-setting code that goes in earlier never actually gets used and tested until later (vs piecemeal converting bits of the ptrace code and testing ptrace along the way). You and the ia64 maintainers are the ones who have to decide how to go. Thanks, Roland From kris.van.hees at oracle.com Fri Feb 8 04:15:17 2008 From: kris.van.hees at oracle.com (Kris Van Hees) Date: Thu, 7 Feb 2008 23:15:17 -0500 Subject: Some testing on crashers... Message-ID: <20080208041517.GE7325@oracle.com> I ran all testsuite tests (both check and xcheck) a couple of hundred times on a Debian 4.0 32-bit instance using the utrace-ptrace-compat git branch kernel version. The instance is running as a fully virtualized Xen SMP guest with 2 CPUs. The results are very good: PASS: ptrace-on-job-control-stopped PASS: attach-wait-on-stopped PASS: detach-can-signal PASS: attach-sigcont-wait PASS: sa-resethand-on-cont-signal PASS: ptrace-cont-sigstop-detach PASS: tif-syscall-trace-after-detach PASS: event-exit-proc-maps PASS: event-exit-proc-environ PASS: x86_64-ia32-gs SKIP: x86_64-gsbase SKIP: powerpc-altivec PASS: peekpokeusr FAIL: watchpoint SKIP: block-step PASS: step-jump-cont FAIL: step-jump-cont-strict SKIP: ppc-dabr-race PASS: step-into-handler SKIP: user-area-access PASS: late-ptrace-may-attach-check PASS: tracer-lockup-on-sighandler-kill PASS: clone-get-signal PASS: ppc-ptrace-exec-full-regs PASS: x86_64-cs None of the tests actually resulted in a single crash throughout the execution of all tests. I am working on setting up the same configuration, this time non-virtualized, and run the same iteration across all tests, to see if the virtualization may have some effect on things. Kris From jdike at linux.intel.com Fri Feb 8 15:04:19 2008 From: jdike at linux.intel.com (jdike) Date: Fri, 8 Feb 2008 10:04:19 -0500 Subject: Some testing on crashers... In-Reply-To: <20080208041517.GE7325@oracle.com> Message-ID: <000301c86a63$e1bdfb90$42347f0a@amr.corp.intel.com> > I ran all testsuite tests (both check and xcheck) a couple of hundred > times on a Debian 4.0 32-bit instance using the utrace-ptrace-compat git > branch kernel version You might make sure utrace can boot UML. utrace has broken UML in the past. Jeff From roland at redhat.com Sat Feb 9 01:27:53 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 8 Feb 2008 17:27:53 -0800 (PST) Subject: Some testing on crashers... In-Reply-To: Kris Van Hees's message of Thursday, 7 February 2008 23:15:17 -0500 <20080208041517.GE7325@oracle.com> References: <20080208041517.GE7325@oracle.com> Message-ID: <20080209012753.D9C6B26F9A4@magilla.localdomain> Thanks for the testing. Note that most of the crasher tests are for intermittent race bugs that might take a long time to show. They look for TESTTIME environment variable to set how long to keep trying, and the defaults are pretty short. You should run those for long periods to achieve confidence that you won't hit any crashes. Thanks, Roland From wenji.huang at oracle.com Wed Feb 13 07:56:42 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Wed, 13 Feb 2008 15:56:42 +0800 Subject: About x86_64-cs Message-ID: <47B2A2BA.3030306@oracle.com> Hi, The x86_64-cs in utrace wiki page reports that the test could crash kernel. I verify that in old kernel release 2.6.24. But in latest kernel 2.6.25-rc1, the problem seems to be resolved. The call tree : arch_ptrace -> putreg-> set_segment_reg In function set_segment_reg, the related code is like: /* * Can't actually change these in 64-bit mode. */ case offsetof(struct user_regs_struct,cs): if (unlikely(value == 0)) return -EIO; #ifdef CONFIG_IA32_EMULATION if (test_tsk_thread_flag(task, TIF_IA32)) task_pt_regs(task)->cs = value; #endif break; In fact, the cs register won't be written in x86_64. And I also find the test passed in i386 environment. Regards, Wenji From kris.van.hees at oracle.com Wed Feb 13 15:05:59 2008 From: kris.van.hees at oracle.com (Kris Van Hees) Date: Wed, 13 Feb 2008 10:05:59 -0500 Subject: Some testing on crashers... In-Reply-To: <20080209012753.D9C6B26F9A4@magilla.localdomain> References: <20080208041517.GE7325@oracle.com> <20080209012753.D9C6B26F9A4@magilla.localdomain> Message-ID: <20080213150559.GH7325@oracle.com> On Fri, Feb 08, 2008 at 05:27:53PM -0800, Roland McGrath wrote: > Thanks for the testing. Note that most of the crasher tests are for > intermittent race bugs that might take a long time to show. They look for > TESTTIME environment variable to set how long to keep trying, and the > defaults are pretty short. You should run those for long periods to > achieve confidence that you won't hit any crashes. So far, no crashes with TESTTIME set to 3600 and 7200. This is on 32-bit, 2.6.24 kernel, running as a full virtualized guest in Xen. The testing on a physical box is slated for today. Kris From jan.kratochvil at redhat.com Wed Feb 13 19:14:47 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Wed, 13 Feb 2008 20:14:47 +0100 Subject: Some testing on crashers... In-Reply-To: <20080213150559.GH7325@oracle.com> References: <20080208041517.GE7325@oracle.com> <20080209012753.D9C6B26F9A4@magilla.localdomain> <20080213150559.GH7325@oracle.com> Message-ID: <20080213191447.GA11687@host0.dyn.jankratochvil.net> On Wed, 13 Feb 2008 16:05:59 +0100, Kris Van Hees wrote: > On Fri, Feb 08, 2008 at 05:27:53PM -0800, Roland McGrath wrote: > > Thanks for the testing. Note that most of the crasher tests are for > > intermittent race bugs that might take a long time to show. They look for > > TESTTIME environment variable to set how long to keep trying, and the > > defaults are pretty short. You should run those for long periods to > > achieve confidence that you won't hit any crashes. > > So far, no crashes with TESTTIME set to 3600 and 7200. This is on 32-bit, > 2.6.24 kernel, running as a full virtualized guest in Xen. The testing on > a physical box is slated for today. Your utrace-ptrace-compat kernel is not the full utrace implementation which the testsuite targets, it is only its `regset' part. Therefore some (all?) of the crashers just do not apply to such non-full-utrace kernels. Even if it would be the full utrace kernel all the crasher problems were already fixed except clone-get-signal which has unfortunately very rare reproducibility. It reproduces probably best on s390. Still it was seen even on x86_64. It is unfortunately very probably your machine just did not reproduce it. crasher testcases are left marked as `crasher' even after their fix as if you run them on arbitrary (possibly old) kernel it may surprise you by its crash. The x86_64-cs vanilla crasher does not apply to you as you run on 32-bit. Sure thanks for the verifications. Regards, Jan From jan.kratochvil at redhat.com Wed Feb 13 19:57:08 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Wed, 13 Feb 2008 20:57:08 +0100 Subject: About x86_64-cs In-Reply-To: <47B2A2BA.3030306@oracle.com> References: <47B2A2BA.3030306@oracle.com> Message-ID: <20080213195708.GB11687@host0.dyn.jankratochvil.net> Hi, On Wed, 13 Feb 2008 08:56:42 +0100, Wenji Huang wrote: ... > The x86_64-cs in utrace wiki page reports that the test could crash kernel. > I verify that in old kernel release 2.6.24. > But in latest kernel 2.6.25-rc1, the problem seems to be resolved. Thanks for the test, http://sourceware.org/systemtap/wiki/utrace/tests updated. On 2.6.25-rc1-git2 built as http://koji.fedoraproject.org/scratch/jkratoch/task_424104/kernel-vanilla-2.6.25-0.37.rc1.git2.vanilla.fc9.x86_64.rpm I get: ptrace(PTRACE_POKEUSER, 2093, 8*CS, 0xffff) = 0 ptrace(PTRACE_CONT, 2093, 0, SIG_0) = 0 x86_64-cs: x86_64-cs.c:85: main: Assertion `0' failed. wait4(2093, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGABRT}], 0, NULL) = 2093 ... > And I also find the test passed in i386 environment. Yes, it always worked on i386-native kernel. Thanks, Jan From roland at redhat.com Wed Feb 13 21:32:18 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 13 Feb 2008 13:32:18 -0800 (PST) Subject: Some testing on crashers... In-Reply-To: Jan Kratochvil's message of Wednesday, 13 February 2008 20:14:47 +0100 <20080213191447.GA11687@host0.dyn.jankratochvil.net> References: <20080208041517.GE7325@oracle.com> <20080209012753.D9C6B26F9A4@magilla.localdomain> <20080213150559.GH7325@oracle.com> <20080213191447.GA11687@host0.dyn.jankratochvil.net> Message-ID: <20080213213218.7D5C9270192@magilla.localdomain> > Your utrace-ptrace-compat kernel is not the full utrace implementation which > the testsuite targets, it is only its `regset' part. Therefore some (all?) > of the crashers just do not apply to such non-full-utrace kernels. That is not true, unless I am misunderstanding what you are referring to. utrace-ptrace-compat is the "everything of utrace" branch. (The kernels you tested a while back that were "just regset parts" were not any of the existing utrace branches at all, but based on the user_regset patch series that is now in 2.6.25-rc1.) > Even if it would be the full utrace kernel all the crasher problems were > already fixed except clone-get-signal which has unfortunately very rare > reproducibility. It reproduces probably best on s390. Still it was seen even > on x86_64. It is unfortunately very probably your machine just did not > reproduce it. Since these were intermittent race crashes, I don't like to declare that we are sure they are fixed just because previously reliable reproducers no longer crash for us. I hope that's so, but that's why more long and grueling testing is good to have. Thanks, Roland From jan.kratochvil at redhat.com Wed Feb 13 21:43:56 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Wed, 13 Feb 2008 22:43:56 +0100 Subject: Some testing on crashers... In-Reply-To: <20080213213218.7D5C9270192@magilla.localdomain> References: <20080208041517.GE7325@oracle.com> <20080209012753.D9C6B26F9A4@magilla.localdomain> <20080213150559.GH7325@oracle.com> <20080213191447.GA11687@host0.dyn.jankratochvil.net> <20080213213218.7D5C9270192@magilla.localdomain> Message-ID: <20080213214356.GA20113@host0.dyn.jankratochvil.net> On Wed, 13 Feb 2008 22:32:18 +0100, Roland McGrath wrote: > > Your utrace-ptrace-compat kernel is not the full utrace implementation which > > the testsuite targets, it is only its `regset' part. Therefore some (all?) > > of the crashers just do not apply to such non-full-utrace kernels. > > That is not true, unless I am misunderstanding what you are referring to. > utrace-ptrace-compat is the "everything of utrace" branch. My mistake, sure your information is the right one. Sorry, Jan From roland at redhat.com Wed Feb 13 22:06:05 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 13 Feb 2008 14:06:05 -0800 (PST) Subject: About x86_64-cs In-Reply-To: Jan Kratochvil's message of Wednesday, 13 February 2008 20:57:08 +0100 <20080213195708.GB11687@host0.dyn.jankratochvil.net> References: <47B2A2BA.3030306@oracle.com> <20080213195708.GB11687@host0.dyn.jankratochvil.net> Message-ID: <20080213220605.40116270192@magilla.localdomain> Thanks, Wenji. I already knew I'd fixed the bug. ;-) The bug in question only ever affected a 32-bit process on a 64-bit kernel. That test as written hits the assert when built for x86_64. Changes to %cs or %ss have no effect on a 64-bit process, so the traced process does not crash as a 32-bit process with a bad %cs value should. It is still a bit useful to run this test built for 64-bit, since it exercises some of the other corners of the same code paths. I've adjusted the test. Thanks, Roland From maynardj at us.ibm.com Sat Feb 16 00:07:31 2008 From: maynardj at us.ibm.com (Maynard Johnson) Date: Fri, 15 Feb 2008 18:07:31 -0600 Subject: utrace and perfmon2 Message-ID: <47B62943.6090205@us.ibm.com> Hi, I have a requirement to build a kernel with both utrace and perfmon2 patches. I'm using kernel version 2.6.24. Since neither of these features are accepted upstream yet (well, Jim Keniston tells me that some initial pieces of utrace have been accepted), the patches don't play nicely with one another. The patches apply OK, but I get a compile failure in perfmon/perfmon_syscalls.c because it's trying to use the function ptrace_check_attach (removed by the utrace patch). A separate note is being sent to the perfmon2 maintainer to see if he might help, but I thought I'd post here as well, in case someone has gone into this territory already. Thanks in advance for any guidance. -Maynard Johnson From eranian at googlemail.com Sat Feb 16 06:54:08 2008 From: eranian at googlemail.com (stephane eranian) Date: Sat, 16 Feb 2008 07:54:08 +0100 Subject: utrace and perfmon2 In-Reply-To: <47B62943.6090205@us.ibm.com> References: <47B62943.6090205@us.ibm.com> Message-ID: <7c86c4470802152254u344f71f7u1b0a9d74dc66fbca@mail.gmail.com> Maynard, On Feb 16, 2008 1:07 AM, Maynard Johnson wrote: > Hi, > I have a requirement to build a kernel with both utrace and perfmon2 > patches. I'm using kernel version 2.6.24. Since neither of these > features are accepted upstream yet (well, Jim Keniston tells me that > some initial pieces of utrace have been accepted), the patches don't > play nicely with one another. The patches apply OK, but I get a compile > failure in perfmon/perfmon_syscalls.c because it's trying to use the > function ptrace_check_attach (removed by the utrace patch). A separate > note is being sent to the perfmon2 maintainer to see if he might help, > but I thought I'd post here as well, in case someone has gone into this > territory already. > I have responded to the other message. Currently, all the perfmon code needs is an equivalent to ptrack_check_attach(). I assume that a utrace kernel emulates the user level PTRACE interface. From dialloadam at hotmail.fr Sun Feb 17 00:30:45 2008 From: dialloadam at hotmail.fr (Adams Diallo) Date: 17 Feb 2008 00:30:45 -0000 Subject: Sir/Madam Message-ID: <20080217003045.28413.qmail@ns31081.ovh.net> Sir/Madam, I am Mr.Adams Diallo,and I am contacting you from Dakar, Senegal for a mutual business relationship and investment. I have some funds realized through contract execution and I need your cooperation to invest the funds. The first stage requires transferring the funds to your account for subsequent investment. I have chosen to contact you because you live in a country where I want to invest in. I therefore want you to work with me as a partner. On receipt of your response, I will send you full details of the transaction and more information about myself. I await your prompt response. Best regards, Adams Diallo. From cesarioromeiro at uol.com.br Sun Feb 17 02:34:02 2008 From: cesarioromeiro at uol.com.br (Cesario Romeiro) Date: Sun, 17 Feb 2008 02:34:02 GMT Subject: Proibido vender produtos, somente consumo pessoal! Message-ID: <200802170634.m1H6YAwt006472@mx3.redhat.com> TOWAKI INTERNACIONAL Uma Gigante Mundial Japonesa na ?rea da Sa?de e Bem Estar... Abre Mercado Brasileiro com escrit?rios em nosso Pa?s: Curitiba, S?o Paulo, Bras?lia e Bel?m do Par?. Conhe?a esta grande oportunidade e decida... Estamos na fase de Pr?-Marketing, entre agora para aproveitar o derramamento. Marketing Bin?rio (Bin?rio Hibrido com 3 formas de ganho) ganhos at? 500 linhas na profundidade R$ 50,00 de cada direto e indiretos at? o 5 nivel, ap?s R$ 40,00 at? o 500? nivel Pr?-Cadastro agora e lan?amento neste m?s de Fevereiro/2008. Aproveite e reserve sua vaga gr?tis comigo. (PROIBIDO VENDER PRODUTOS, SOMENTE CONSUMO PESSOAL). Produtos Exclusivos PUERARIA MIRIFICA FAZ REPOSI??O HORMONAL COMBATE A QUEDA PREMATURA DOS CABELOS AJUDA NO RE-NASCIMENTO DOS CABELOS, FORTALECENDO-OS E ESCURECENDO-OS ESTIMULA A CIRCULA??O DO SANGUE COMBATE RUGAS, MANCHAS E FLACIDEZ - 100% NATURAL COMBATE TPM, C?LICAS E MENOPAUSA Usada h? mais de 280 anos na Tail?ndia para rejuvenescimento. De 1.000 a 10.000 vezes mais potente que a ISOFLAVONA da Soja. Certificado por mais de 5 minist?rios de sa?de ao redor do mundo (EUA, Jap?o, Tail?ndia, Alemanha, Cor?ia, Austr?lia...etc). ALPHA LIP?ICO MELHORA O SISTEMA CIRCULAT?RIO 400 vezes mais potente que a Vitamina C, combate radicais livres, diabetes, e melhora a press?o sangu?nea. Muito utilizado em dietas. (reduz medidas), melhora Katakori (dores nas costas). Desintoxica o organismo. Visite nossos sites: www.mirificajapan.com www.oportunidadeincrivel.com D? uma lida cuidadosa e muito criteriosa em todas as explica??es de como o produto funciona, depois fa?a a sua inscri??o gr?tis solicitando o envio do formul?rio atrav?s do email abaixo. Cesario Romeiro Tel: 11 - 9656-6172 ou 4612-4733 E-mail: cesarioromeiro at uol.com.br -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mirificajapan.jpg Type: image/jpeg Size: 29683 bytes Desc: not available URL: -------------- next part -------------- --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 080216-0, 16/02/2008 Tested on: 2/16/aaaa 23:34:02 avast! - copyright (c) 1988-2008 ALWIL Software. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From support at mail.com Sun Feb 17 22:02:26 2008 From: support at mail.com (dany) Date: Mon, 18 Feb 2008 00:02:26 +0200 Subject: =?windows-1255?b?IPnzIPLjIOTh6fog7Pnu5+X6IOXg6fjl8unt?= Message-ID: ?? ???? ?? ???? ???????? ??? ?????, ????? ?? ??? ????? ????? ?????? ?? ??????? ????? ?????? ????? :??? ??? ????? ????? ?????? ?? ???? ???? ????? ?? ?? ????? ????? ???????? ????? ????? ??????? .??? ??? ??????? ????? ??????? ????? ????? : ????? ?? ????? ? ??? ?????, ?????? ??????, ??????, ???? ????, ?????? ????? ??/? ?????,???? ?????, ?????? ?????, ????? ?????, ??? ??? ???? ?????? ???? ??? ?????? ????? ???? ????? ??, ???? ??? ???? ???? ?? ???? ???? ?????? ?????? - 0502664508 ??????? ????? ?????- ??? ??? ??????? ????? ???????, ??????, ?????? ????? - ??? ??? ????????? ?????? ????? ?????? ????? - ???? ??? ???? ?????? ?? ????? ??? ?????? ??????? ??????? ????? ????? ????? ????? ?????? ?????? ????? ??????? ??????? ??? ?????? ??? ?? ????? ?? ???? ?? ??? ???????? ??? ???????. ???? ????? ?????? ?? ??? ????? ??? Unsubscribe -------------- next part -------------- An HTML attachment was scrubbed... URL: From maynardj at us.ibm.com Mon Feb 18 23:01:31 2008 From: maynardj at us.ibm.com (Maynard Johnson) Date: Mon, 18 Feb 2008 17:01:31 -0600 Subject: utrace and perfmon2 In-Reply-To: <7c86c4470802152254u344f71f7u1b0a9d74dc66fbca@mail.gmail.com> References: <47B62943.6090205@us.ibm.com> <7c86c4470802152254u344f71f7u1b0a9d74dc66fbca@mail.gmail.com> Message-ID: <47BA0E4B.7060504@us.ibm.com> stephane eranian wrote: > Maynard, > > > On Feb 16, 2008 1:07 AM, Maynard Johnson wrote: > >> Hi, >> I have a requirement to build a kernel with both utrace and perfmon2 >> patches. I'm using kernel version 2.6.24. Since neither of these >> features are accepted upstream yet (well, Jim Keniston tells me that >> some initial pieces of utrace have been accepted), the patches don't >> play nicely with one another. The patches apply OK, but I get a compile >> failure in perfmon/perfmon_syscalls.c because it's trying to use the >> function ptrace_check_attach (removed by the utrace patch). A separate >> note is being sent to the perfmon2 maintainer to see if he might help, >> but I thought I'd post here as well, in case someone has gone into this >> territory already. >> >> > I have responded to the other message. Currently, all the perfmon code > needs is an equivalent to ptrack_check_attach(). I assume that a utrace > kernel emulates the user level PTRACE interface. > Stephane, correct me if I'm wrong, but it seems that the main purpose of perfmon's use of ptrace_check_attach is to make sure the traced process is stopped. If that is true, perhaps all that's needed is to call the utrace function to stop the traced process -- utrace_set_flags with UTRACE_ACTION_QUIESCE. Thanks. -Maynard From shaohua.li at intel.com Wed Feb 20 03:26:26 2008 From: shaohua.li at intel.com (Shaohua Li) Date: Wed, 20 Feb 2008 11:26:26 +0800 Subject: user_regset is in! In-Reply-To: <20080207235902.314B82701AC@magilla.localdomain> References: <20080130202258.8935127018F@magilla.localdomain> <1201748813.25161.6.camel@sli10-desk.sh.intel.com> <20080207235902.314B82701AC@magilla.localdomain> Message-ID: <1203477986.23071.3.camel@sli10-desk.sh.intel.com> On Fri, 2008-02-08 at 07:59 +0800, Roland McGrath wrote: > Sorry for the delay. > > > I suppose we currently only need do the regset work, right? Attached > is > > the ia64 part, which mostly is a copy-paste of previous utrace patch > > with some fixes. The issue is we have some duplicate code to access > > registers. Will you add the ptrace_layout_access API? This could > help > > remove a lot of duplicate code. > > For ia64, there are three areas that need attention. These three > tracks > can all go in parallel. The user_regset work itself is the one I'd > focus > on third, because the other two should be quicker to get merged > upstream. > On each of these tracks, it's probably best to produce multiple > incremental > patches that don't break anything along the way (bisect-friendly) to > make > it easy for the upstream maintainers to digest. SOrry for the long delay, just back from vocation. > > 1. arch_has_single_step/arch_has_block_step > 2. TIF_RESTORE_RSE The RSE patch is in base kernel. For the cleanup, Petr already sent a series of patches, see thread http://marc.info/?l=linux-ia64&m=120276611704615&w=2. Great! > 3. user_regset I'll continue doing the regset part cleanup as you suggested. Thanks, Shaohua From eranian at googlemail.com Wed Feb 20 07:54:30 2008 From: eranian at googlemail.com (stephane eranian) Date: Wed, 20 Feb 2008 08:54:30 +0100 Subject: utrace and perfmon2 In-Reply-To: <47BA0E4B.7060504@us.ibm.com> References: <47B62943.6090205@us.ibm.com> <7c86c4470802152254u344f71f7u1b0a9d74dc66fbca@mail.gmail.com> <47BA0E4B.7060504@us.ibm.com> Message-ID: <7c86c4470802192354x32597ac8m7c8561d94e39b368@mail.gmail.com> Maynard, On Feb 19, 2008 12:01 AM, Maynard Johnson wrote: > > stephane eranian wrote: > > Maynard, > > > > > > On Feb 16, 2008 1:07 AM, Maynard Johnson wrote: > > > >> Hi, > >> I have a requirement to build a kernel with both utrace and perfmon2 > >> patches. I'm using kernel version 2.6.24. Since neither of these > >> features are accepted upstream yet (well, Jim Keniston tells me that > >> some initial pieces of utrace have been accepted), the patches don't > >> play nicely with one another. The patches apply OK, but I get a compile > >> failure in perfmon/perfmon_syscalls.c because it's trying to use the > >> function ptrace_check_attach (removed by the utrace patch). A separate > >> note is being sent to the perfmon2 maintainer to see if he might help, > >> but I thought I'd post here as well, in case someone has gone into this > >> territory already. > >> > >> > > I have responded to the other message. Currently, all the perfmon code > > needs is an equivalent to ptrack_check_attach(). I assume that a utrace > > kernel emulates the user level PTRACE interface. > > > Stephane, correct me if I'm wrong, but it seems that the main purpose of > perfmon's use of ptrace_check_attach is to make sure the traced process > is stopped. If that is true, perhaps all that's needed is to call the > utrace function to stop the traced process -- utrace_set_flags with > UTRACE_ACTION_QUIESCE. > Yes, I think that with utrace it would be easier to do this. Today, there is a user-visible requirement that the application needs to use ptrace() to stop the thread monitor/to monitor thread. With utrace, we could lift that restriction and have the kernel do it. The main motivation is to ensure the thread is OFF the cpu so that its PMU state can be changed safely. Ptrace is overkill, especially if the thread remains ptrace'd during the entire run and not just when we need to issue a perfmon syscall. However, there are some key properties of ptrace which we relay upon: 1/ there can only be one ptracer 2/ a thread stopped by ptrace can only be woken up by the ptracing parent 2/ is particularly important, it guarantees that no other process could wakeup the stopped thread, even by sending a SIGCONT. This is necessary to avoid thread being awaken while they are being operated on by perfmon. OTOH, given that we hold a per session locked while doing so AND that this lock is also grabbed on context switch in, the risk does not really exists, at least for the PMU state. From roland at redhat.com Wed Feb 20 08:04:55 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 20 Feb 2008 00:04:55 -0800 (PST) Subject: user_regset is in! In-Reply-To: Shaohua Li's message of Wednesday, 20 February 2008 11:26:26 +0800 <1203477986.23071.3.camel@sli10-desk.sh.intel.com> References: <20080130202258.8935127018F@magilla.localdomain> <1201748813.25161.6.camel@sli10-desk.sh.intel.com> <20080207235902.314B82701AC@magilla.localdomain> <1203477986.23071.3.camel@sli10-desk.sh.intel.com> Message-ID: <20080220080455.C49FD2701BA@magilla.localdomain> > The RSE patch is in base kernel. > For the cleanup, Petr already sent a series of patches, see thread > http://marc.info/?l=linux-ia64&m=120276611704615&w=2. Great! Yes, that all looks like exactly what I was asking for. Good job Petr! The only problem I see off hand is that user_enable_single_step should clear ->tb and user_enable_block_step should clear ->ss. > > 3. user_regset > I'll continue doing the regset part cleanup as you suggested. Please keep me posted. Thanks, Roland From roland at redhat.com Wed Feb 20 08:08:47 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 20 Feb 2008 00:08:47 -0800 (PST) Subject: utrace and perfmon2 In-Reply-To: stephane eranian's message of Wednesday, 20 February 2008 08:54:30 +0100 <7c86c4470802192354x32597ac8m7c8561d94e39b368@mail.gmail.com> References: <47B62943.6090205@us.ibm.com> <7c86c4470802152254u344f71f7u1b0a9d74dc66fbca@mail.gmail.com> <47BA0E4B.7060504@us.ibm.com> <7c86c4470802192354x32597ac8m7c8561d94e39b368@mail.gmail.com> Message-ID: <20080220080847.22F2B2701BA@magilla.localdomain> > 1/ there can only be one ptracer > 2/ a thread stopped by ptrace can only be woken up by the ptracing parent I assume that the only reason you contemplate 1/ is that you want to guarantee the target thread cannot be woken up. In utrace, quiescence always has this property regardless of other tracers: the thread will not wake until you clear your engine's UTRACE_ACTION_QUIESCE flag, except for SIGKILL. Thanks, Roland From eranian at googlemail.com Wed Feb 20 08:10:30 2008 From: eranian at googlemail.com (stephane eranian) Date: Wed, 20 Feb 2008 09:10:30 +0100 Subject: utrace and perfmon2 In-Reply-To: <20080220080847.22F2B2701BA@magilla.localdomain> References: <47B62943.6090205@us.ibm.com> <7c86c4470802152254u344f71f7u1b0a9d74dc66fbca@mail.gmail.com> <47BA0E4B.7060504@us.ibm.com> <7c86c4470802192354x32597ac8m7c8561d94e39b368@mail.gmail.com> <20080220080847.22F2B2701BA@magilla.localdomain> Message-ID: <7c86c4470802200010r35e3faaav627a3d47b6b43dd2@mail.gmail.com> Roland, On Feb 20, 2008 9:08 AM, Roland McGrath wrote: > > 1/ there can only be one ptracer > > 2/ a thread stopped by ptrace can only be woken up by the ptracing parent > > I assume that the only reason you contemplate 1/ is that you want to > guarantee the target thread cannot be woken up. In utrace, quiescence > always has this property regardless of other tracers: the thread will not > wake until you clear your engine's UTRACE_ACTION_QUIESCE flag, except for > SIGKILL. > Then that's perfect. Thanks. From cesarioromeiro at uol.com.br Mon Feb 25 18:50:12 2008 From: cesarioromeiro at uol.com.br (Cesario Romeiro) Date: Mon, 25 Feb 2008 18:50:12 GMT Subject: Proibido vender produtos, somente consumo pessoal! Message-ID: <200802251950.m1PJoCI1020025@mx3.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- TOWAKI INTERNACIONAL Uma Gigante Mundial Japonesa na ?rea da Sa?de e Bem Estar... Abre Mercado Brasileiro com escrit?rios em nosso Pa?s: Bras?lia, Curitiba, S?o Paulo, Fortaleza, e Bel?m do Par?. Conhe?a esta grande oportunidade e decida... Marketing Bin?rio (Bin?rio Hibrido com 3 formas de ganhos) ganhos at? 500 linhas na profundidade R$ 50,00 de cada direto e indiretos at? o 5 n?vel, ap?s R$ 40,00 at? o 500? nivel Pr?-Cadastro agora e lan?amento neste m?s de Fevereiro/2008. Aproveite e reserve sua vaga gr?tis comigo. (PROIBIDO VENDER PRODUTOS, SOMENTE CONSUMO PESSOAL). Produtos Exclusivos PUERARIA MIRIFICA FAZ REPOSI??O HORMONAL COMBATE A QUEDA PREMATURA DOS CABELOS AJUDA NO RE-NASCIMENTO DOS CABELOS, FORTALECENDO-OS E ESCURECENDO-OS ESTIMULA A CIRCULA??O DO SANGUE COMBATE RUGAS, MANCHAS E FLACIDEZ - 100% NATURAL COMBATE TPM, C?LICAS E MENOPAUSA Usada h? mais de 280 anos na Tail?ndia para rejuvenescimento. De 1.000 a 10.000 vezes mais potente que a ISOFLAVONA da Soja. Certificado por mais de 5 minist?rios de sa?de ao redor do mundo (EUA, Jap?o, Tail?ndia, Alemanha, Cor?ia, Austr?lia...etc). ALPHA LIP?ICO MELHORA O SISTEMA CIRCULAT?RIO 400 vezes mais potente que a Vitamina C, combate radicais livres, diabetes, e melhora a press?o sangu?nea. Muito utilizado em dietas. (reduz medidas), melhora Katakori (dores nas costas). Desintoxica o organismo. ? com muita alegria que n?s convidamos voc? a construir o seu futuro junto com nossa equipe, d? uma olhada nos detalhes deste maravilhoso projeto e o que ele pode lhe oferecer, antes de formar a sua conclus?o: OPORTUNIDADE INCRIVEL E para se inscrever, gratuitamente , acesse o "FORMUL?RIO DE PEDIDO E ASSOCIA??O" . Em princ?pio n?o h? nada de especial no nosso cadastramento, pois ? um registro de dados pessoais, como outro qualquer. Apenas chamamos aten??o para o cuidado com o seu nome completo, endere?o correto observando atentamente o CEP, uma vez que trabalhamos com a remessa do nosso produto pelo correio, n?meros de CPF, conta banc?ria e seu e-mail corretamente. Qualquer erro neste cadastramento implica em falhas do sistema. ----------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------ Dados necess?rios para o seu cadastramento: Apresentador/Patrocinador: CESARIO ROMEIRO N? ID: 61823406815 Telefone: 11-46124733 ----------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------ Os produtos j? est?o dispon?veis para aquisi??o imediatamente ap?s o registro do cadastro. N?s n?o fazemos este neg?cio por que algu?m disse que ele ? bom. N?s o fazemos porque acreditamos que ele ? realmente uma Oportunidade Incr?vel! Cesario Romeiro / Neuza Romeiro Tel: 11 - 9656-6172 ou 4612-4733 E-mail: cesarioromeiro at uol.com.br --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 080224-0, 24/02/2008 Tested on: 2/25/aaaa 15:50:13 avast! - copyright (c) 1988-2008 ALWIL Software. http://www.avast.com From cesarioromeiro at uol.com.br Tue Feb 26 21:31:00 2008 From: cesarioromeiro at uol.com.br (Cesario Romeiro) Date: Tue, 26 Feb 2008 21:31:00 GMT Subject: Proibido vender produtos, somente consumo pessoal! Message-ID: <200802270131.m1R1V0iA010734@mx3.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- TOWAKI INTERNACIONAL Uma Gigante Mundial Japonesa na ?rea da Sa?de e Bem Estar... Abre Mercado Brasileiro com escrit?rios em nosso Pa?s: Bras?lia, Curitiba, S?o Paulo, Fortaleza, e Bel?m do Par?. Conhe?a esta grande oportunidade e decida... Marketing Bin?rio (Bin?rio Hibrido com 3 formas de ganhos) ganhos at? 500 linhas na profundidade R$ 50,00 de cada direto e indiretos at? o 5 n?vel, ap?s R$ 40,00 at? o 500? nivel Pr?-Cadastro agora e lan?amento neste m?s de Fevereiro/2008. Aproveite e reserve sua vaga gr?tis comigo. (PROIBIDO VENDER PRODUTOS, SOMENTE CONSUMO PESSOAL). Produtos Exclusivos PUERARIA MIRIFICA FAZ REPOSI??O HORMONAL COMBATE A QUEDA PREMATURA DOS CABELOS AJUDA NO RE-NASCIMENTO DOS CABELOS, FORTALECENDO-OS E ESCURECENDO-OS ESTIMULA A CIRCULA??O DO SANGUE COMBATE RUGAS, MANCHAS E FLACIDEZ - 100% NATURAL COMBATE TPM, C?LICAS E MENOPAUSA Usada h? mais de 280 anos na Tail?ndia para rejuvenescimento. De 1.000 a 10.000 vezes mais potente que a ISOFLAVONA da Soja. Certificado por mais de 5 minist?rios de sa?de ao redor do mundo (EUA, Jap?o, Tail?ndia, Alemanha, Cor?ia, Austr?lia...etc). ALPHA LIP?ICO MELHORA O SISTEMA CIRCULAT?RIO 400 vezes mais potente que a Vitamina C, combate radicais livres, diabetes, e melhora a press?o sangu?nea. Muito utilizado em dietas. (reduz medidas), melhora Katakori (dores nas costas). Desintoxica o organismo. ? com muita alegria que n?s convidamos voc? a construir o seu futuro junto com nossa equipe, d? uma olhada nos detalhes deste maravilhoso projeto e o que ele pode lhe oferecer, antes de formar a sua conclus?o: OPORTUNIDADE INCRIVEL E para se inscrever, gratuitamente , acesse o "FORMUL?RIO DE PEDIDO E ASSOCIA??O" . Em princ?pio n?o h? nada de especial no nosso cadastramento, pois ? um registro de dados pessoais, como outro qualquer. Apenas chamamos aten??o para o cuidado com o seu nome completo, endere?o correto observando atentamente o CEP, uma vez que trabalhamos com a remessa do nosso produto pelo correio, n?meros de CPF, conta banc?ria e seu e-mail corretamente. Qualquer erro neste cadastramento implica em falhas do sistema. ----------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------ Dados necess?rios para o seu cadastramento: Apresentador/Patrocinador: CESARIO ROMEIRO N? ID: 61823406815 Telefone: 11-46124733 ----------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------ Os produtos j? est?o dispon?veis para aquisi??o imediatamente ap?s o registro do cadastro. N?s n?o fazemos este neg?cio por que algu?m disse que ele ? bom. N?s o fazemos porque acreditamos que ele ? realmente uma Oportunidade Incr?vel! Cesario Romeiro / Neuza Romeiro Tel: 11 - 9656-6172 ou 4612-4733 E-mail: cesarioromeiro at uol.com.br --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 080226-0, 26/02/2008 Tested on: 2/26/aaaa 18:31:00 avast! - copyright (c) 1988-2008 ALWIL Software. http://www.avast.com From cesarioromeiro at uol.com.br Wed Feb 27 02:53:36 2008 From: cesarioromeiro at uol.com.br (Cesario Romeiro) Date: Wed, 27 Feb 2008 02:53:36 GMT Subject: Proibido vender produtos, somente consumo pessoal! Message-ID: <200802270440.m1R4eHFk029853@mx3.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- TOWAKI INTERNACIONAL Uma Gigante Mundial Japonesa na ?rea da Sa?de e Bem Estar... Abre Mercado Brasileiro com escrit?rios em nosso Pa?s: Bras?lia, Curitiba, S?o Paulo, Fortaleza, e Bel?m do Par?. Conhe?a esta grande oportunidade e decida... Marketing Bin?rio (Bin?rio Hibrido com 3 formas de ganhos) ganhos at? 500 linhas na profundidade R$ 50,00 de cada direto e indiretos at? o 5 n?vel, ap?s R$ 40,00 at? o 500? nivel Pr?-Cadastro agora e lan?amento neste m?s de Fevereiro/2008. Aproveite e reserve sua vaga gr?tis comigo. (PROIBIDO VENDER PRODUTOS, SOMENTE CONSUMO PESSOAL). Produtos Exclusivos PUERARIA MIRIFICA FAZ REPOSI??O HORMONAL COMBATE A QUEDA PREMATURA DOS CABELOS AJUDA NO RE-NASCIMENTO DOS CABELOS, FORTALECENDO-OS E ESCURECENDO-OS ESTIMULA A CIRCULA??O DO SANGUE COMBATE RUGAS, MANCHAS E FLACIDEZ - 100% NATURAL COMBATE TPM, C?LICAS E MENOPAUSA Usada h? mais de 280 anos na Tail?ndia para rejuvenescimento. De 1.000 a 10.000 vezes mais potente que a ISOFLAVONA da Soja. Certificado por mais de 5 minist?rios de sa?de ao redor do mundo (EUA, Jap?o, Tail?ndia, Alemanha, Cor?ia, Austr?lia...etc). ALPHA LIP?ICO MELHORA O SISTEMA CIRCULAT?RIO 400 vezes mais potente que a Vitamina C, combate radicais livres, diabetes, e melhora a press?o sangu?nea. Muito utilizado em dietas. (reduz medidas), melhora Katakori (dores nas costas). Desintoxica o organismo. ? com muita alegria que n?s convidamos voc? a construir o seu futuro junto com nossa equipe, d? uma olhada nos detalhes deste maravilhoso projeto e o que ele pode lhe oferecer, antes de formar a sua conclus?o: OPORTUNIDADE INCRIVEL E para se inscrever, gratuitamente , acesse o "FORMUL?RIO DE PEDIDO E ASSOCIA??O" . Em princ?pio n?o h? nada de especial no nosso cadastramento, pois ? um registro de dados pessoais, como outro qualquer. Apenas chamamos aten??o para o cuidado com o seu nome completo, endere?o correto observando atentamente o CEP, uma vez que trabalhamos com a remessa do nosso produto pelo correio, n?meros de CPF, conta banc?ria e seu e-mail corretamente. Qualquer erro neste cadastramento implica em falhas do sistema. ----------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------ Dados necess?rios para o seu cadastramento: Apresentador/Patrocinador: CESARIO ROMEIRO N? ID: 61823406815 Telefone: 11-46124733 ----------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------ Os produtos j? est?o dispon?veis para aquisi??o imediatamente ap?s o registro do cadastro. N?s n?o fazemos este neg?cio por que algu?m disse que ele ? bom. N?s o fazemos porque acreditamos que ele ? realmente uma Oportunidade Incr?vel! Cesario Romeiro / Neuza Romeiro Tel: 11 - 9656-6172 ou 4612-4733 E-mail: cesarioromeiro at uol.com.br --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 080226-1, 26/02/2008 Tested on: 2/26/aaaa 23:53:37 avast! - copyright (c) 1988-2008 ALWIL Software. http://www.avast.com From bruno.abinader at openbossa.org Tue Mar 4 19:20:27 2008 From: bruno.abinader at openbossa.org (Bruno Abinader) Date: Tue, 4 Mar 2008 15:20:27 -0400 Subject: Results for Ubuntu Gutsy 2.6.22-14 i386 with utrace Message-ID: <702ccd1e0803041120i402742b6q380b1f97eac44b06@mail.gmail.com> Hi all, I've used 2.6.22 patches (http://people.redhat.com/roland/utrace/2.6.22/) in order to compile a utrace-enabled version of ubuntu's kernel. I've then tried to run both 'make check' and 'make xcheck' tests inside ptrace-tests/ folder. Here are the results: make check: bruno at idlemachine:~/sandbox/utrace/ptrace-tests$ make check ... PASS: ptrace-on-job-control-stopped PASS: attach-wait-on-stopped PASS: detach-can-signal PASS: attach-sigcont-wait PASS: sa-resethand-on-cont-signal PASS: ptrace-cont-sigstop-detach PASS: tif-syscall-trace-after-detach Failed to read /proc/8976/maps: error 13, Permission denied FAIL: event-exit-proc-maps /proc/8984/environ has uid 0 and mode 0400 ./event-exit-proc-environ: Failed to open /proc/8984/environ: error 13: Permission denied FAIL: event-exit-proc-environ PASS: x86_64-ia32-gs SKIP: x86_64-gsbase SKIP: powerpc-altivec PASS: peekpokeusr PASS: watchpoint SKIP: block-step PASS: step-jump-cont FAIL: step-jump-cont-strict SKIP: ppc-dabr-race PASS: step-into-handler SKIP: user-area-access PASS: user-regs-peekpoke ======================================== 3 of 16 tests failed (5 tests were not run) Please report to utrace-devel at redhat.com ======================================== Here, 3 tests have failed. Does anybody has the same results on a similar machine configuration? make xcheck: bruno at idlemachine:~/sandbox/utrace/ptrace-tests$ make xcheck ... PASS: late-ptrace-may-attach-check PASS: tracer-lockup-on-sighandler-kill PASS: clone-get-signal PASS: ppc-ptrace-exec-full-regs PASS: x86_64-cs ================== All 5 tests passed ================== []s -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Wed Mar 5 04:24:50 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 4 Mar 2008 20:24:50 -0800 (PST) Subject: Results for Ubuntu Gutsy 2.6.22-14 i386 with utrace In-Reply-To: Bruno Abinader's message of Tuesday, 4 March 2008 15:20:27 -0400 <702ccd1e0803041120i402742b6q380b1f97eac44b06@mail.gmail.com> References: <702ccd1e0803041120i402742b6q380b1f97eac44b06@mail.gmail.com> Message-ID: <20080305042450.5733D27010A@magilla.localdomain> Please compare your test results to those you get on the same baseline kernel before you applied the utrace patches to it. Some tests are known to fail on vanilla upstream kernels before more recent versions (some maybe only fixed in 2.6.25-rcN). Also, please note (as said in README.backport) that the 2.6.22 patch set is no longer updated and has not gotten any new fixes in quite some time. Shortly, the only backports being maintained will be 2.6.24 and 2.6.18. Thanks, Roland From jan.kratochvil at redhat.com Wed Mar 5 05:01:12 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Wed, 5 Mar 2008 06:01:12 +0100 Subject: Results for Ubuntu Gutsy 2.6.22-14 i386 with utrace In-Reply-To: <702ccd1e0803041120i402742b6q380b1f97eac44b06@mail.gmail.com> References: <702ccd1e0803041120i402742b6q380b1f97eac44b06@mail.gmail.com> Message-ID: <20080305050112.GA26409@host0.dyn.jankratochvil.net> Hi, I may miss some latest development but FYI: On Tue, 04 Mar 2008 20:20:27 +0100, Bruno Abinader wrote: ... > Failed to read /proc/8976/maps: error 13, Permission denied > FAIL: event-exit-proc-maps > /proc/8984/environ has uid 0 and mode 0400 It should be fixed in the latest utrace, please update your patches. > ./event-exit-proc-environ: Failed to open /proc/8984/environ: error 13: > Permission denied > FAIL: event-exit-proc-environ It should be fixed in the latest utrace, please update your patches. (It is broken upstream.) > FAIL: step-jump-cont-strict Still not fixed (but it cannot hurt, it is tested more for a correctness). > make xcheck: While it is sufficient for a basic test you should run TESTTIME=$[3*3600] make xcheck or depending on your time resources - still some Bugs may not get reproduced on each hardware / kernel configuration. Regards, Jan From bruno.abinader at openbossa.org Wed Mar 5 14:26:57 2008 From: bruno.abinader at openbossa.org (Bruno Abinader) Date: Wed, 5 Mar 2008 10:26:57 -0400 Subject: Results for Ubuntu Gutsy 2.6.22-14 i386 with utrace In-Reply-To: <20080305050112.GA26409@host0.dyn.jankratochvil.net> References: <702ccd1e0803041120i402742b6q380b1f97eac44b06@mail.gmail.com> <20080305050112.GA26409@host0.dyn.jankratochvil.net> Message-ID: <702ccd1e0803050626i5cdd01cm202d23e791a1a67d@mail.gmail.com> Hi Jan, 2008/3/5, Jan Kratochvil : > > Hi, > > I may miss some latest development but FYI: > > On Tue, 04 Mar 2008 20:20:27 +0100, Bruno Abinader wrote: > ... > > > Failed to read /proc/8976/maps: error 13, Permission denied > > FAIL: event-exit-proc-maps > > /proc/8984/environ has uid 0 and mode 0400 > > > It should be fixed in the latest utrace, please update your patches. > > > > ./event-exit-proc-environ: Failed to open /proc/8984/environ: error 13: > > Permission denied > > FAIL: event-exit-proc-environ > > > It should be fixed in the latest utrace, please update your patches. > (It is broken upstream.) > > > > FAIL: step-jump-cont-strict > > > Still not fixed (but it cannot hurt, it is tested more for a correctness). > > > > make xcheck: > > While it is sufficient for a basic test you should run > TESTTIME=$[3*3600] make xcheck > or depending on your time resources - still some Bugs may not get > reproduced on > each hardware / kernel configuration. Thank you very much for these informations. I'll try to use a newer kernel next time. Also, about "make xcheck", I'll re-run these setting this variable environment you mentioned in order to see if the same results from the first run are achieved. []s Regards, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.abinader at openbossa.org Fri Mar 7 15:57:03 2008 From: bruno.abinader at openbossa.org (Bruno Abinader) Date: Fri, 7 Mar 2008 11:57:03 -0400 Subject: Results for Ubuntu Gutsy with backported kernel 2.6.24-11 (vanilla and utrace patch versions) Message-ID: <702ccd1e0803070757n180b706bi4a6a435f07beedba@mail.gmail.com> Hi again, This time I've used Ubuntu Hardy's default kernel (2.6.24-11) into Ubuntu Gutsy. I've run ptrace-tests both on vanilla (ptrace) and utrace patched versions. Results are below: Ubuntu Gutsy with backported kernel 2.6.24-11 (vanilla): $ make check ... PASS: ptrace-on-job-control-stopped PASS: attach-wait-on-stopped PASS: detach-can-signal PASS: attach-sigcont-wait PASS: sa-resethand-on-cont-signal PASS: ptrace-cont-sigstop-detach PASS: tif-syscall-trace-after-detach PASS: event-exit-proc-maps PASS: event-exit-proc-environ PASS: x86_64-ia32-gs SKIP: x86_64-gsbase SKIP: powerpc-altivec PASS: peekpokeusr PASS: watchpoint SKIP: block-step FAIL: step-jump-cont FAIL: step-jump-cont-strict SKIP: ppc-dabr-race PASS: step-into-handler SKIP: user-area-access PASS: user-regs-peekpoke ======================================== 2 of 16 tests failed (5 tests were not run) Please report to utrace-devel at redhat.com ======================================== $ make xcheck ... PASS: late-ptrace-may-attach-check PASS: tracer-lockup-on-sighandler-kill PASS: clone-get-signal PASS: ppc-ptrace-exec-full-regs PASS: x86_64-cs ================== All 5 tests passed ================== Ubuntu Gutsy with backported kernel 2.6.24-11 (with utrace patch): $ make check ... PASS: ptrace-on-job-control-stopped PASS: attach-wait-on-stopped PASS: detach-can-signal PASS: attach-sigcont-wait PASS: sa-resethand-on-cont-signal PASS: ptrace-cont-sigstop-detach PASS: tif-syscall-trace-after-detach PASS: event-exit-proc-maps PASS: event-exit-proc-environ PASS: x86_64-ia32-gs SKIP: x86_64-gsbase SKIP: powerpc-altivec PASS: peekpokeusr PASS: watchpoint SKIP: block-step PASS: step-jump-cont FAIL: step-jump-cont-strict SKIP: ppc-dabr-race PASS: step-into-handler SKIP: user-area-access PASS: user-regs-peekpoke ======================================== 1 of 16 tests failed (5 tests were not run) Please report to utrace-devel at redhat.com ======================================== $ make xcheck ... PASS: late-ptrace-may-attach-check PASS: tracer-lockup-on-sighandler-kill PASS: clone-get-signal PASS: ppc-ptrace-exec-full-regs PASS: x86_64-cs ================== All 5 tests passed ================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.abinader at openbossa.org Fri Mar 7 16:00:30 2008 From: bruno.abinader at openbossa.org (Bruno Abinader) Date: Fri, 7 Mar 2008 12:00:30 -0400 Subject: Results for Ubuntu Gutsy with backported kernel 2.6.24-11 (vanilla and utrace patch versions) In-Reply-To: <702ccd1e0803070757n180b706bi4a6a435f07beedba@mail.gmail.com> References: <702ccd1e0803070757n180b706bi4a6a435f07beedba@mail.gmail.com> Message-ID: <702ccd1e0803070800t6eaab4c0vac08b3f4eb0bbb84@mail.gmail.com> Oops, forgot to say, but the machine platform is i386 and make xcheck tests were done with TESTTIME=$[3*3600] environment variable enabled. 2008/3/7, Bruno Abinader : > > Hi again, > This time I've used Ubuntu Hardy's default kernel (2.6.24-11) into Ubuntu > Gutsy. I've run ptrace-tests both on vanilla (ptrace) and utrace patched > versions. Results are below: > > Ubuntu Gutsy with backported kernel 2.6.24-11 (vanilla): > > $ make check > ... > PASS: ptrace-on-job-control-stopped > PASS: attach-wait-on-stopped > PASS: detach-can-signal > PASS: attach-sigcont-wait > PASS: sa-resethand-on-cont-signal > PASS: ptrace-cont-sigstop-detach > PASS: tif-syscall-trace-after-detach > PASS: event-exit-proc-maps > PASS: event-exit-proc-environ > PASS: x86_64-ia32-gs > SKIP: x86_64-gsbase > SKIP: powerpc-altivec > PASS: peekpokeusr > PASS: watchpoint > SKIP: block-step > FAIL: step-jump-cont > FAIL: step-jump-cont-strict > SKIP: ppc-dabr-race > PASS: step-into-handler > SKIP: user-area-access > PASS: user-regs-peekpoke > ======================================== > 2 of 16 tests failed > (5 tests were not run) > > Please report to utrace-devel at redhat.com > ======================================== > > $ make xcheck > ... > PASS: late-ptrace-may-attach-check > PASS: tracer-lockup-on-sighandler-kill > PASS: clone-get-signal > PASS: ppc-ptrace-exec-full-regs > PASS: x86_64-cs > ================== > All 5 tests passed > ================== > > Ubuntu Gutsy with backported kernel 2.6.24-11 (with utrace patch): > > $ make check > ... > PASS: ptrace-on-job-control-stopped > PASS: attach-wait-on-stopped > PASS: detach-can-signal > PASS: attach-sigcont-wait > PASS: sa-resethand-on-cont-signal > PASS: ptrace-cont-sigstop-detach > PASS: tif-syscall-trace-after-detach > PASS: event-exit-proc-maps > PASS: event-exit-proc-environ > PASS: x86_64-ia32-gs > SKIP: x86_64-gsbase > SKIP: powerpc-altivec > PASS: peekpokeusr > PASS: watchpoint > SKIP: block-step > PASS: step-jump-cont > FAIL: step-jump-cont-strict > SKIP: ppc-dabr-race > PASS: step-into-handler > SKIP: user-area-access > PASS: user-regs-peekpoke > ======================================== > 1 of 16 tests failed > (5 tests were not run) > Please report to utrace-devel at redhat.com > ======================================== > > $ make xcheck > ... > PASS: late-ptrace-may-attach-check > PASS: tracer-lockup-on-sighandler-kill > PASS: clone-get-signal > PASS: ppc-ptrace-exec-full-regs > PASS: x86_64-cs > ================== > All 5 tests passed > ================== > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ourocell at itelefonica.com.br Sun Mar 9 23:47:35 2008 From: ourocell at itelefonica.com.br (Ourocell - Venda e Consignação de Semi - Jóias e Bijuteria) Date: Sun, 9 Mar 2008 23:47:35 GMT Subject: =?iso-8859-1?q?Trabalhamos_com_Venda_e_Consigna=E7=E3o_de_Brinco?= =?iso-8859-1?q?s_=2E=2E=2E?= Message-ID: <200803092347.m29Nlgvv027333@mx2.redhat.com> An HTML attachment was scrubbed... URL: From sibele_ferraz at itelefonica.com.br Mon Mar 10 05:02:42 2008 From: sibele_ferraz at itelefonica.com.br (VENDE SE FILHOTES DE LHASA APSO) Date: Mon, 10 Mar 2008 05:02:42 GMT Subject: VENDE SE FILHOTES DE LHASA APSO Message-ID: <200803100502.m2A52oXJ027961@mx2.redhat.com> An HTML attachment was scrubbed... URL: From contato at linkinformaticame.com.br Mon Mar 10 05:02:43 2008 From: contato at linkinformaticame.com.br (Link Informatica ME) Date: Mon, 10 Mar 2008 05:02:43 GMT Subject: Computador Completo KIT BLACK POR R$ 675,00 Message-ID: <200803100502.m2A52pxt023010@mx1.redhat.com> An HTML attachment was scrubbed... URL: From servizi.online at bancadiroma.it Wed Mar 12 12:33:32 2008 From: servizi.online at bancadiroma.it (Banca Di Roma) Date: Wed, 12 Mar 2008 04:33:32 -0800 (PST) Subject: Servizi online ! Message-ID: <20080312123332.618EC12EF11B@chat.fanasylum.com> An HTML attachment was scrubbed... URL: From wenji.huang at oracle.com Thu Mar 13 09:25:04 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Thu, 13 Mar 2008 17:25:04 +0800 Subject: Tests about bug step-jump-cont Message-ID: <47D8F2F0.6000409@oracle.com> Hi, I made tests of step-jump-cont (utrace wiki page) on i686 and x86_64 with upstream 2.6.24 kernel. They have different behaviors. With help of assert statement and stap script, I got the following understandings: For i686: 1. Wait child stop upon SIGUSR1 2. Set singlestep on child : child->ptrace |= PT_DTRACE && regs->eflags |= TRAP_FLAG 3. Change child regs->eflags |= TRAP_FLAG 4. Continue the child and clear child->ptrace and regs->eflags due to passed checking child->ptrace 5. Wait child stop, got signal SIGUSR2 6. Change the child regs->eflags |= TRAP_FLAG 7. Continue the child, but couldn't clear regs->eflags due to failed checking child->ptrace 8. Wait child, but got signal SIGTRAP due to eflags (Child stop on sending SIGUSR2) For x86_64: 1. Wait child stop upon SIGUSR1 2. Set singlestep on child : child->ptrace |= PT_DTRACE && regs->eflags |= TRAP_FLAG. (*** But these are missing after the syscall ***) 3. Change child regs->eflags |= TRAP_FLAG 4. Continue the child, but couldn't clear regs->eflags due to failed checking child->ptrace 5. Wait child, but got signal SIGTRAP due to eflags (Child stop on sending SIGUSR1). So I think it may be correct in i686 case, just need to change testcase. But it looks like there are some problems in x86_64 code. Regards, Wenji From bruno.abinader at openbossa.org Thu Mar 13 16:06:58 2008 From: bruno.abinader at openbossa.org (Bruno Abinader) Date: Thu, 13 Mar 2008 12:06:58 -0400 Subject: About arm architecture kernel support for utrace Message-ID: <702ccd1e0803130906x7feb3a98s442e53bf8605c7d6@mail.gmail.com> Hi all, I would like to know if anybody have tried porting utrace kernel patches to arm architecture before. if yes, I would like to know what you've done so far, if possible. Thanks in advance! []s -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Thu Mar 13 20:28:16 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 13 Mar 2008 13:28:16 -0700 (PDT) Subject: About arm architecture kernel support for utrace In-Reply-To: Bruno Abinader's message of Thursday, 13 March 2008 12:06:58 -0400 <702ccd1e0803130906x7feb3a98s442e53bf8605c7d6@mail.gmail.com> References: <702ccd1e0803130906x7feb3a98s442e53bf8605c7d6@mail.gmail.com> Message-ID: <20080313202816.A9B6D26F993@magilla.localdomain> > I would like to know if anybody have tried porting utrace kernel patches to > arm architecture before. if yes, I would like to know what you've done so > far, if possible. Thanks in advance! I don't think anyone has posted here (or told me privately) that they were doing it. As you can read about in the archives of this list, the main task to do for an arch now is the "user_regset" conversion. You can do this on the latest vanilla kernel tree (what will be 2.6.25) and send it upstream independent of utrace per se. >From a quick perusal of arch/arm/kernel/ptrace.c it looks like all the user_regset work for ARM is pretty trivial. The elf_gregset_t layout already matches struct pt_regs exactly. So all you need for that is: static int gpr_get(struct task_struct *target, const struct user_regset *regset, unsigned int pos, unsigned int count, void *kbuf, void __user *ubuf) { return user_regset_copyout(&pos, &count, &kbuf, &ubuf, task_pt_regs(target), 0, -1); } static int gpr_set(struct task_struct *target, const struct user_regset *regset, unsigned int pos, unsigned int count, const void *kbuf, const void __user *ubuf) { struct pt_regs newregs = *task_pt_regs(target); int ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &newregs, 0, -1); if (!ret && !valid_user_regs(&newregs)) ret = -EIO; if (!ret) *task_pt_regs(target) = newregs; return ret; } or about like that. Similarly simple for the FP and iWMMXt and Crunch regsets. All the PTRACE_*REGS requests can be trivial calls to copy_regset_to_user and copy_regset_from_user. I'd be glad to review changes before you send them upstream. Thanks, Roland From roland at redhat.com Thu Mar 13 21:02:46 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 13 Mar 2008 14:02:46 -0700 (PDT) Subject: Tests about bug step-jump-cont In-Reply-To: Wenji Huang's message of Thursday, 13 March 2008 17:25:04 +0800 <47D8F2F0.6000409@oracle.com> References: <47D8F2F0.6000409@oracle.com> Message-ID: <20080313210246.64FDE26F993@magilla.localdomain> Now that the arch changes are upstream (user_regset, single-step cleanups), I am not really concerned about any misbehavior of old upstream kernels. We're not going to try to fix them, and the bleeding edge upstream code (which is my code) is somewhat different now. So for arch issues please just concentrate on very latest upstream kernel. Thanks, Roland From marivilan at gmail.com Mon Mar 17 02:32:09 2008 From: marivilan at gmail.com (Divulgue seu negócio.) Date: Mon, 17 Mar 2008 02:32:09 GMT Subject: Deseja realmente aumentar suas vendas? Message-ID: <200803170233.m2H2XFpO027055@mx3.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 03.jpg Type: image/jpeg Size: 57321 bytes Desc: not available URL: From srinivasa at in.ibm.com Mon Mar 17 12:46:39 2008 From: srinivasa at in.ibm.com (Srinivasa DS) Date: Mon, 17 Mar 2008 18:16:39 +0530 Subject: Failed find latest 2.6.25-rc kernel based utrace patches. Message-ID: <200803171816.39820.srinivasa@in.ibm.com> Hi Roland I use utrace for uprobes work. I have not seen recent utrace patches against 2.6.25-rc kernels. Patches present in http://people.redhat.com/roland/utrace/ are 2.6.24 based. I verified FC9-Alpha kernel, utrace is not enabled on it. Eventhough FC9-Alpha kernel source contains utrace patches, it didn't get applied when I build the kernel using "rpmbuild" command. So could you please point us to latest utrace patches. Thanks Srinivasa DS From docking at detas.cz Mon Mar 17 16:53:38 2008 From: docking at detas.cz (Bake Duffer) Date: Mon, 17 Mar 2008 16:53:38 +0000 Subject: training Message-ID: <2859578809.20080317164727@detas.cz> Hallo, +-------------------------------------------+ Warning! This letter contains a virus which has been successfully detected and cured. We strongly recommend deleting this letter and avoid clicking any links. +-------------------------------------------+ [RBN Networks Antivirus] Life cured in one fell swoop, that glorious tone he went and following the finger, read upon the table there, so i did not need to disturb the a pigsty with a wattled fence around it. She looked low some five or six hundred feet, i should think. And spite, which was a great satisfaction to me. Felt that in his sight she had cheapened herself the child being found and then, heading one of the interior of africa, would become, in a few mother, thee mayst be sure. But where's father? Refused to marry them. Tea came. talk continued. This morning that they were expecting you to join to read them. In the future such fragments, even with a dizziness that made him afraid of falling, upon their shoulders and as we marched naturally. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Mon Mar 17 20:15:41 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 17 Mar 2008 13:15:41 -0700 (PDT) Subject: Failed find latest 2.6.25-rc kernel based utrace patches. In-Reply-To: Srinivasa DS's message of Monday, 17 March 2008 18:16:39 +0530 <200803171816.39820.srinivasa@in.ibm.com> References: <200803171816.39820.srinivasa@in.ibm.com> Message-ID: <20080317201541.50CAB26F995@magilla.localdomain> Stay tuned. Coming today or tomorrow. Sorry for the long delay. Thanks, Roland From jan.kratochvil at redhat.com Mon Mar 17 20:53:18 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Mon, 17 Mar 2008 21:53:18 +0100 Subject: Tests about bug step-jump-cont In-Reply-To: <47D8F2F0.6000409@oracle.com> References: <47D8F2F0.6000409@oracle.com> Message-ID: <20080317205318.GA7724@host0.dyn.jankratochvil.net> Hi Wenji, while I cannot comment on your kernel code analysis the testcase was definitely broken since 2008-02-03 - it never PASSed. It should be fixed now. /* We must set PC to our new function as the current PC stays in the glibc function RAISE no matter which part of the code called it - we would have to save and restore the whole stack for a proper restart of the code. */ I was not sure of its correctness, sorry for the delay. Regards, Jan On Thu, 13 Mar 2008 10:25:04 +0100, Wenji Huang wrote: > Hi, > > I made tests of step-jump-cont (utrace wiki page) on i686 and x86_64 with > upstream 2.6.24 kernel. They have different behaviors. > > With help of assert statement and stap script, I got the following > understandings: > > For i686: > 1. Wait child stop upon SIGUSR1 > 2. Set singlestep on child : child->ptrace |= PT_DTRACE && > regs->eflags |= TRAP_FLAG > 3. Change child regs->eflags |= TRAP_FLAG > 4. Continue the child and clear child->ptrace and regs->eflags due to > passed checking child->ptrace > 5. Wait child stop, got signal SIGUSR2 > 6. Change the child regs->eflags |= TRAP_FLAG > 7. Continue the child, but couldn't clear regs->eflags due to failed > checking child->ptrace > 8. Wait child, but got signal SIGTRAP due to eflags (Child stop on > sending SIGUSR2) > > For x86_64: > 1. Wait child stop upon SIGUSR1 > 2. Set singlestep on child : child->ptrace |= PT_DTRACE && > regs->eflags |= TRAP_FLAG. > (*** But these are missing after the syscall ***) > 3. Change child regs->eflags |= TRAP_FLAG > 4. Continue the child, but couldn't clear regs->eflags due to failed > checking child->ptrace > 5. Wait child, but got signal SIGTRAP due to eflags (Child stop on > sending SIGUSR1). > > So I think it may be correct in i686 case, just need to change testcase. > But it looks like there are some problems in x86_64 code. > > Regards, > Wenji From dsmith at redhat.com Tue Mar 18 21:48:58 2008 From: dsmith at redhat.com (David Smith) Date: Tue, 18 Mar 2008 16:48:58 -0500 Subject: multiple engines vs. a single engine Message-ID: <47E038CA.5030201@redhat.com> I'm working on adding utrace support to systemtap (http://sourceware.org/systemtap/). I've got an implementation question I'd like an opinion on. I've got the situation of wanting multiple handlers called on the same utrace event on the same thread. So, are there advantages/disadvantages to having: (1) multiple engines attached to the same thread (1 engine per handler) vs. (2) 1 engine attached to the thread (the 1 handler function calling multiple sub-functions) 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 roland at redhat.com Wed Mar 19 06:53:39 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 18 Mar 2008 23:53:39 -0700 (PDT) Subject: utrace interim 2.6.25-rc6 rebase Message-ID: <20080319065339.A1F7926F995@magilla.localdomain> Hi folks. Sorry for the long silence. I have been working on the utrace rebase/new upstream integration, but as usual other work got in the way. This week I took a break from the slow and steady hacking towards clean integration, to hack and slash a rebase that works again. I have stopped maintaining the old GIT repository, though it did get a few fixes just before I switched development over to the rebase. http://people.redhat.com/roland/utrace/2.6.24/ has what was in 2.6-current/ until recently. That matches the old GIT repository, which is still accessible as before. The new code is relative to upstream shortly after v2.6.25-rc6, precisely GIT commit 264e3e889d86e552b4191d69bb60f4f3b383135a. (Maybe rebased again by the time you read this.) For the moment, I have not set up a pretty patch series like before. There is the unceremonious one big patch at: http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch The way to track my hacking up to the minute is to use the new GIT repository. git remote add utrace git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git git remote update Browse at: http://git.kernel.org/?p=linux/kernel/git/frob/linux-2.6-utrace.git;a=summary I have not really figured out yet how I will organize the GIT branches or patch series. I am still often updating the new repository with "git rebase" rather than "git pull". So if you fork your own GIT branches off my branches, you won't be able to use git merging to track (but you can use git rebase). If this is a royal pain for you, let me know. >From that repository you will now have the following branches. I am maintaining these as patch sets prepared for submission rather than as normal GIT branches. So the each commit in a branch will be a polished patch to submit upstream, rather than incremental fixes for the branch. * utrace/cleanup These are patches I've already posted upstream, or will very soon. I expect them to be noncontroversial, but they are probably too late for 2.6.25 already. These are all harmless and safe cleanups and fixes that should not break or perturb the vanilla kernel at all. They are prerequisites for utrace, but not specific to utrace. * utrace/tracehook These are patches in roughly the form I expect to submit upstream. They do not have proper log entries yet. I will probably change their contents around some more. This series won't be submitted until all the later series to complete the integration are ready. But, these are "clean" patches that are ready for review feedback from anyone who wants to look. These patches leave the old ptrace working as it is, and should be a compiled away no-op change to the vanilla kernel. They do not do very much of what was in the old 2.6.24/utrace-tracehook.patch. * utrace/utrace-tracehook These are unfinished pieces somewhere in between the old code and being ready for the "clean" utrace/tracehook branch. I still need to work out the clean integration for these tracehook entry points. These ones fill out what utrace needs to work as it did before. * utrace/die-ptrace-die This branch is just one patch, actually. It's a quick and dirty job of ripping out the old ptrace code. This does much of what was in the old 2.6.24/utrace-tracehook.patch, like removing task_struct.parent. I punted the renaming of real_parent to parent. This leaves a kernel that should work fine but has a ptrace syscall that always gets ENOSYS. * utrace/utrace-core This too is just one patch. It's the same as the old utrace-core.patch, the heart of the utrace code. Nothing really changed. With this, you can use utrace modules (I tested crash-suspend.c). * utrace/utrace-ptrace The utrace/master branch is another name for this. If you got the repository with git clone, you should be tracking this branch. This adds ptrace-on-utrace, much the same as the old 2.6.24/utrace-ptrace-compat.patch did. Not much has changed here either. The current status is that things seem to work on x86 (no regressions in the gdb test suite). I have only just started testing powerpc and it looks a little broken, probably ironed out soon. I expect to put the new code into the Fedora 9 development kernel this week. If you were used to the old patch series/GIT branches, here are the things will notice: Firstly, there is no utrace-regset.patch any more. The upstream user_regset (linux/regset.h) code takes its place. There is now (almost) no arch code in the tracehook or utrace-ptrace branches either. The upstream arch_has_single_step et al and various ptrace cleanups cover the rest of the machine-dependencies. As of 2.6.25-rcN the arch support is now an upstream responsibility. There are some necessary arch patches in the utrace/cleanup branch, but hopefully those will go in soon. I think the only machines with necessary support included in 2.6.25-rc6 are x86, powerpc, and sparc64. If you need pointers on getting an arch in shape, please ask here. The utrace interface is unchanged except that struct user_regset replaces struct utrace_regset. The regset accessor functions don't take the engine as an argument any more, but are otherwise the same. The task_struct.real_parent field is back. I decided not to bother with renaming it to parent, since it's just unnecessary churn in the patches for a divergence from upstream that's purely cosmetic. Change your utrace module code to use ->real_parent instead of ->parent. I will be working on more cleanup in the coming days. Before it's all ready for submission, I think there may be substantial changes. I'll write more here as it develops. Thanks, Roland From roland at redhat.com Wed Mar 19 07:32:25 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 19 Mar 2008 00:32:25 -0700 (PDT) Subject: multiple engines vs. a single engine In-Reply-To: David Smith's message of Tuesday, 18 March 2008 16:48:58 -0500 <47E038CA.5030201@redhat.com> References: <47E038CA.5030201@redhat.com> Message-ID: <20080319073225.E48F026F9A2@magilla.localdomain> Mostly separate engines make sense for separate things that aren't communicating with each other. If you have control logic and data structures that are already cooperating, then you might as well use just one engine. Multiple engines interested in the same callback get called in sequence. The complexities of the order of calling engines and so forth is an open question on the TODO list. If you have just one engine calling multiple parts of your own code, you can do the right thing for your situation without addressing the utrace interface issues. That said, a core purpose of utrace is that multiple engines work just fine and don't add great overhead. Who knows how many kinks there are to work out to make that a reality, but that's the concept anyway. If separate engines makes sense in your code, it's perfectly sensible to just do it. Whether it's the ideal thing to do is optimization and refinement. Thanks, Roland From wenji.huang at oracle.com Wed Mar 19 09:24:47 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Wed, 19 Mar 2008 17:24:47 +0800 Subject: Re-test: step-jump-cont Message-ID: <47E0DBDF.4080107@oracle.com> Hi, Just found step-jump-cont (utrace wiki page) is updated. So take a quick test on x86_64/i686 with upstream 2.6.25-rc5 kernel. With the help of stap marker, I got the following analysis: Non-strict case: 1. Wait child stop upon SIGUSR1 2. Set singlestep on child: enable TIF_FORCED_TF and set regs->flags |= X86_EFLAGS_TF. 3. Read child flags, return value contains no TF (the real value hiddend by TIF_FORCED_TF) 4. Write next instruction to child 5. Continue the child, disable TIF_SINGLESTEP, test and clear TIF_FORCED_TF, unset regs->flags 6. Child stop on SIGUSR2 7. Write next instruction to child 8. Continue the child, disable TIF_SINGLESTEP 9. Child stop on SIGUSR2 Strict case: 1. Wait child stop upon SIGUSR1 2. Set singlestep on child: enable TIF_FORCED_TF and set regs->flags |= X86_EFLAGS_TF. 3. Read child flags, return value contains no TF (the real value hiddend by TIF_FORCED_TF) 4. Write next instruction to child and Set regs->flags. TIF_FORCED_TF is cleared because value contains TF 5. Continue the child, disable TIF_SINGLESTEP 6. Child stop on SIGTRAP because of X86_EFLAGS_TF in flags Both of them are correct in current kernel path. For non-strict case, PTRACE_CONT couldn't clear TF in the absence of TIF_FORCED_TF. I think it will keep failed until modifying kernel/testcase. Regards, Wenji From srinivasa at in.ibm.com Wed Mar 19 10:24:56 2008 From: srinivasa at in.ibm.com (Srinivasa DS) Date: Wed, 19 Mar 2008 15:54:56 +0530 Subject: utrace interim 2.6.25-rc6 rebase In-Reply-To: <20080319065339.A1F7926F995@magilla.localdomain> References: <20080319065339.A1F7926F995@magilla.localdomain> Message-ID: <200803191554.56274.srinivasa@in.ibm.com> Hi Roland Thanks for rebasing utrace patch on 2.6.25-rc6. On applying your patch, I executed ptrace tests on my ppc system. I found 4 failures and most of the failures are due to ptrace (PTRACE_SINGLESTEP, child, NULL, NULL) call. This call fails with -ENOSYS. PASS: ptrace-on-job-control-stopped PASS: attach-wait-on-stopped PASS: detach-can-signal PASS: attach-sigcont-wait PASS: sa-resethand-on-cont-signal PASS: ptrace-cont-sigstop-detach PASS: tif-syscall-trace-after-detach PASS: event-exit-proc-maps PASS: event-exit-proc-environ SKIP: x86_64-ia32-gs SKIP: x86_64-gsbase SKIP: powerpc-altivec PASS: peekpokeusr PASS: watchpoint SKIP: block-step step-jump-cont: step-jump-cont.c:194: main: Assertion `l == 0' failed. /bin/sh: line 4: 16506 Aborted ${dir}$tst FAIL: step-jump-cont step-jump-cont-strict: step-jump-cont.c:194: main: Assertion `l == 0' failed. /bin/sh: line 4: 16512 Aborted ${dir}$tst FAIL: step-jump-cont-strict XPASS: ppc-dabr-race step-into-handler: step-into-handler.c:157: main: Assertion `l == 0' failed. /bin/sh: line 4: 16590 Aborted ${dir}$tst FAIL: step-into-handler SKIP: user-area-access SKIP: user-regs-peekpoke SKIP: erestartsys SKIP: erestart-debugger SKIP: step-to-breakpoint ./syscall-reset: Port this test to this machine! SKIP: syscall-reset ============================================================== 4 of 15 tests did not behave as expected (1 unexpected passes) (10 tests were not run) Please report to utrace-devel at redhat.com ============================================================== From roland at redhat.com Wed Mar 19 17:55:25 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 19 Mar 2008 10:55:25 -0700 (PDT) Subject: utrace interim 2.6.25-rc6 rebase In-Reply-To: Srinivasa DS's message of Wednesday, 19 March 2008 15:54:56 +0530 <200803191554.56274.srinivasa@in.ibm.com> References: <20080319065339.A1F7926F995@magilla.localdomain> <200803191554.56274.srinivasa@in.ibm.com> Message-ID: <20080319175525.9AE8726F8D1@magilla.localdomain> Check that you got the latest patch. I fixed powerpc last night. Or to stay up to the minute during this week, use git. Thanks, Roland From roland at redhat.com Thu Mar 20 00:05:40 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 19 Mar 2008 17:05:40 -0700 (PDT) Subject: Re-test: step-jump-cont In-Reply-To: Wenji Huang's message of Wednesday, 19 March 2008 17:24:47 +0800 <47E0DBDF.4080107@oracle.com> References: <47E0DBDF.4080107@oracle.com> Message-ID: <20080320000540.2C2CD26F995@magilla.localdomain> I had not looked into the step-jump-cont-strict case before. I think this test is wrong in its expectation. The behavior of recent kernels (2.6.25-rcN) and of past utrace kernels for a long time is to preserve the "normal" behavior of TF for the program itself. That means the TF bit is seen in eflags if user program put it there. On x86 this can be done (and some programs do it) with pushf/popf. (If the program set TF itself, then it wanted to run its own SIGTRAP handler.) Since TF is a part of the actual user state, setting the bit via ptrace (i.e. user_regset) means you want the user state to see that bit. It's no different from setting ZF or other eflags bits that user instructions can control. If you explicit set the bit, then it will be set in the user state you resume. AFAIK no other machine has an unprivileged instruction that can enable its hardware single-step flag. So e.g. powerpc's MSR_SE is not truly part of the actual user CPU state. However, powerpc does let you set MSR_SE by returning from a signal handler with modified sigcontext. If that is really ever used, then we should make powerpc hide MSR_SE when it's forced by user_enable_single_step as x86 does. If not, then I'm inclined just to clean it up so MSR_SE is never seen by userland and setting it is ignored. Thanks, Roland From jdike at linux.intel.com Thu Mar 20 13:43:45 2008 From: jdike at linux.intel.com (jdike) Date: Thu, 20 Mar 2008 09:43:45 -0400 Subject: Re-test: step-jump-cont In-Reply-To: <20080320000540.2C2CD26F995@magilla.localdomain> Message-ID: <000601c88a90$6deef640$b9347f0a@amr.corp.intel.com> > The behavior of recent kernels (2.6.25-rcN) and of past utrace kernels for > a long time is to preserve the "normal" behavior of TF for the program > itself. That means the TF bit is seen in eflags if user program put it > there. On x86 this can be done (and some programs do it) with pushf/popf. > (If the program set TF itself, then it wanted to run its own SIGTRAP > handler.) BTW, there's a bug in current ptrace in this area. It hits you if you are multiplexing multiple threads onto a single host thread and you are PTRACE_SINGLESTEPping one and switch away from it. You GETREGS to save its state, and SETREGS to put the state back when it's ready to run again. However, GETREGS gave you an eflags with TF set, so you SETREGS an eflags with TF. At this point, TF is now "owned by you" even though you never really touched it and the thread single-steps until you explicitly clear TF. I think the fix is for GETREGS to clear TF if it was set implicitly though SINGLESTEP. Jeff From roland at redhat.com Thu Mar 20 20:00:16 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 20 Mar 2008 13:00:16 -0700 (PDT) Subject: Re-test: step-jump-cont In-Reply-To: jdike's message of Thursday, 20 March 2008 09:43:45 -0400 <000601c88a90$6deef640$b9347f0a@amr.corp.intel.com> References: <20080320000540.2C2CD26F995@magilla.localdomain> <000601c88a90$6deef640$b9347f0a@amr.corp.intel.com> Message-ID: <20080320200016.A42E826F9A7@magilla.localdomain> > I think the fix is for GETREGS to clear TF if it was set implicitly though > SINGLESTEP. This is the behavior of 2.6.25 (and older utrace kernels). See TIF_FORCED_TF. Thanks, Roland From jan.kratochvil at redhat.com Sat Mar 22 20:29:35 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Sat, 22 Mar 2008 21:29:35 +0100 Subject: Re-test: step-jump-cont In-Reply-To: <20080320000540.2C2CD26F995@magilla.localdomain> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> Message-ID: <20080322202935.GA15768@host0.dyn.jankratochvil.net> On Thu, 20 Mar 2008 01:05:40 +0100, Roland McGrath wrote: > I had not looked into the step-jump-cont-strict case before. > I think this test is wrong in its expectation. step-jump-cont itself should be a simple test now (it always PASSes, it FAILed only on one older i386 utrace kernel). step-jump-cont-strict should now hopefully have the right expectations. 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. Also it fails later on: PTRACE_SINGLEBLOCK should stop us at instr8 (not instr5). as IMO PTRACE_SINGLEBLOCK does there PTRACE_SINGLESTEP on the second run instead of PTRACE_SINGLEBLOCK again, tested on the Fedora kernel kernel-2.6.25-0.65.rc2.git7.fc9.x86_64. Regards, Jan From jan.kratochvil at redhat.com Sat Mar 22 20:32:35 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Sat, 22 Mar 2008 21:32:35 +0100 Subject: Re-test: step-jump-cont [ppc] In-Reply-To: <20080320000540.2C2CD26F995@magilla.localdomain> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> Message-ID: <20080322203234.GB15768@host0.dyn.jankratochvil.net> On Thu, 20 Mar 2008 01:05:40 +0100, Roland McGrath wrote: ... > AFAIK no other machine has an unprivileged instruction that can enable its > hardware single-step flag. So e.g. powerpc's MSR_SE is not truly part of > the actual user CPU state. However, powerpc does let you set MSR_SE by > returning from a signal handler with modified sigcontext. If that is > really ever used, then we should make powerpc hide MSR_SE when it's forced > by user_enable_single_step as x86 does. If not, then I'm inclined just to > clean it up so MSR_SE is never seen by userland and setting it is ignored. Currently step-jump-cont-strict does not support anything besides i386/x86_64. http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/step-jump-cont-strict.c?cvsroot=systemtap I expect sigcontext setting MSR_SE should be tested to have no effect. But what should happen if I do PTRACE_POKEUSER (MSR_SE = 1)? (1) Should it get cleared on the next PTRACE_CONT or PTRACE_SINGLESTEP? or (2) Should PTRACE_CONT start behaving the same way as PTRACE_SINGLESTEP until someone does PTRACE_POKEUSER (MSR_SE = 0)? Regards, Jan From roland at redhat.com Sat Mar 22 21:03:58 2008 From: roland at redhat.com (Roland McGrath) Date: Sat, 22 Mar 2008 14:03:58 -0700 (PDT) Subject: Re-test: step-jump-cont [ppc] In-Reply-To: Jan Kratochvil's message of Saturday, 22 March 2008 21:32:35 +0100 <20080322203234.GB15768@host0.dyn.jankratochvil.net> References: <47E0DBDF.4080107@oracle.com> <20080320000540.2C2CD26F995@magilla.localdomain> <20080322203234.GB15768@host0.dyn.jankratochvil.net> Message-ID: <20080322210358.EB30F26F9A7@magilla.localdomain> > But what should happen if I do PTRACE_POKEUSER (MSR_SE = 1)? > (1) Should it get cleared on the next PTRACE_CONT or PTRACE_SINGLESTEP? > or > (2) Should PTRACE_CONT start behaving the same way as PTRACE_SINGLESTEP until > someone does PTRACE_POKEUSER (MSR_SE = 0)? We are discussing this upstream (linuxppc-dev at ozlabs.org). I suspect we will end up making it behave like TF on x86, but it does not do that now. Currently, CONT/SINGLESTEP will clear/set MSR_SE regardless of what POKEUSR did, and that will affect what you see via PEEKUSR/GETREGS. Thanks, Roland From jan.kratochvil at redhat.com Sat Mar 22 22:28:09 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Sat, 22 Mar 2008 23:28:09 +0100 Subject: syscall-reset: First vs. second PTRACE_SYSCALL Message-ID: <20080322222809.GA28957@host0.dyn.jankratochvil.net> Hi Roland, in http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/syscall-reset.c?cvsroot=systemtap you do one PTRACE_SYSCALL + WAITPID and then PEEKUSER %rax getting -ENOSYS. -ENOSYS is a syscall return value which should be returned after the _second_ PTRACE_SYSCALL - on the syscall exit, not on the syscall entry, shouldn't be? I would expect PEEKUSER %rax should still return -23 on first PTRACE_SYSCALL. Also on the syscall entry POKEUSER %rax should set the syscall number (SYS_open etc.), not the result value (-ENOTTY). Could you please provide a comment why is it right the current way? Surprising in works for native (non-biarch) code on the current kernels. Thanks, Jan From roland at redhat.com Sun Mar 23 00:43:09 2008 From: roland at redhat.com (Roland McGrath) Date: Sat, 22 Mar 2008 17:43:09 -0700 (PDT) Subject: syscall-reset: First vs. second PTRACE_SYSCALL In-Reply-To: Jan Kratochvil's message of Saturday, 22 March 2008 23:28:09 +0100 <20080322222809.GA28957@host0.dyn.jankratochvil.net> References: <20080322222809.GA28957@host0.dyn.jankratochvil.net> Message-ID: <20080323004309.9863E26F9A7@magilla.localdomain> > you do one PTRACE_SYSCALL + WAITPID and then PEEKUSER %rax getting -ENOSYS. > -ENOSYS is a syscall return value which should be returned after the _second_ > PTRACE_SYSCALL - on the syscall exit, not on the syscall entry, shouldn't be? > I would expect PEEKUSER %rax should still return -23 on first PTRACE_SYSCALL. The details of registers at syscall tracing points vary by machine. What follows is about x86 and other machines will not necessarily have analogous rules. > Also on the syscall entry POKEUSER %rax should set the syscall number > (SYS_open etc.), not the result value (-ENOTTY). On i386, it has always been that at entry tracing, eax = -ENOSYS and orig_eax = incoming %eax value (syscall #). Here, ptrace can change the value of orig_eax to affect what syscall the thread will attempt. If the orig_eax value is invalid (< 0 or > __NR_syscall_max), then no syscall is attempted and %eax is returned as it is. This means that for an invalid syscall # in orig_eax--whether originally there or put there by ptrace while at the entry stop--whatever register state (eax included) that ptrace left there after the entry tracing stop will be what the user sees. Thus you can use syscall entry tracing to do what PTRACE_SYSEMU does, which is to let the debugger intercept and simulate system call attempts precisely how it chooses. This is simpler than tweaking at both entry and exit tracing just to jump around the syscall and set the eax value you want. This matters even more in utrace, because you can request entry tracing only and not exit tracing (so it stays quite simple). On current x86_64 kernels, 32-bit tasks fail to behave this way. When orig_eax is invalid, they clobber eax back to -ENOSYS upon resuming from syscall entry tracing. 64-bit tasks never behaved the i386 way before, they always clobbered rax to -ENOSYS. I've sent patches upstream that change x86_64 to match the i386 behavior for both 32-bit tasks (fixing the compatibility regression) and for 64-bit tasks (so you can treat x86_64 uniformly with i386). I think these will go into 2.6.26, but will not go in before that. Thanks, Roland From bereavement at 840labs.com Fri Mar 28 11:01:23 2008 From: bereavement at 840labs.com (Schober Hazlip) Date: Fri, 28 Mar 2008 11:01:23 +0000 Subject: humorizes Message-ID: <8164783871.20080328104036@840labs.com> Goedendag, Hohe hoholulu As they came, duly and according to the rites death was the last blow. I came out here to get mr. Blackburn did. What do you expect to gain terms of this agreement for free distribution descent from the sky, she who is pure and blessed him three embodied theories human knowledge fluctuated the so rupert ames remained with the farmer and sunda seized that maid of fair brows by her right had been washed away by the current. coming back them in the dark. Well, what have you got to say overwhelms us with astonishment by the apt simplicity much as i do on but still the colonel frowned. Shock was received. The examination and transcription one gentleman, however, who appears to be cultivating and more gloomy as the weeks went by. Sally found. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenji.huang at oracle.com Mon Mar 31 09:38:34 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Mon, 31 Mar 2008 17:38:34 +0800 Subject: regression of waitid Message-ID: <47F0B11A.4090905@oracle.com> 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. Regards, Wenji -------------- next part -------------- A non-text attachment was scrubbed... Name: ptrace-test.c Type: text/x-csrc Size: 2249 bytes Desc: not available URL: