Re: Froggy status
David Smith wrote: I took a quick look at froggy.c (the kernel module). I'm not sure how finished A long, long, way there from--it's still a hacker's sandbox. you consider it, but in general I'm not sure it is paranoid enough. For instance, what happens if there is a error in a client and it aborts? What happens if someone does a rmmod on the module while clients are still running? Both circumstances on the to-do list. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey signature.asc Description: OpenPGP digital signature
tracehook is in!
We had a pleasant surprise over the weekend. The tracehook branch was merged in upstream! As of 2.6.26-git18, the generic tracehook patches plus the powerpc and sparc64 arch work are all in. The x86-tracehook branch is in the hands of the x86 arch maintainers and I expect it will get pushed up soon. For 2.6.26-git18, you still need to apply x86-tracehook.patch. Aside from the arch merging, the only thing you have to apply now is utrace.patch itself. This was the last big milestone on the path to upstream merging, short of finally including utrace itself upstream. I'm very grateful to everyone who helped review the code and everyone who worked on arch code. The x86, powerpc, and sparc64 arch support is in good order now and handed off to the arch maintainers. If you are intereseted in any other arch working with utrace or other future debug/tracing features, now is the time to take that up directly with your arch maintainers. The arch support can be implemented and merged upstream now without any interlock with utrace work. Feel free to CC: me (or this list) on your patches and discussions with arch maintainers. For what needs to be done, see http://sourceware.org/systemtap/wiki/utrace/arch/HowTo s390 and ia64 have done the big pieces of the work upstream already. (That's user_regset and ptrace cleanups.) The rest is relatively quick stuff that any kernel hacker for that arch can finish up in a day. I have written (but never even compiled) a subset of the remaining pieces for ia64, and I'll send those to the upstream ia64 folks to consider. Thanks, Roland
Re: utrace doc update, nearing submission(?)
Roland McGrath wrote:
I've read through most of the docs (although my eyes certainly glazed
over when I got to the tracehook stuff).
That stuff is for kernel maintainers, as it says. You don't really need to
know. For that part, just checking for typos is all the help it needs.
What's there seems to be pretty good. I think it is missing (or at
least I missed it) a good description of how to asynchronously stop a
thread. What are the ins-and-outs here, knowing how/when to use
UTRACE_STOP vs. UTRACE_INTERRUPT, etc.
Yeah, the kerneldoc-driven format doesn't lend itself to a lot of
exposition. The details are in there in the utrace_control description.
But I guess it's not real obvious how to put it all together.
How is the Stopping Safely section? That seems like the place to add
something more direct about this. Was there something other than the
UTRACE_INTERRUPT issue that didn't seem clear?
Is that not clear to you, or is it just not clear in the documentation?
Probably both - see below.
You use UTRACE_INTERRUPT when you want to interfere with system calls in
progress (or blocking page faults or whatever). To interrupt and stop
(like PTRACE_ATTACH does) and handle it already being stopped, you really
want to do UTRACE_STOP first and see 0 if it's already stopped. If it's
not already stopped, you get -EINPROGRESS and then can do UTRACE_INTERRUPT
to be sure that you interrupt it and that the race complexity of it being
stopped before or waking up is minimized. (If you just do UTRACE_INTERRUPT
first, then you'll get a callback soon--unless it's stopped. Then you
won't, but if you do UTRACE_STOP second to see if it's stopped, then you
could get the callback in between and your life gets more hairy.)
Ah.
That paragraph makes lots of sense - I wish it could be included
somewhere. So, basically, you do something like this:
rc = utrace_control(t, engine, UTRACE_STOP);
if (rc == -EINPROGRESS) {
rc = utrace_control(t, engine, UTRACE_INTERRUPT);
}
--
David Smith
[EMAIL PROTECTED]
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
Re: Froggy status
David Smith wrote: I took a quick look at froggy.c (the kernel module). I'm not sure how finished you consider it, but in general I'm not sure it is paranoid enough. For instance, what happens if there is a error in a client and it aborts? Just looked into that: when a task crashies the kernel apparently closes any open file descriptors, thereby invoking froggy_release() which gives froggy a chance to free any resources, etc. What happens if someone does a rmmod on the module while clients are still running? The rmmod fails as long as there are any open fds on the froggy peeudo-file /sys/kernel/debug/froggy. BTW, until further notice--tomorrow morning, probably, don't use a froggy of any later that 2006-07-28 11:20. Somehow a kernel-crasher snuck in which I'll debug in the morning. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey signature.asc Description: OpenPGP digital signature
