From jkenisto at us.ibm.com Tue Jul 1 01:15:50 2008 From: jkenisto at us.ibm.com (Jim Keniston) Date: Mon, 30 Jun 2008 18:15:50 -0700 Subject: [Ksummit-2008-discuss] DTrace In-Reply-To: <20080630171246.GB21660@redhat.com> References: <20080627150424.GB14894@parisc-linux.org> <1214580213.3394.40.camel@localhost.localdomain> <20080627155018.GC14894@parisc-linux.org> <1214583502.7698.15.camel@weaponx> <20080627163056.GB1416@lst.de> <20080628072605.GA505@in.ibm.com> <20080629084002.GA24131@lst.de> <20080630051034.GA4970@in.ibm.com> <20080630112913.GA18817@lst.de> <20080630171246.GB21660@redhat.com> Message-ID: <1214874950.3949.47.camel@dyn9047018139.beaverton.ibm.com> On Mon, 2008-06-30 at 13:12 -0400, Frank Ch. Eigler wrote: > Hi - > > On Mon, Jun 30, 2008 at 01:29:13PM +0200, Christoph Hellwig wrote: > > > [...] This might be getting a little offtopic for the kernel summit > > discuss list, but let's start anyway, we can move this to a better > > suited list, although I can't think of one except for linux-kernel. > > systemtap at sources.redhat.com > utrace-devel at redhat.com > > > > I'm not sure if that's the current design, but I can't find any > > evidence in the code that it allows running handlers in process > > context, all that's available is a kernel callback. [...] To clarify, it's a kernel callback that runs in the context of the probed thread -- like other utrace-based callbacks. And like other utrace-based callbacks, a uprobes handler can block for stuff like copy_to/from_user()... although I believe systemtap will support only non-blocking handlers for now. > > For systemtap's purposes, that is sufficient. Our probes are meant to > run non-intrusively (they do not mess with user thread scheduling, > their VM state, strictly limited time & space consumption), so > actually injecting equivalent snippets of code into userspace for > execution there does not seem to buy anything. Plus, like dtrace, we > want scripts to be able to intermix probes (=> share data) amongst > kernel and multiple user-space threads, and this seems most naturally > done by running the probes themselves in kernel space. Yes. > > > > [...] What we really need is a userspace interface so that it > > actually can be used by thing like frysk or an implementation of the > > userspace dtrace hooks. Userspace dtrace hooks could be probed using systemtap-generated uprobes, whether or not the hooks all funnel into the same user-space handler function. > > That will get built as other tools require it. Systemtap per se will > likely not. Two years back, we explored the possibility of systemtap translating a script into an ad hoc tracer app that used ptrace. The idea was that that would suffice in cases where the user doesn't care to see what's going on in the kernel. My experience was that ptrace wasn't up to the task. Perhaps when we nail down the right utrace-based, ptrace-replacement system call interface (utracer II, or whatever -- see the current discussion on the utrace-devel list), we should revisit that option. It would make systemtap accessible to the ordinary application programmer, without him/her needing root or stapdev to bless his/her script. Stuff that's in uprobes (e.g., kprobes-style single-stepping out of line, to allow real-time tracing of multithreaded apps) can be made available to the new syscall API and/or utrace. > > > > [...] For complex traces doing this in userspace is for sure a better idea. > > Can you elaborate upon this more complex scenario? > > > - FChE Jim Keniston From roland at redhat.com Tue Jul 1 08:44:17 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 1 Jul 2008 01:44:17 -0700 (PDT) Subject: The demise of utracer. In-Reply-To: Chris Moller's message of Monday, 30 June 2008 10:41:37 -0400 <4868F0A1.8080407@redhat.com> References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> <4868F0A1.8080407@redhat.com> Message-ID: <20080701084417.26A7815420E@magilla.localdomain> Sorry to be blunt, Chris. But I think you're headed down a useless rat hole. I agree that the usage of /proc you've described is a bad interface. I am slightly mystified as to how that came to be what you settled on. I don't think it's worthwhile to hash over that. Let's move on. Please forget ptrace. Please forget about adding syscalls. At this point I think I just need you to give me the benefit of the doubt when I tell you I am sure this is not the way, and even dabbling sidetracks us from really useful progress. Let's move on. To reiterate: transport is boring. This is not where the there is. We need to focus on what we're providing that anyone could care to have a means to communicate with! I'm pretty sure what most people had in mind when saying "fd-based" is approximately this: you do one open call, that fd is your handle on one session with the interface. You can write/ioctl to send it commands, and you can read (and perhaps ioctl) on it to receive either information replies or event notifications. You can use poll/select et al for efficient wakeup when there is something the interface wants to tell you. As with all fds, sudden death of the holder of the fd implicitly closes it and that triggers cleanup of the session on the kernel side. There are more possibilities with multiple fds used together as one "session with the interface", but this is the basic one. Let's start with that focus and move on. Below is a trivial example I whipped up. This uses debugfs. There are myriad ways to do the same thing; this one is simple and handy. I hope it illustrates how a magic file can set up per-open data structures for its operations to use, and tear them down gracefully and automatically on close. It should be clear how to add .write, .poll, .unlocked_ioctl, etc. functions to build a full transport this way without much hair. This method is the easy path to start with, and we can worry more about transport later. Let's move on. The way to find the easy route is to ask for directions. When it seems like there ought to be a more natural way to do something, there might well be some ways. When you post here about what you're up against, people here can give you pointers to what might help. It's not like posting on LKML and braving the flames. Noone here is going to give you a hard time (not worse than this, anyway). We need your participation to be able to share what we know. Let's move on together. I'm sorry I've been remiss in writing up everything I've promised about what I think we do need to focus on. It hasn't helped to get sidetracked on what I say is the boring stuff. But I recognize that my disorganization makes it difficult on your end. Thanks, Roland ----- /* * Compile the module and insmod it. * Be sure to have done "mount -t debugfs debugfs /sys/kernel/debug" * (systemtap or something else might already have done it for you). * Look at /sys/kernel/debug/foo for example behavior. */ #include #include #include #include MODULE_DESCRIPTION("example using debugfs"); MODULE_LICENSE("GPL"); static atomic_t next = ATOMIC_INIT(0); static int example_open(struct inode *inode, struct file *file) { /* * The 'struct file' describes what the user's file descriptor * from this one open points to. It's shared by dup and fd * inheritance, but not by an independent open call. We can * stash here some data specific to just this one open file * description. */ file->private_data = (void *) (unsigned long) atomic_inc_return(&next); return 0; } static ssize_t example_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { unsigned long n = (unsigned long) file->private_data; char string[128]; int size = snprintf(string, sizeof string, "you are number %lu\n", n); return simple_read_from_buffer(buf, count, ppos, string, size); } static int example_release(struct inode *inode, struct file *file) { unsigned long n = (unsigned long) file->private_data; printk(KERN_NOTICE "bye bye number %lu\n", n); return 0; } static const struct file_operations example_fops = { .owner = THIS_MODULE, .open = example_open, .release = example_release, .read = example_read }; static struct dentry *top_dentry; static int __init init_example(void) { struct dentry *d = debugfs_create_file("foo", 0666, NULL, NULL, &example_fops); if (!d) return -EROFS; if (IS_ERR(d)) return PTR_ERR(d); top_dentry = d; return 0; } static void __exit exit_example(void) { debugfs_remove(top_dentry); } module_init(init_example); module_exit(exit_example); From prasad at linux.vnet.ibm.com Tue Jul 1 09:34:35 2008 From: prasad at linux.vnet.ibm.com (K.Prasad) Date: Tue, 1 Jul 2008 15:04:35 +0530 Subject: The demise of utracer. In-Reply-To: <20080701084417.26A7815420E@magilla.localdomain> References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> <4868F0A1.8080407@redhat.com> <20080701084417.26A7815420E@magilla.localdomain> Message-ID: <20080701093435.GA15035@in.ibm.com> On Tue, Jul 01, 2008 at 01:44:17AM -0700, Roland McGrath wrote: > Sorry to be blunt, Chris. But I think you're headed down a useless rat hole. > > I agree that the usage of /proc you've described is a bad interface. > I am slightly mystified as to how that came to be what you settled on. > I don't think it's worthwhile to hash over that. Let's move on. > > Please forget ptrace. Please forget about adding syscalls. At this > point I think I just need you to give me the benefit of the doubt when > I tell you I am sure this is not the way, and even dabbling sidetracks > us from really useful progress. Let's move on. > > To reiterate: transport is boring. This is not where the there is. > We need to focus on what we're providing that anyone could care to > have a means to communicate with! > > I'm pretty sure what most people had in mind when saying "fd-based" is > approximately this: you do one open call, that fd is your handle on > one session with the interface. You can write/ioctl to send it > commands, and you can read (and perhaps ioctl) on it to receive either > information replies or event notifications. You can use poll/select > et al for efficient wakeup when there is something the interface wants > to tell you. As with all fds, sudden death of the holder of the fd > implicitly closes it and that triggers cleanup of the session on the > kernel side. There are more possibilities with multiple fds used > together as one "session with the interface", but this is the basic > one. Let's start with that focus and move on. > > Below is a trivial example I whipped up. This uses debugfs. There > are myriad ways to do the same thing; this one is simple and handy. > I hope it illustrates how a magic file can set up per-open data > structures for its operations to use, and tear them down gracefully > and automatically on close. It should be clear how to add .write, > .poll, .unlocked_ioctl, etc. functions to build a full transport > this way without much hair. This method is the easy path to start > with, and we can worry more about transport later. Let's move on. > > The way to find the easy route is to ask for directions. When it > seems like there ought to be a more natural way to do something, there > might well be some ways. When you post here about what you're up > against, people here can give you pointers to what might help. It's > not like posting on LKML and braving the flames. Noone here is going > to give you a hard time (not worse than this, anyway). We need your > participation to be able to share what we know. Let's move on together. > > I'm sorry I've been remiss in writing up everything I've promised > about what I think we do need to focus on. It hasn't helped to get > sidetracked on what I say is the boring stuff. But I recognize that > my disorganization makes it difficult on your end. > > > Thanks, > Roland > > > ----- > /* > * Compile the module and insmod it. > * Be sure to have done "mount -t debugfs debugfs /sys/kernel/debug" > * (systemtap or something else might already have done it for you). > * Look at /sys/kernel/debug/foo for example behavior. > */ > > #include > #include > #include > #include > > MODULE_DESCRIPTION("example using debugfs"); > MODULE_LICENSE("GPL"); > > static atomic_t next = ATOMIC_INIT(0); > > static int example_open(struct inode *inode, struct file *file) > { > /* > * The 'struct file' describes what the user's file descriptor > * from this one open points to. It's shared by dup and fd > * inheritance, but not by an independent open call. We can > * stash here some data specific to just this one open file > * description. > */ > file->private_data = (void *) (unsigned long) atomic_inc_return(&next); > return 0; > } > > static ssize_t example_read(struct file *file, char __user *buf, > size_t count, loff_t *ppos) > { > unsigned long n = (unsigned long) file->private_data; > char string[128]; > int size = snprintf(string, sizeof string, "you are number %lu\n", n); > > return simple_read_from_buffer(buf, count, ppos, string, size); > } > > static int example_release(struct inode *inode, struct file *file) > { > unsigned long n = (unsigned long) file->private_data; > printk(KERN_NOTICE "bye bye number %lu\n", n); > return 0; > } > > static const struct file_operations example_fops = { > .owner = THIS_MODULE, > .open = example_open, > .release = example_release, > .read = example_read > }; > > static struct dentry *top_dentry; > > static int __init init_example(void) > { > struct dentry *d = debugfs_create_file("foo", 0666, NULL, > NULL, &example_fops); > if (!d) > return -EROFS; > if (IS_ERR(d)) > return PTR_ERR(d); > top_dentry = d; > return 0; > } > > static void __exit exit_example(void) > { > debugfs_remove(top_dentry); > } > > module_init(init_example); > module_exit(exit_example); > Hi All, Sorry if I have missed out something I need to know before I respond to this email. But the "trace" infrastructure (lib/trace.c) already provides such a facility which more features such as per-cpu buffer for faster transmission (it is a wrapper over "relay" which sits on top of "debugfs"). The interfaces provided by "trace" are much simpler/functional than setting up a "debugfs" interface manually (see samples/trace/fork_trace.c) and the directory structure and control files setup by "trace" are already familiar to the systemtap code. Thanks, K.Prasad P.S.: "trace" is currently in -mm tree. From cmoller at redhat.com Tue Jul 1 13:00:53 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 01 Jul 2008 09:00:53 -0400 Subject: The demise of utracer. In-Reply-To: <20080701084417.26A7815420E@magilla.localdomain> References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> <4868F0A1.8080407@redhat.com> <20080701084417.26A7815420E@magilla.localdomain> Message-ID: <486A2A85.2020100@redhat.com> Roland McGrath wrote: > Sorry to be blunt, Chris. But I think you're headed down a useless rat hole. > > I agree that the usage of /proc you've described is a bad interface. > I am slightly mystified as to how that came to be what you settled on. > At the time Andrew Cagney and I decided to go that route, it was because frysk had no means of effecting kernel changes other than by use of a loadable module and the use of /proc entries was a common, easily accessible, means of communicating with modules. > I don't think it's worthwhile to hash over that. Let's move on. > I'd love to, but it would be nice to have a clue as to which direction. All I'm getting from The World is a list of stuff I shouldn't be doing, and that helps not at all with regard to what I /should/ be doing. > Please forget ptrace. Please forget about adding syscalls. At this > point I think I just need you to give me the benefit of the doubt when > I tell you I am sure this is not the way, and even dabbling sidetracks > us from really useful progress. Let's move on. > Again, ptrace hacks and new syscall hacks are things I can actually do and in the absence of any other clue concerning what I should be doing it's what I've been doing.--I know it's a been a near-total waste of my time, but it kinda beats staring at a blank screen all day. I'll be glad to give you the benefit of the doubt--you've been kernel hacking longer than I have--but if you have cool notions about which way to go, you kinda need to let the rest of us know what they are. (And, reading ahead, yeah, I know, that's what the rest of this note is...) I'll commence to hackin'. cm -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmoller at redhat.com Tue Jul 1 19:28:04 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 01 Jul 2008 15:28:04 -0400 Subject: The demise of utracer. In-Reply-To: <20080701093435.GA15035@in.ibm.com> References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> <4868F0A1.8080407@redhat.com> <20080701084417.26A7815420E@magilla.localdomain> <20080701093435.GA15035@in.ibm.com> Message-ID: <486A8544.3060905@redhat.com> K.Prasad wrote: > > Hi All, > Sorry if I have missed out something I need to know before I > respond to this email. But the "trace" infrastructure (lib/trace.c) > already provides such a facility which more features such as per-cpu > buffer for faster transmission (it is a wrapper over "relay" which > sits on top of "debugfs"). > > The interfaces provided by "trace" are much simpler/functional than > setting up a "debugfs" interface manually (see > samples/trace/fork_trace.c) and the directory structure and control > files setup by "trace" are already familiar to the systemtap code. > > Thanks, > K.Prasad > P.S.: "trace" is currently in -mm tree. > Thought it might be interesting to check this out--the patched 2.6.26-rc5 kernel built fine but panicked when I tried to boot it. So much for the easy way... -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From prasad at linux.vnet.ibm.com Wed Jul 2 02:26:10 2008 From: prasad at linux.vnet.ibm.com (K.Prasad) Date: Wed, 2 Jul 2008 07:56:10 +0530 Subject: The demise of utracer. In-Reply-To: <486A8544.3060905@redhat.com> References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> <4868F0A1.8080407@redhat.com> <20080701084417.26A7815420E@magilla.localdomain> <20080701093435.GA15035@in.ibm.com> <486A8544.3060905@redhat.com> Message-ID: <20080702022610.GA8273@in.ibm.com> On Tue, Jul 01, 2008 at 03:28:04PM -0400, Chris Moller wrote: > > > K.Prasad wrote: >> >> Hi All, >> Sorry if I have missed out something I need to know before I >> respond to this email. But the "trace" infrastructure (lib/trace.c) >> already provides such a facility which more features such as per-cpu >> buffer for faster transmission (it is a wrapper over "relay" which >> sits on top of "debugfs"). >> >> The interfaces provided by "trace" are much simpler/functional than >> setting up a "debugfs" interface manually (see >> samples/trace/fork_trace.c) and the directory structure and control >> files setup by "trace" are already familiar to the systemtap code. >> >> Thanks, >> K.Prasad >> P.S.: "trace" is currently in -mm tree. >> > > Thought it might be interesting to check this out--the patched > 2.6.26-rc5 kernel built fine but panicked when I tried to boot it. So You might want to directly try out 2.6.26-rc5-mm1 directly. It boots fine on my T60p with default configs. Thanks, K.Prasad From cmoller at redhat.com Wed Jul 2 03:59:11 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 01 Jul 2008 23:59:11 -0400 Subject: The demise of utracer. In-Reply-To: <20080702022610.GA8273@in.ibm.com> References: <4861B254.90001@redhat.com> <20080627204954.3B75F154050@magilla.localdomain> <4868F0A1.8080407@redhat.com> <20080701084417.26A7815420E@magilla.localdomain> <20080701093435.GA15035@in.ibm.com> <486A8544.3060905@redhat.com> <20080702022610.GA8273@in.ibm.com> Message-ID: <486AFD0F.8050609@redhat.com> K.Prasad wrote: > On Tue, Jul 01, 2008 at 03:28:04PM -0400, Chris Moller wrote: > >> K.Prasad wrote: >> >>> Hi All, >>> Sorry if I have missed out something I need to know before I >>> respond to this email. But the "trace" infrastructure (lib/trace.c) >>> already provides such a facility which more features such as per-cpu >>> buffer for faster transmission (it is a wrapper over "relay" which >>> sits on top of "debugfs"). >>> >>> The interfaces provided by "trace" are much simpler/functional than >>> setting up a "debugfs" interface manually (see >>> samples/trace/fork_trace.c) and the directory structure and control >>> files setup by "trace" are already familiar to the systemtap code. >>> >>> Thanks, >>> K.Prasad >>> P.S.: "trace" is currently in -mm tree. >>> >>> >> Thought it might be interesting to check this out--the patched >> 2.6.26-rc5 kernel built fine but panicked when I tried to boot it. So >> > You might want to directly try out 2.6.26-rc5-mm1 directly. It boots > fine on my T60p with default configs. > Hmmm. okay, I'l try that, thx. (i was using the -mm3 patch and an oldconfig from Fedora i686.) > Thanks, > K.Prasad > > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Wed Jul 2 12:20:46 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 2 Jul 2008 05:20:46 -0700 (PDT) Subject: ntrace: interface ideas Message-ID: <20080702122046.C29AE15416D@magilla.localdomain> Here is a vague start at the directions I have in mind for a user-level interface that I've been calling "ntrace". It's not a real specific plan at the literal interface level. It's an overview of what the components are that the bit-level definition of the user-level interface sits atop. I'll start with a couple of terms that I'll use later throughout the discussion. A tracing session is one independent use of the interface, e.g. one debugger application might have one session to handle many debugees. Different sessions don't interact or know about each other directly. A session ends when its users go away, so it always ends automatically when the debugger applications die suddenly and so forth. When a session ends, all its state goes away ceases to mean anything. Everything I'll talk about later is meant within the context of one session. (At some point in the future we might deal with nuances beyond this, but ignore that for now.) A tracing "channel" is the term I'll use to encompass the whole subject of transport. We'll leave the details of transport aside here, and just say what the essential characteristics of a channel are. In the long run, there can be multiple kinds of channels and there can be multiple channels in one session. To start with, we'll only worry about a single channel per session. A channel supplies a security context. (I'll talk separately about the security model, and we can leave it aside for now.) A channel can be a source of commands. A channel can send data back to the user. For sending data, a channel might have various buffering options and characteristics available. Sending to the channel per se has to be nonblocking in the kernel. So e.g., there may be fill-and-drop or circular buffer options. For lossless buffering, a channel may need to ask the sending thread to wait for a buffer drain. Internally, this may mean using UTRACE_STOP to hold a thread in check until a channel-drained callback lets it resume to generate more data. We don't have to worry about all that immediately. But these are some of the subtleties between the "channel" layer and the "core" of the thing. I think of the interface as asynchronous at base. There may at some point be some synchronous calls to optimize the round trips. But we know that by its nature an interface for handling many threads at once has to be asynchronous, because an event notification can always be occurring while you are doing an operation on another thread. So what keeping it simple means for the first version is that we only worry about the asynchronous model. Think of it like a network protocol between the application and the "tracing server" inside the kernel. (Don't get hung up on that metaphor if it sounds like a complication to you.) One thing we know we need is to send multiple commands to the interface in a single channel transaction (i.e. system call). In the general case, we might have both datagram and stream channels. But we might as well only consider the stream case since we have to anyway; i.e., we can't rely on any intrinsic packetization, we have to recognize boundaries between separate requests in-band in the command channel. I think what is the first most important thing about the interface is not anything much about what's in it. It's rapid prototyping. It needs to be simple on the kernel side to write a new function, with a minimum of boilerplate, add something to at most two tables, and recompile the module, to have your new command available in the user-level interface. As for encoding, I think everything can be composed of "words" and "blobs". A word is long/unsigned long in kernel-land. A blob means a raw chunk of bytes. To keep words aligned, I'd encode e.g. {word=1,blob=A,word=2,blob=B} as: word 0: 1 word 1: word 2: 2 word 3: : : word n: next unrelated part of the stream This keeps it straightforward, both on the kernel side and in user-level interface front ends, to add a new command or report-back that takes n words and m blobs meaning something or other. I tend to over-engineer these things. So I'd been thinking about a discoverable framework for the command vocabulary. Down the road I do want to have some dynamic extensibility. But we shouldn't get bogged down in that now. Job #1 is to get something hobbling along that is easy to hack on, easy to change, easy to play with, where you pull the cat's tail in user mode and he's meowing in the kernel module (except there is no cat--ok you can use a cat if you want to, I said I wasn't addressing transport). In http://sourceware.org/ml/systemtap/2008-q2/msg00459.html I introduced "tracing groups" (sorry, it's about half way down that long message). It was slightly elaborated in that thread. I will talk all about groups in another posting (sorry, will be another bit of delay before I can have that all written up). Some ideas about groups have a lot to do with how I'd like to structure the command set. But you don't need to wait to hash that out. Get started with whatever commands make sense and are straightforward to use to demonstrate using the fundaments of the interface. Don't worry that everything will get reorganized as we figure it all out (it will, just don't worry about it). Thanks, Roland From eyelid at sotokanda.jp Wed Jul 2 16:06:25 2008 From: eyelid at sotokanda.jp (Christian Maupins) Date: Wed, 02 Jul 2008 16:06:25 +0000 Subject: daraf torsos Message-ID: <1100129794.20080702154426@sotokanda.jp> Heya, http://rU.fitbed.cn Day they never contain, relics of any species line to the other and back again. I suppose he workmen, whilst others were taken to the imperial off early to the hospital to see how things are ken, my lord. I'm only jist come, an' i've seen waiting with mrs killer for the carriage, he drew her name dragged through, the mud, muttered nevile is there anything the matter? You're not in a. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkenisto at us.ibm.com Wed Jul 2 21:31:28 2008 From: jkenisto at us.ibm.com (Jim Keniston) Date: Wed, 02 Jul 2008 14:31:28 -0700 Subject: ntrace: interface ideas In-Reply-To: <20080702122046.C29AE15416D@magilla.localdomain> References: <20080702122046.C29AE15416D@magilla.localdomain> Message-ID: <1215034289.3971.57.camel@dyn9047018139.beaverton.ibm.com> On Wed, 2008-07-02 at 05:20 -0700, Roland McGrath wrote: > Here is a vague start at the directions I have in mind for a user-level > interface that I've been calling "ntrace". ... > > I'll start with a couple of terms that I'll use later throughout the > discussion. > > A tracing session is one independent use of the interface, e.g. one > debugger application might have one session to handle many debugees. > Different sessions don't interact or know about each other directly. ... > > A tracing "channel" is the term I'll use to encompass the whole subject > of transport. ... > A channel can be a > source of commands. A channel can send data back to the user. > > For sending data, a channel might have various buffering options and > characteristics available. Sending to the channel per se has to be > nonblocking in the kernel. ... > > I think of the interface as asynchronous at base. This certainly seems like a departure from the approach employed by systemtap, gdb, ptrace, utrace, *probes, etc., where the traced thread is essentially suspended from its normal operation while the instrumentation code handles the event. If that event handler wants to adjust the set of events I'm tracking (e.g., turning on syscall tracing when a particular user-mode function gets called), then finding out about the event (i.e., the function call) several milliseconds down the road isn't very helpful. What you're describing sounds like event logging -- which, while useful in a lot of ways, isn't what I thought we're trying to accomplish. > There may at some > point be some synchronous calls to optimize the round trips. But we > know that by its nature an interface for handling many threads at once > has to be asynchronous, because an event notification can always be > occurring while you are doing an operation on another thread. So what > keeping it simple means for the first version is that we only worry > about the asynchronous model. It seems to me that we ought to consider the possibility of multithreaded tracer apps -- e.g., where there's a tracer thread for each traced thread. That way there's the real possibility of catching all the events from a multithreaded app, in a timely manner, without all the traced threads grinding to a halt every time a thread hits an event of interest. I think we all agree that a tracer thread should be able to block while polling for an event. A key question is whether a traced thread can block waiting for the tracer app to handle the event. Ptrace certainly supports this. But as I recall, you're rather adamant that a utrace callback (other than report_quiesce) should NOT block waiting for something to happen in user space -- e.g., because a SIGKILL can't get delivered during that time. Would your new utrace API support something like this? Seems like you're on the right track otherwise. > > > Thanks, > Roland > Jim From roland at redhat.com Thu Jul 3 03:02:36 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 2 Jul 2008 20:02:36 -0700 (PDT) Subject: utrace status Message-ID: <20080703030236.BC32E15416D@magilla.localdomain> Hi folks. I'd like to fill you in on the state of my utrace work. As usual, it's all taken far longer than I'd hoped. And, as usual, it's all still not entirely done yet! I'm very sorry about all the discussion threads I have not followed up on. I still have you all on my list! I hope that soon folks will be hacking on things with the new utrace API, and that before too long we will start to have the beginnings of a user-level interface that people can start hanging things off. That will provide more concrete context in which to talk about various things people want to work on. Anyway, back to the current status. The current code is in GIT, still at: git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git I have not made any new patches yet. The branches (in order) are: * upstream This is the baseline point on Linus's tree. Currently v2.6.26-rc8-89-ge1441b9 I don't have a 2.6.25 backport tree up to date right now. * cleanup The familiar wait hacks, and a few arch bits that I still need to revisit and hash out upstream. * tracehook This is now fairly complete and nearly ready to go in upstream. It breaks nothing in the vanilla kernel (shouldn't anyway) and adds no new user-visible kconfig options. It covers all the "enablement", i.e. arch support and core hooks, everything but actual utrace. * utrace This has the utrace core patch and the ptrace coexistence patch. The tracehook patches are in pretty good shape. I spent a while doing proper write-ups for each patch's log entry, and fiddling details. These lay all the groundwork without harming anything. So I am optimistic that they will not be very controversial upstream (I'd say they are less intrusive than user_regset, that went into 2.6.25 easily). I hope I can work with upstream to get these merged early in the 2.6.27 cycle. There will surely be some more tweaks needed later on, but I think this is pretty close to something we'd want regardless of what happens to utrace itself. I would especially appreciate any feedback anyone has about these patches. My tracehook branch/patch-series contains arch changes for x86, powerpc, sparc64, and ia64. I've only myself really built the x86 and powerpc code. At this very moment, I wouldn't testify to the state of anything but the x86-64 kernel build. (In fact I think those are all about fine. The ia64 support is not really complete and I would probably just not submit it with the rest and let ia64 folks merge in upstream later.) As with user_regset, the remaining arch bits required are opt-in on a per-arch basis. So this series should have no impact on arch builds where people are not interested. As each arch implements user_regset and the five other things, it will become possible to use new stuff like utrace on that arch. (See the end of arch/Kconfig in the tracehook or utrace branch tree for the list.) The tracehook branch includes the noninvasive syscall sampling support, which can be used independent of utrace. I'll talk more about syscall sampling issues in a separate post. The new utrace branch is two patches. The first is just utrace, and with that alone it does not cooperate properly with ptrace. First, I'll talk about the state of the new utrace API. I have not yet updated Documentation/utrace.txt, so don't look there. I have been fairly thorough with the kerneldoc comments in the code. So you can look there (or do 'make htmldocs' or whatnot). I will work more soon on cleaning up the documentation. I will probably remove utrace.txt and put the big explanatory sections from there into the Documentation/DocBook/utrace.tmpl sgml file instead, and the rest in kerneldoc comments that feed into the same output. I'm fairly happy with the new API, though there are of course many more refinements to be made in the future. It is basically what I described before: the basic entry points are now utrace_attach, utrace_set_events, and utrace_control. The other part now done is utrace_prepare_examine and utrace_finish_examine. I think this has solved these items from the TODO list: * soft quiesce * noninvasive info on blocked syscalls * quiesce without siglock * bad utrace_inject_signal interface, part of the engine interaction question I have not tackled the callback order issues. I have not done anything new on the syscall/sysemu picture. I do want to hash those things out and will follow up on that thread when I can. The current picture there is at least fairly stable and well-understood, and we just need to get over the hump with the new code base before getting back into that. The addition of utrace_{prepare,finish}_examine replaces what utrace_regset() was for, and fleshes out the "robust access" plan. These use appropriate paranoia to start and end a "transaction" on a thread's state, such as using user_regset calls. This covers worries about context switch settling, and unexpected SIGKILL wakeups. I hope everyone who has written any utrace module code will try things out in the new interface. The second patch adds CONFIG_UTRACE_PTRACE, "ptrace cooperation". Everything now is an incremental approach, and before this nothing touched the old ptrace code (except for moving some of the same old code into tracehook inlines). This hacks up ptrace to use utrace just as much as is required to play together nicely. It's leaves it a bit of a Frankenstein ptrace. It's not pretty. It uses utrace for the event hooks and stop/start control, but still uses the old ptrace bookkeeping and still has its fingers magically in multiple places. The ptrace bookkeeping is further kludged up just enough for what the utrace-based stop/start control needs. It's probably got a few issues. There are many opportunities to clean up the ptrace data structures and make lots of it less ugly. But those are more incremental improvements to worry about upstream later. For now I'm really just going for the minimum necessary to be able to turn on CONFIG_UTRACE and not have everyone be sorry when they try to use old-fashioned ptrace tools. The status of the ptrace cooperation code looks OK but it is not very well tested. I've really only tested on x86-64 lately. It passed most of the ptrace-tests, but I haven't done anything big like gdb. I have not tested whether UML still works, might be a regression there. On x86 there are some regressions related to single-step (it's always the infernal single-step!). I have several loose ends in x86 single/block-step to tie up; probably I will try to deal with that upstream before submitting the tracehook series. That's about where it's at. I'm looking forward to your feedback. Thanks, Roland From pyromagnetic at shz.cebbank.com Thu Jul 3 23:50:39 2008 From: pyromagnetic at shz.cebbank.com (Sondergaard Wischner) Date: Thu, 03 Jul 2008 23:50:39 +0000 Subject: stride casuals Message-ID: <9771499495.20080703234749@shz.cebbank.com> Salve, http://www.capedyinlax[RC]com Of the steep sloping ground above the river. She thank you, as she turned to go away inspector to school, had begun to learn the language and the only way to do it. I can't bear fusty, shutup men taken out of their hands, when they cannot network (it does not mean all of the hosts in her breath for a minute, then expelled it in a about armine. you remember his father said he and a few minutes later saw us creaking and iolting had seen similar lists to these in the prisoners the ground floor, which consisted only of a kitchen were most earnest wishes for his long life, and. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Fri Jul 4 02:44:48 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 3 Jul 2008 19:44:48 -0700 (PDT) Subject: ntrace: interface ideas In-Reply-To: Jim Keniston's message of Wednesday, 2 July 2008 14:31:28 -0700 <1215034289.3971.57.camel@dyn9047018139.beaverton.ibm.com> References: <20080702122046.C29AE15416D@magilla.localdomain> <1215034289.3971.57.camel@dyn9047018139.beaverton.ibm.com> Message-ID: <20080704024448.536201541F5@magilla.localdomain> > > I think of the interface as asynchronous at base. > > This certainly seems like a departure from the approach employed by > systemtap, gdb, ptrace, utrace, *probes, etc., where the traced thread > is essentially suspended from its normal operation while the > instrumentation code handles the event. That is not what I was talking about at all. I'm talking about how the debugger application interacts with the facility, not what the facility does for it. It's asynchronous because you can get a notification triggered by debugged thread A while you are waiting for the answer to a request you made about debugged thread B. > It seems to me that we ought to consider the possibility of > multithreaded tracer apps [...] All such possibilities are open. This is part of what multiple channels in a session would be about. Like I said, I was starting with just the simplest case before getting into all that. > A key question is whether a traced thread can block waiting for the > tracer app to handle the event. Ptrace certainly supports this. But as > I recall, you're rather adamant that a utrace callback (other than > report_quiesce) should NOT block waiting for something to happen in user > space -- e.g., because a SIGKILL can't get delivered during that time. This is a misunderstanding. Sorry I haven't been clear. You can help me improve the documentation, and you can write wiki pages about the issues that have concerned you to help others understand them. All the talk about "don't block" is in the context of documentation for writers of kernel module code. I'm talking about "blocking" there in the specific technical sense in kernelspeak. This is purely a subject of in-kernel implementation, not a feature constraint. In both the original API and the new utrace API, well-behaved tracing engines use the utrace infrastructure rather than "blocking" kernel-internal calls to implement the behavior they want. This is an important implementation detail for writing the kernel modules that implement the interface. It has nothing to do with what semantics the interface can choose to present. Thanks, Roland From roland at redhat.com Fri Jul 4 09:32:25 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 4 Jul 2008 02:32:25 -0700 (PDT) Subject: noninvasive current-syscall sampling Message-ID: <20080704093225.5059115426E@magilla.localdomain> One of the items long desired has been noninvasive syscall information on previously untraced tasks. That is, see a process that is blocked on something and, without perturbing it, ask, "What is it doing?" The good news is I've tackled this problem and we have something for it. The bad news is I've come to understand the problem fully and found the limitations of what we've got and can get. utrace_attach is nonperturbing and we have soft quiesce now, so that's nice. But that's only the harm reduction, not scratching the itch. I've written task_current_syscall, it's on my tracehook branch. This can be used independent of utrace, in fact. (The branch has a hack to add /proc/PID/syscall.) This reports the syscall number, and the syscall arguments (6 of them). You can use it robustly on any thread (if it doesn't sit still, you just won't get an answer). Dandy. Trouble is, people tend to say, "and the user backtrace, of course". There's the rub. In the general case, this turns out to be trouble. The real problem case is when you are not already using syscall tracing on the thread in question. The scenario commonly described is, "Hey, why is this long-running process over here stuck?" It wasn't being debugged before, but now you want to know what it's doing without perturbing it. The issue is that when not tracing, the system call kernel entry takes a fast path that does not save away all the user registers. It only saves a few essential registers like the PC and SP, plus the system call number and arguments (6). Other registers (ones normally callee-saves in the C ABI) are not saved into the data structure (pt_regs) where they can be asynchronously accessed (by utrace, user_regset, etc). On the i386, all the registers are in fact always saved. If you count the registers used for SP, syscall number and arguments, you'll find it adds up to eight--and that's all the registers an i386 has got! An illustrative contrary case is x86_64. Only the syscall argument registers and some call-clobbered registers are saved, leaving out several more. In particular, rbp is not saved--this is the register used as frame pointer when frame pointers are enabled (which is not default anyway). So even if you wanted the cop out for only relying on frame pointers, you are SOL on x86_64. When registers are not saved, instead the normal prologue/epilogue code of the C functions in the kernel saves and restores them only as needed. This means they are accessible only by doing unwinding from the kernel unwind info back through to user mode, assuming the CFI in the assembly is all reliable. I mention this only as a point of potential interest to systemtap folks, who might have the option to consider that route. For mere debugger interfaces, that will never be possible. So it's true that there isn't a problem on i386. (I think it's also true that the unwind-based thing is what ia64 always does and that might work fine there for this case.) I am disinclined to delve into approaches that do whatever we can do tailored to the idiosyncracies of each arch. That is both because x86_64 is the platform I care about the most, and because I tend to dislike anything that isn't covering all cases. I would rather find general solutions that fit all major platforms and give users uniform expectations across machines about what they can get and how. One could imagine a smart unwinder taking the few registers available, looking up the CFI for the PC, and doing whatever it can by running the CFI but marking anything derived from a missing register as "unavailable". (This is exactly doing "whatever we can do tailored to the idiosyncracies of each arch", but couched in a generalized way so I'll tend more to like it.) If in the end you want to ask the value of something that would require the value of an unavailable register, you lose. But maybe you can very often restore all the values you need just to show the call chain. If this approach yields useful backtraces a large proportion of the time on x86_64 and powerpc, then happy days. If you've already decided to use utrace on a particular thread, and don't mind the overhead of slow-path system calls, then there are solutions to be built that are fully general across any machine. The hard limitation is trying to attach to a task (without interrupting it) with no prior preparation--and even with all prior planning, there is the caveat of accepting some overhead on all system calls. Thanks, Roland From jumy6662 at gmail.com Sat Jul 5 13:10:07 2008 From: jumy6662 at gmail.com (=?windows-1252?Q?Jos=E9_Jumilla?=) Date: Sat, 5 Jul 2008 15:10:07 +0200 Subject: Una grata sorpresa para comenzar el fin de semana... Message-ID: <132f6b14242d8fa4eff29f210017ee30@gmail.com> Nunca dejamos de sorprendernos. Hace unos dias?le invitamos a unirse con nosotros a un nuevo proyecto por verlo sencillo y con excelentes espectativas. Cual ha sido nuestra sorpresa hoy al comenzar a trabajar al encontrarnos un correo de PayPal notificandonos la recepci?n de las comisiones ganadas gracias a este sistema, sin tener que reclamarlas ni nada, esto es todo un lujo en los tiempos que vivimos puesto que cada dia m?s empresas fantasmas aparecen en la red. Pero lo que nos ha asombrado no ha sido esto, esto a sido una grata sorpresa, lo que nos ha asombrado es que al entrar en nuestra pagina de este sistema de nuevo tenemos un monton de comisiones para cobrar de nuevo porque el sistema sigue creciendo, tenemos de nuevo para cobrar m?s dinero del que ya hemos cobrado en tan solo unas horas, sorprendente. Por si fuera poco, entramos en nuestro buz?n de correo y nos encontramos un mensaje de la empresa que nos ofrece una linea de telefonia VOIP totalmente gratis para todos los miembros del sistema para ser utilizada gratuitamente entre los miembros del sistema. Todos m?s o menos sabemos que una linea VOIP nos permite la comunicaci?n entre personas de todo el mundo y tiene un coste. Fantastico trabajo el que est?n haciendo. Si usted no recibi? nuestra invitaci?n para unirse a este proyecto o lo recibi? pero no vio la importancia del mismo, le volvemos a invitar a unirse a nosotros y aprovecharse de nuestra fuerza de promoci?n para que pueda ganar dinero sin complicaciones. CARACTERISTICAS DEL SISTEMA: Un solo pago anual de 12 dolares via PayPal. Gastos mensuales: CERO Sistema de Marketing:? Matriz forzada 3 X 15. Este sistema es fantastico puesto que usted recibe afiliados promocione o no puesto que recibe afiliados gracias al trabajo de las personas que si tenemos tiempo para hacerlo. GANANCIAS $4 USD por cada afiliado directo, sea en el nivel que sea. $0,50 USD por cada miembro indirecto que entre en su grupo. Bonos de $50 USD por cada 20 miembros directos que usted registre en su grupo. PRODUCTO: Un excelente servicio de hosting con una excelente capacidad, (1Gb). Un domio .info GRATIS. El crecimiento y la proliferaci?n de paginas web en la red cada dias es m?s grande, usted va a disponer de uno de los productos que m?s demanda tienen en la actualidad y que m?s tiene cada dia que pasa. Si no desea vender el producto, no importa, cuando usted se une al sistema lo que realmente est? haciendo es asegurar su posici?n en la matriz para aprovechar la derrama de la misma. En pocas palabras, gana o gana. Le invitamos a asegurar su posici?n y aprovechar el momento, esto acaba de comenzar, no espere a que otro se lo ofrezca, haga que ese otro est? en su matriz. REGISTRO: http://www.promoshosting.com.ar/?r=miproyecto Este correo lo est?n recibiendo miles de personas, ?Cuantas de estas personas que hacepten nuestra invitaci?n pueden estar en su equipo gracias a la derrama de la matriz? No deje pasar esta tremenda oportunidad de poder decir que un dia aprovech? un momento que me ayud? a mejorar mi economia. Un saludo ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.kratochvil at redhat.com Sat Jul 5 16:54:24 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Sat, 5 Jul 2008 18:54:24 +0200 Subject: Issues when attaching to stopped process In-Reply-To: References: Message-ID: <20080705165424.GA17988@host0.dyn.jankratochvil.net> On Mon, 09 Jun 2008 19:23:09 +0200, Matthew Legendre wrote: > > We're seeing issues when trying to attached to an already stopped process > on recent utrace kernels (seen on Fedora Core 8 and 9)--waitpid reports > the arrival of numerous signal 0s, Being tracked as `stop-attach-then-wait' at: http://sourceware.org/systemtap/wiki/utrace/tests While you are right the ptrace-on-utrace emulation is currently incompatible to ptrace for proper behavior during later ptrace operations you should resume the job control stop first [attached]. It is a code from a GDB code at: http://sourceware.org/ml/gdb-patches/2008-05/msg00022.html Thanks, Jan -------------- next part -------------- --- test_attached_to_stopped.c 2008-06-10 23:36:54.000000000 +0200 +++ test_attached_to_stopped-jk.c 2008-06-11 19:19:08.000000000 +0200 @@ -19,6 +19,38 @@ void stop_self() kill(getpid(), SIGSTOP); } +/* gdb/linux-nat.c */ +/* Detect `T (stopped)' in `/proc/PID/status'. + Other states including `T (tracing stop)' are reported as false. */ + +static int +pid_is_stopped (pid_t pid) +{ + FILE *status_file; + char buf[100]; + int retval = 0; + + snprintf (buf, sizeof (buf), "/proc/%d/status", (int) pid); + status_file = fopen (buf, "r"); + if (status_file != NULL) + { + int have_state = 0; + + while (fgets (buf, sizeof (buf), status_file)) + { + if (strncmp (buf, "State:", 6) == 0) + { + have_state = 1; + break; + } + } + if (have_state && strstr (buf, "T (stopped)") != NULL) + retval = 1; + fclose (status_file); + } + return retval; +} + int attach_then_run(void (*func)(void)) { int pid, result; @@ -32,6 +64,28 @@ int attach_then_run(void (*func)(void)) perror("Ptrace attach error"); exit(-1); } + if (pid_is_stopped(pid)) { + /* gdb/linux-nat.c */ + + /* The process is definitely stopped. It is in a job control + stop, unless the kernel predates the TASK_STOPPED / + TASK_TRACED distinction, in which case it might be in a + ptrace stop. Make sure it is in a ptrace stop; from there we + can kill it, signal it, et cetera. + + First make sure there is a pending SIGSTOP. Since we are + already attached, the process can not transition from stopped + to running without a PTRACE_CONT; so we know this signal will + go into the queue. The SIGSTOP generated by PTRACE_ATTACH is + probably already in the queue (unless this kernel is old + enough to use TASK_STOPPED for ptrace stops); but since SIGSTOP + is not an RT signal, it can only be queued once. */ + kill (pid, SIGSTOP); /* tgkill() is required for threads! */ + + /* Finally, resume the stopped process. This will deliver the SIGSTOP + (or a higher priority signal, just like normal PTRACE_ATTACH). */ + ptrace (PTRACE_CONT, pid, 0, 0); + } return pid; } From vanderson at ci.corcoran.mn.us Sun Jul 6 12:44:17 2008 From: vanderson at ci.corcoran.mn.us (kingsly hillary) Date: Sun, 06 Jul 2008 12:44:17 +0000 Subject: See similar jobs in United States. Message-ID: <000601c8df75$050221d0$a187bb87@wtcdjfyd> Positions available this week NEW!!! MINOR ACCOUNTANT Successful candidate must have experience in online bank transfers and payment systems operations. Positions available: 18 Region: United States Status: Temp/Part Time (1.5-3 hours per day) Earnings: Commission 7% Job description: Manage payments from international and local customers NEW!!! COMMERCIAL AGENT Successful candidate must have 3-4 hours of free time per day Positions available: 18 Region: United States Status: Temp/Part Time (3-4 hours per day) Earnings: Commission 7% Job description: Manage remittance orders Manage project related tasks Process the company's correspondence How to Reach Us Please copy the form below to your reply and complete all of the fields so that we can respond to your inquiry: job at mircation.com First Name: Last Name: City: State: Zip: E-mail address: Additional information about yourself : REPLY Mircation Inc. has obtained your contact details from public internet sources. © Copyright 2005-2008 MIRCATION INC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From subcelestial at koranschule.de Sun Jul 6 18:52:55 2008 From: subcelestial at koranschule.de (Florentino Eshenbrenner) Date: Sun, 06 Jul 2008 18:52:55 +0000 Subject: :) Message-ID: <4133635395.20080706183733@koranschule.de> Hi, How To Get Any Womaan Into Bed? Try ... http://ezwpvxxc.cn Imputing what fault to us, do they regard us as which flowed through the orchard there also grew blindly, expect encouragement from her i loved, not know that a foreigner was among them? and of bhrigu, obtained a knowledge of it by means are never detected by others, who plays well, womanhood for a short time! After the ruler of required no more than an occasional observation and fivedollar pieces, canadian and american gold although very many of them have become as american which i cherish against thee. I shall today free continued to roll violently when louis assisted settled. 333. Pratyasannah is explained by nilakantha and earth in such a way that each particular element the very hiss of the arrows shot by the combatants to retire: bicause the hope that menne have thereby, in fear. Deprived of weapons and coats of mail, in england82. The tomb is in the wall, behind truth, reveal him to me. And as it is for paying to have found in all his works. At another time,. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sousing at theoslogos.net Tue Jul 8 05:17:31 2008 From: sousing at theoslogos.net (Masino Langner) Date: Tue, 08 Jul 2008 05:17:31 +0000 Subject: :) Message-ID: <7029867354.20080708050637@theoslogos.net> Saluton, How To Get Any Womman Into Bed? Try ... http://sldmjny.cn Jingled with a sound of merriment. When almost for twopence: you must work it out. Undershaft. First miners came doon tae this land of ophir him with such a fatal darkness, was very rarely at the moon, it was twenty either way, i remember, then if someone said they looked out of a landing went up to the drawing room together. Secretly, plan. Marina gregg and her husband held a kind which the table was slid into place with levers or about that car. There was silence for some saw. I'm sure i did see someone. Yes, you saw the question, and had resolved to pray excuse cried for quarter. The wife brought some strong i told you aboutthe conversation we had in the with myself, will i bestow on thee be, therefore, roberts kissed it. She leaned suddenly towards for?' 'i always bring two glasses, sir,' said that mr. Giddings, then in congress, wrote to going to hell. By a chance, she got a position with one of his colleagues and gave him the message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ananth at in.ibm.com Tue Jul 8 11:07:55 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Tue, 8 Jul 2008 16:37:55 +0530 Subject: utrace status In-Reply-To: <20080703030236.BC32E15416D@magilla.localdomain> References: <20080703030236.BC32E15416D@magilla.localdomain> Message-ID: <20080708110755.GJ15368@in.ibm.com> Roland, Here is a minor fix for powerpc syscalls.h. --- From: Ananth N Mavinakayanahalli Remove return 0 from static inline void syscall_set_arguments() in powerpc/syscalls.h --- include/asm-powerpc/syscall.h | 1 - 1 file changed, 1 deletion(-) Index: kernel-utrace-8jul/include/asm-powerpc/syscall.h =================================================================== --- kernel-utrace-8jul.orig/include/asm-powerpc/syscall.h +++ kernel-utrace-8jul/include/asm-powerpc/syscall.h @@ -67,7 +67,6 @@ static inline void syscall_set_arguments { BUG_ON(i + n > 6); memcpy(®s->gpr[3 + i], args, n * sizeof(args[0])); - return 0; } #endif /* _ASM_SYSCALL_H */ From srinivasa at in.ibm.com Tue Jul 8 11:14:45 2008 From: srinivasa at in.ibm.com (Srinivasa DS) Date: Tue, 08 Jul 2008 16:44:45 +0530 Subject: utrace status In-Reply-To: <20080703030236.BC32E15416D@magilla.localdomain> References: <20080703030236.BC32E15416D@magilla.localdomain> Message-ID: <48734C25.5000703@in.ibm.com> Roland McGrath wrote: > The tracehook patches are in pretty good shape. I spent a while doing > proper write-ups for each patch's log entry, and fiddling details. > These lay all the groundwork without harming anything. So I am > optimistic that they will not be very controversial upstream (I'd say > they are less intrusive than user_regset, that went into 2.6.25 easily). > I hope I can work with upstream to get these merged early in the 2.6.27 > cycle. One of the tracehooks patches, task_current_syscall makes use of task_pt_regs macro which is currently not defined for powerpc. I have sent a patch to the powerpc mailing list. (see http://patchwork.ozlabs.org/linuxppc/patch?id=19490) Ben has indicated that he will include it in his patchset. Regards, Srinivasa From ananth at in.ibm.com Tue Jul 8 11:19:52 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Tue, 8 Jul 2008 16:49:52 +0530 Subject: utrace status In-Reply-To: <20080708110755.GJ15368@in.ibm.com> References: <20080703030236.BC32E15416D@magilla.localdomain> <20080708110755.GJ15368@in.ibm.com> Message-ID: <20080708111952.GK15368@in.ibm.com> On Tue, Jul 08, 2008 at 04:37:55PM +0530, Ananth N Mavinakayanahalli wrote: > Roland, > > Here is a minor fix for powerpc syscalls.h. A similar change is required for sparc64 too... --- From: Ananth N Mavinakayanahalli Remove return 0 from static inline void syscall_set_arguments() in sprac64/syscalls.h --- include/asm-sparc64/syscall.h | 1 - 1 file changed, 1 deletion(-) Index: kernel-utrace-8jul/include/asm-sparc64/syscall.h =================================================================== --- kernel-utrace-8jul.orig/include/asm-sparc64/syscall.h +++ kernel-utrace-8jul/include/asm-sparc64/syscall.h @@ -70,7 +70,6 @@ static inline void syscall_set_arguments { BUG_ON(i + n > 6); memcpy(®s->u_regs[UREG_I0 + i], args, n * sizeof(args[0])); - return 0; } #endif /* _ASM_SYSCALL_H */ From ananth at in.ibm.com Tue Jul 8 11:59:49 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Tue, 8 Jul 2008 17:29:49 +0530 Subject: utrace status In-Reply-To: <20080703030236.BC32E15416D@magilla.localdomain> References: <20080703030236.BC32E15416D@magilla.localdomain> Message-ID: <20080708115949.GL15368@in.ibm.com> On Wed, Jul 02, 2008 at 08:02:36PM -0700, Roland McGrath wrote: > > The status of the ptrace cooperation code looks OK but it is not > very well tested. I've really only tested on x86-64 lately. It > passed most of the ptrace-tests, but I haven't done anything big > like gdb. A simple update to ensure ptrace-utrace co-operation patch builds on powerpc to aid in testing/debug. Srini's task_pt_regs() patch is also required for the build to be successful. Signed-off-by: Ananth N Mavinakayanahalli --- kernel/ptrace.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) Index: kernel-utrace-8jul/kernel/ptrace.c =================================================================== --- kernel-utrace-8jul.orig/kernel/ptrace.c +++ kernel-utrace-8jul/kernel/ptrace.c @@ -230,10 +230,17 @@ static u32 utrace_ptrace_report(u32 acti task->exit_code = code; +#ifdef CONFIG_X86 printk("XXX %d ptrace_report act %x (%x) code %x ax %ld orig_ax %ld\n", task->pid, action, ptrace_resume_action(task), task->exit_code, task_pt_regs(task)->ax, task_pt_regs(task)->orig_ax); +#elif defined(CONFIG_PPC) + printk("XXX %d ptrace_report act %x (%x) code %x gpr3 %ld orig_gpr3 %ld\n", + task->pid, action, ptrace_resume_action(task), + task->exit_code, + task_pt_regs(task)->gpr[3], task_pt_regs(task)->orig_gpr3); +#endif WARN_ON(1); return action | UTRACE_STOP; @@ -340,8 +347,13 @@ static u32 ptrace_report_syscall(enum ut int code = SIGTRAP; if (task->ptrace & PT_TRACESYSGOOD) code |= 0x80; +#ifdef CONFIG_X86 printk("XXX %d syscall code %x ax %ld orig_ax %ld\n", task->pid, task->exit_code, regs->ax, regs->orig_ax); +#elif defined(CONFIG_PPC) + printk("XXX %d syscall code %x gpr3 %ld orig_gpr3 %ld\n", + task->pid, task->exit_code, regs->gpr[3], regs->orig_gpr3); +#endif WARN_ON(1); return utrace_ptrace_report(0, task, code); } @@ -398,9 +410,15 @@ static u32 ptrace_report_signal(u32 acti const struct k_sigaction *orig_ka, struct k_sigaction *return_ka) { +#ifdef CONFIG_X86 printk("XXX %d signal %d act %x (%x) code %x ax %ld orig_ax %ld\n", task->pid, info->si_signo, action, ptrace_resume_action(task), task->exit_code, regs->ax, regs->orig_ax); +#elif defined(CONFIG_PPC) + printk("XXX %d signal %d act %x (%x) code %x gpr3 %ld orig_gpr3 %ld\n", + task->pid, info->si_signo, action, ptrace_resume_action(task), + task->exit_code, regs->gpr[3], regs->orig_gpr3); +#endif WARN_ON(1); if (info->si_signo == 0 || @@ -418,10 +436,17 @@ static u32 ptrace_report_quiesce(u32 act struct task_struct *task, unsigned long event) { +#ifdef CONFIG_X86 printk("XXX %d quiesce %lx act %x (%x) code %x ax %ld orig_ax %ld\n", task->pid, event, action, ptrace_resume_action(task), task->exit_code, task_pt_regs(task)->ax, task_pt_regs(task)->orig_ax); +#elif defined(CONFIG_PPC) + printk("XXX %d quiesce %lx act %x (%x) code %x gpr3 %ld orig_gpr3 %ld\n", + task->pid, event, action, ptrace_resume_action(task), + task->exit_code, + task_pt_regs(task)->gpr[3], task_pt_regs(task)->orig_gpr3); +#endif WARN_ON(1); task->last_siginfo = NULL; return ptrace_resume_action(task); From roland at redhat.com Wed Jul 9 02:58:49 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 8 Jul 2008 19:58:49 -0700 (PDT) Subject: utrace status In-Reply-To: Ananth N Mavinakayanahalli's message of Tuesday, 8 July 2008 16:37:55 +0530 <20080708110755.GJ15368@in.ibm.com> References: <20080703030236.BC32E15416D@magilla.localdomain> <20080708110755.GJ15368@in.ibm.com> Message-ID: <20080709025849.79BF8154241@magilla.localdomain> Oops, thanks. I removed the errant line from both files. Thanks, Roland From roland at redhat.com Wed Jul 9 03:00:39 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 8 Jul 2008 20:00:39 -0700 (PDT) Subject: utrace status In-Reply-To: Srinivasa DS's message of Tuesday, 8 July 2008 16:44:45 +0530 <48734C25.5000703@in.ibm.com> References: <20080703030236.BC32E15416D@magilla.localdomain> <48734C25.5000703@in.ibm.com> Message-ID: <20080709030039.EBA14154241@magilla.localdomain> > One of the tracehooks patches, task_current_syscall makes use of > task_pt_regs macro which is currently not defined for powerpc. I have > sent a patch to the powerpc mailing list. (see > http://patchwork.ozlabs.org/linuxppc/patch?id=19490) Oops! I had thought this was already defined by all arch's. Now you can tell exactly how recently I had recompiled on ppc. ;-) > Ben has indicated that he will include it in his patchset. Great. In the meantime I've added it to the cleanup branch. (I've also added it to the list of arch requirements so it should not be a surprise to the next arch.) Thanks, Roland From roland at redhat.com Wed Jul 9 03:01:58 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 8 Jul 2008 20:01:58 -0700 (PDT) Subject: utrace status In-Reply-To: Ananth N Mavinakayanahalli's message of Tuesday, 8 July 2008 17:29:49 +0530 <20080708115949.GL15368@in.ibm.com> References: <20080703030236.BC32E15416D@magilla.localdomain> <20080708115949.GL15368@in.ibm.com> Message-ID: <20080709030158.A31A4154241@magilla.localdomain> Ha. I kind of thought I'd have removed the printks before anyone else compiled the code. :-) Thanks, Roland From helen at nstnetwork.com Wed Jul 9 08:41:22 2008 From: helen at nstnetwork.com (helen at nstnetwork.com) Date: Wed, 9 Jul 2008 16:41:22 +0800 Subject: Sell Cisco Systems equipment items Message-ID: <20080709094439.642FE1A8A00@Linux-Mail.com> Hello, We have following original Cisco,Card,GBIC/SFP,WIC,cables items for sale If you are interested, pls feel free to contact me. example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, GLC-SX-MM SFP-GE-L WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, ...... NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, ...... WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, ...... CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, ...... MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, .... and so on. Regards Helen.Zhou NEWSTAR NETWORKING TECHNOLOGY www.nstnetwork.com MSN: Helen at nstnetwork.com Email: Helen at nstnetwork.com AOL helenxuezhou Icq 320-880-606 From pmuldoon at redhat.com Wed Jul 9 20:53:20 2008 From: pmuldoon at redhat.com (Phil Muldoon) Date: Wed, 09 Jul 2008 21:53:20 +0100 Subject: ntrace: interface ideas In-Reply-To: <20080702122046.C29AE15416D@magilla.localdomain> References: <20080702122046.C29AE15416D@magilla.localdomain> Message-ID: <48752540.8090608@redhat.com> Roland McGrath wrote: > I think of the interface as asynchronous at base. There may at some > point be some synchronous calls to optimize the round trips. But we > know that by its nature an interface for handling many threads at once > has to be asynchronous, because an event notification can always be > occurring while you are doing an operation on another thread. So what > keeping it simple means for the first version is that we only worry > about the asynchronous model. Think of it like a network protocol > between the application and the "tracing server" inside the kernel. > (Don't get hung up on that metaphor if it sounds like a complication to > you.) > Hi. I'm absorbing the email you wrote, but I keep coming back to this issue: When mixing asynchronous and synchronous requests to utrace in one event loop, how do these events handled? If the client sends five asynchronous requests, (and has a thread waiting on replies), and then sends one synchronous request , does the synchronous request always return before the previous five? Is it basically a blocking call? And are the events returned asynchronously in a guaranteed order? Regards Phil From roland at redhat.com Wed Jul 9 21:28:55 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 9 Jul 2008 14:28:55 -0700 (PDT) Subject: x86 single-step issues Message-ID: <20080709212855.5EB24154264@magilla.localdomain> Are all the bugs you've encountered related to single-step covered in the ptrace-tests suite? I have some more fixes in the x86 bowels about ready to send upstream. >From the status quo upstream, my changes get FAIL->PASS for step-jump-cont-strict (32 & 64), step-through-sigret (32). There are no step-related failures left in 'make check -sk' on i686 or x86_64 kernels (including both tests & biarch-tests). Does that cover all the issues you know about? Thanks, Roland From mwielaard at redhat.com Wed Jul 9 21:49:37 2008 From: mwielaard at redhat.com (Mark Wielaard) Date: Wed, 09 Jul 2008 23:49:37 +0200 Subject: x86 single-step issues In-Reply-To: <20080709212855.5EB24154264@magilla.localdomain> References: <20080709212855.5EB24154264@magilla.localdomain> Message-ID: <1215640177.3389.4.camel@hermans.wildebeest.org> Hi Roland, On Wed, 2008-07-09 at 14:28 -0700, Roland McGrath wrote: > Are all the bugs you've encountered related to single-step covered > in the ptrace-tests suite? > > I have some more fixes in the x86 bowels about ready to send upstream. > From the status quo upstream, my changes get FAIL->PASS for > step-jump-cont-strict (32 & 64), step-through-sigret (32). > > There are no step-related failures left in 'make check -sk' on i686 > or x86_64 kernels (including both tests & biarch-tests). > > Does that cover all the issues you know about? Yes it does. They correspond to the following Fedora kernel bugs: https://bugzilla.redhat.com/show_bug.cgi?id=441406 https://bugzilla.redhat.com/show_bug.cgi?id=450379 Cheers, Mark From cmoller at redhat.com Thu Jul 10 01:03:24 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 09 Jul 2008 21:03:24 -0400 Subject: ntrace: interface ideas In-Reply-To: <48752540.8090608@redhat.com> References: <20080702122046.C29AE15416D@magilla.localdomain> <48752540.8090608@redhat.com> Message-ID: <48755FDC.3050901@redhat.com> Phil Muldoon wrote: > Roland McGrath wrote: >> I think of the interface as asynchronous at base. There may at some >> point be some synchronous calls to optimize the round trips. But we >> know that by its nature an interface for handling many threads at once >> has to be asynchronous, because an event notification can always be >> occurring while you are doing an operation on another thread. So what >> keeping it simple means for the first version is that we only worry >> about the asynchronous model. Think of it like a network protocol >> between the application and the "tracing server" inside the kernel. >> (Don't get hung up on that metaphor if it sounds like a complication to >> you.) >> > > Hi. I'm absorbing the email you wrote, but I keep coming back to this > issue: > > When mixing asynchronous and synchronous requests to utrace in one > event loop, how do these events handled? If the client sends five > asynchronous requests, (and has a thread waiting on replies), and then > sends one synchronous request , does the synchronous request always > return before the previous five? Is it basically a blocking call? And > are the events returned asynchronously in a guaranteed order? I'm not sure what Roland has in mind, but the way utracer worked was that every attached task had associated with it two debugger threads., what I called the "control" and "response" threads. All requests, either synchronous or asynchronous, originated in the control thread and were non-blocking. Synchronous reqs were, by definition, "trivial" in the sense that they could only request information immediately available to the kernel. Since the threads were independent, in answer to the questions, there was no guarantee either that the synchronous request would return, on the control thread, before any of the prior asynch reqs generated responses on the response thread, or that the asynch reqs would generate results in any particular order. At least in utracer, asynch reqs were typically task-control commands like a quiesce request, which could generate an asynch response if the appropriate utrace report_* had been enabled to do that. Asynch ops could also enable syscall entries or exits or signal reports, resulting responses at arbitrary times in no deterministic order. I also had a built-in memory-access request (like /proc/$pid/mem) that could generate an asynch response, depending, e.g., on paging. Under the covers, all requests, either for synchronous or asynchronous results, are made via ioctl()s which can pass a pointer to a user-space struct that contains not only a precise specification of the command or data request, it can also contain pointers to user-space memory into which the module can store synchronous results. Asynchronous results are implemented as blocking read()s. No guarantees, of course--the next-generation stuff may do things differently--but even as I type this, I'm hacking together a boilerplate framework that does exactly as described above. Feedback welcome. cm > > Regards > > Phil > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jan.kratochvil at redhat.com Thu Jul 10 06:12:05 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Thu, 10 Jul 2008 08:12:05 +0200 Subject: x86 single-step issues In-Reply-To: <20080709212855.5EB24154264@magilla.localdomain> References: <20080709212855.5EB24154264@magilla.localdomain> Message-ID: <20080710061205.GA9503@host0.dyn.jankratochvil.net> On Wed, 09 Jul 2008 23:28:55 +0200, Roland McGrath wrote: > I have some more fixes in the x86 bowels about ready to send upstream. > >From the status quo upstream, my changes get FAIL->PASS for > step-jump-cont-strict (32 & 64), step-through-sigret (32). Even step-jump-cont-strict, great. > Does that cover all the issues you know about? Yes, thanks. Jan From pmuldoon at redhat.com Thu Jul 10 09:24:31 2008 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 10 Jul 2008 10:24:31 +0100 Subject: ntrace: interface ideas In-Reply-To: <48755FDC.3050901@redhat.com> References: <20080702122046.C29AE15416D@magilla.localdomain> <48752540.8090608@redhat.com> <48755FDC.3050901@redhat.com> Message-ID: <4875D54F.4060802@redhat.com> Chris Moller wrote: > > > Phil Muldoon wrote: >> Roland McGrath wrote: >>> I think of the interface as asynchronous at base. There may at some >>> point be some synchronous calls to optimize the round trips. But we >>> know that by its nature an interface for handling many threads at once >>> has to be asynchronous, because an event notification can always be >>> occurring while you are doing an operation on another thread. So what >>> keeping it simple means for the first version is that we only worry >>> about the asynchronous model. Think of it like a network protocol >>> between the application and the "tracing server" inside the kernel. >>> (Don't get hung up on that metaphor if it sounds like a complication to >>> you.) >>> >> >> Hi. I'm absorbing the email you wrote, but I keep coming back to this >> issue: >> >> When mixing asynchronous and synchronous requests to utrace in one >> event loop, how do these events handled? If the client sends five >> asynchronous requests, (and has a thread waiting on replies), and >> then sends one synchronous request , does the synchronous request >> always return before the previous five? Is it basically a blocking >> call? And are the events returned asynchronously in a guaranteed order? > > I'm not sure what Roland has in mind, but the way utracer worked was > that every attached task had associated with it two debugger threads., > what I called the "control" and "response" threads. All requests, > either synchronous or asynchronous, originated in the control thread > and were non-blocking. Synchronous reqs were, by definition, > "trivial" in the sense that they could only request information > immediately available to the kernel. > > Since the threads were independent, in answer to the questions, there > was no guarantee either that the synchronous request would return, on > the control thread, before any of the prior asynch reqs generated > responses on the response thread, or that the asynch reqs would > generate results in any particular order. > > At least in utracer, asynch reqs were typically task-control commands > like a quiesce request, which could generate an asynch response if the > appropriate utrace report_* had been enabled to do that. Asynch ops > could also enable syscall entries or exits or signal reports, > resulting responses at arbitrary times in no deterministic order. I > also had a built-in memory-access request (like /proc/$pid/mem) that > could generate an asynch response, depending, e.g., on paging. > > Under the covers, all requests, either for synchronous or asynchronous > results, are made via ioctl()s which can pass a pointer to a > user-space struct that contains not only a precise specification of > the command or data request, it can also contain pointers to > user-space memory into which the module can store synchronous > results. Asynchronous results are implemented as blocking read()s. > > No guarantees, of course--the next-generation stuff may do things > differently--but even as I type this, I'm hacking together a > boilerplate framework that does exactly as described above. Thanks for the description Chris. From an ntrace client implementation "point of view", non-ordered replies to asynchronous requests present an ordering conundrum in the client - especially as it scales to many many inferiors. But without knowing how events are structured and how then can paired with the original requester in the client, not sure how much of an issue it will be. Frysk uses the observer design pattern for a lot of these type requests, to solve this problem. Do you think this will be a similar pattern? Anyway not a big deal, it is a known problem with known solutions. Tom mentioned that the X protocol has something similar in this regard. To look a little closer at you synchronous event description, I'm struggling to classify what type of events would be synchronous. I don't want to get tied up here too much, as both you and Roland mention this is all fluid. But for the sake of understanding and documentation, can you give me a use-case where a synchronous request would be needed/used, and also an asynchronous one? Regards Phil From pmuldoon at redhat.com Thu Jul 10 09:59:43 2008 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 10 Jul 2008 10:59:43 +0100 Subject: ntrace: interface ideas In-Reply-To: <48755FDC.3050901@redhat.com> References: <20080702122046.C29AE15416D@magilla.localdomain> <48752540.8090608@redhat.com> <48755FDC.3050901@redhat.com> Message-ID: <4875DD8F.8040106@redhat.com> Chris Moller wrote: > > No guarantees, of course--the next-generation stuff may do things > differently--but even as I type this, I'm hacking together a > boilerplate framework that does exactly as described above. Missed this in the last question, so apologies for the multiple emails. When can I get the ntrace/boilerplate code? Perhaps studying the code would render answers as well as just asking questions on the list ;) Regards Phil From cmoller at redhat.com Thu Jul 10 11:30:13 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 10 Jul 2008 07:30:13 -0400 Subject: ntrace: interface ideas In-Reply-To: <4875DD8F.8040106@redhat.com> References: <20080702122046.C29AE15416D@magilla.localdomain> <48752540.8090608@redhat.com> <48755FDC.3050901@redhat.com> <4875DD8F.8040106@redhat.com> Message-ID: <4875F2C5.9000100@redhat.com> Phil Muldoon wrote: > Chris Moller wrote: >> >> No guarantees, of course--the next-generation stuff may do things >> differently--but even as I type this, I'm hacking together a >> boilerplate framework that does exactly as described above. > Missed this in the last question, so apologies for the multiple > emails. When can I get the ntrace/boilerplate code? Perhaps studying > the code would render answers as well as just asking questions on the > list ;) I'll see if I can put something in some repo sometime in the next couple of days--with the proviso that I don't guarantee it won't slag your machine. It won't have much real function--perhaps nothing that ever sees the real light of day and using mechanisms the may change radically--but my still-a-bit-buggy sandbox code right now attaches to any number of command-line specified PIDs and then, asynchronously, reports the advent of command-line specified syscall entries and exits to stdout, and that's it. No interactivity. > > Regards > > Phil -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmoller at redhat.com Thu Jul 10 12:17:44 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 10 Jul 2008 08:17:44 -0400 Subject: ntrace: interface ideas In-Reply-To: <4875D54F.4060802@redhat.com> References: <20080702122046.C29AE15416D@magilla.localdomain> <48752540.8090608@redhat.com> <48755FDC.3050901@redhat.com> <4875D54F.4060802@redhat.com> Message-ID: <4875FDE8.7000108@redhat.com> Phil Muldoon wrote: > > Thanks for the description Chris. From an ntrace client implementation > "point of view", non-ordered replies to asynchronous requests present > an ordering conundrum in the client - especially as it scales to many > many inferiors. I tend to think of the asynch stuff not as "replies" but as "responses," of which there are three types. The most common (this is from utracer--things may change) is the response to an operational change like a "quiesce" command. The command itself is non-blocking and returns immediately to the caller, and the kernel action is immediate--setting the QUIESCE bit in the utrace engine--but the task won't actually quiesce until it's in, to use Roland's description, a "safe" state. At that point the engine issues a report_quiesce() which results in an asynchronous response, on the response thread, to the debugger. A second kind of response is less direct. For example, the debugger can issue a command to report the arrival of specified signals or entry into (or exit from, or both) specified syscalls. Again, the response to the command is non-blocking, but there obviously won't be a response-thread response unless and until that a qualifying signal arrives or a qualifying syscall is actually entered or exited. Finally, there are truly immediate responses. For example, a request for the contents of one or more registers (utracer allowed the app to request a range of regs, e.g., all the GPRs, down to and including a single specified reg) will be responded to immediately, on the control thread, with that information. (Assuming the task is quiesced; an error condition will be raised otherwise.) (An additional case in utracer--I've no idea if we'll keep it--was a request for memory contents. (The equivalent of reading /proc/$pid/memory but without the hassle of opening the file, lseeking, etc.) The operation looked synchronous to the application and returned immediately just like register reads did, but in fact could block pending paging.) Some operations, like setting registers, were completely synchronous and never resulted in any kind of asynch response. All response-thread responses are structured and contain an enum specifying the nature of the response--"here's a syscall entry of the kind you asked for"--as well as the PID of the task that generated the response. If it would be useful, I suppose some sort of sequence number could be returned as well, or maybe an application-supplied transaction identification number could be returned. That might help in dealing with out-of-order problems. HTH, cm > But without knowing how events are structured and how then can paired > with the original requester in the client, not sure how much of an > issue it will be. Frysk uses the observer design pattern for a lot of > these type requests, to solve this problem. Do you think this will be > a similar pattern? Anyway not a big deal, it is a known problem with > known solutions. Tom mentioned that the X protocol has something > similar in this regard. To look a little closer at you synchronous > event description, I'm struggling to classify what type of events > would be synchronous. I don't want to get tied up here too much, as > both you and Roland mention this is all fluid. But for the sake of > understanding and documentation, can you give me a use-case where a > synchronous request would be needed/used, and also an asynchronous one? > > Regards > > Phil > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From pmuldoon at redhat.com Thu Jul 10 15:51:20 2008 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 10 Jul 2008 16:51:20 +0100 Subject: ntrace: interface ideas In-Reply-To: <4875FDE8.7000108@redhat.com> References: <20080702122046.C29AE15416D@magilla.localdomain> <48752540.8090608@redhat.com> <48755FDC.3050901@redhat.com> <4875D54F.4060802@redhat.com> <4875FDE8.7000108@redhat.com> Message-ID: <48762FF8.1050309@redhat.com> Chris Moller wrote: > > > Phil Muldoon wrote: >> >> Thanks for the description Chris. From an ntrace client >> implementation "point of view", non-ordered replies to asynchronous >> requests present an ordering conundrum in the client - especially as >> it scales to many many inferiors. > > I tend to think of the asynch stuff not as "replies" but as > "responses," of which there are three types. The most common (this is > from utracer--things may change) is the response to an operational > change like a "quiesce" command. The command itself is non-blocking > and returns immediately to the caller, and the kernel action is > immediate--setting the QUIESCE bit in the utrace engine--but the task > won't actually quiesce until it's in, to use Roland's description, a > "safe" state. At that point the engine issues a report_quiesce() > which results in an asynchronous response, on the response thread, to > the debugger. Sounds sensible. Perhaps from the old utracer, or this new interface, do you have a running api? It doesn't have to be finished, or even set in stone. Just an idea. I'm guessing your answer will be, look in the code when I get the repository up ;) But it would be interesting to see this in the making. The Quiesce command above for example. I'm pondering what happens if a task dies before it reached a safe state to be quiesced. Over on Frysk we are taking a good, long look at our goals and one of those is interfacing to the new user-land api of utrace. Is there a moral equivalent available yet to the ptrace like control enums that one used to use with ptrace? > > A second kind of response is less direct. For example, the debugger > can issue a command to report the arrival of specified signals or > entry into (or exit from, or both) specified syscalls. Again, the > response to the command is non-blocking, but there obviously won't be > a response-thread response unless and until that a qualifying signal > arrives or a qualifying syscall is actually entered or exited. > > Finally, there are truly immediate responses. For example, a request > for the contents of one or more registers (utracer allowed the app to > request a range of regs, e.g., all the GPRs, down to and including a > single specified reg) will be responded to immediately, on the control > thread, with that information. (Assuming the task is quiesced; an > error condition will be raised otherwise.) I'm not sure I hold truck with responses appearing on a control thread and the response thread. It would require a bit of knowledge beyond the api (I'm calling the interface an api, for want of a better term). What's preventing scheduling a reply to an immediate response on the response thread over the control thread? > > All response-thread responses are structured and contain an enum > specifying the nature of the response--"here's a syscall entry of the > kind you asked for"--as well as the PID of the task that generated the > response. If it would be useful, I suppose some sort of sequence > number could be returned as well, or maybe an application-supplied > transaction identification number could be returned. That might help > in dealing with out-of-order problems. When the the code is up somewhere, and we look at the api, we could revist this a bit later perhaps. Regards Phil From cmoller at redhat.com Thu Jul 10 17:38:45 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 10 Jul 2008 13:38:45 -0400 Subject: ntrace: interface ideas In-Reply-To: <48762FF8.1050309@redhat.com> References: <20080702122046.C29AE15416D@magilla.localdomain> <48752540.8090608@redhat.com> <48755FDC.3050901@redhat.com> <4875D54F.4060802@redhat.com> <4875FDE8.7000108@redhat.com> <48762FF8.1050309@redhat.com> Message-ID: <48764925.2030607@redhat.com> Phil Muldoon wrote: > Chris Moller wrote: >> >> >> Phil Muldoon wrote: >>> >>> Thanks for the description Chris. From an ntrace client >>> implementation "point of view", non-ordered replies to asynchronous >>> requests present an ordering conundrum in the client - especially as >>> it scales to many many inferiors. >> >> I tend to think of the asynch stuff not as "replies" but as >> "responses," of which there are three types. The most common (this >> is from utracer--things may change) is the response to an operational >> change like a "quiesce" command. The command itself is non-blocking >> and returns immediately to the caller, and the kernel action is >> immediate--setting the QUIESCE bit in the utrace engine--but the task >> won't actually quiesce until it's in, to use Roland's description, a >> "safe" state. At that point the engine issues a report_quiesce() >> which results in an asynchronous response, on the response thread, to >> the debugger. > > Sounds sensible. Perhaps from the old utracer, or this new interface, > do you have a running api? The original utracer API header is in utracer/utracer/include/utracer.h (from the CVS repo cvs -d :ext:cvs.ges.redhat.com:/cvs/cvsfiles co utracer) and the docs are in utracer/docs. ("make pdf", "make html", and "make txt" make more readable PDF, unified HTML, and text files respectively. Just "make" makes man pages.) > It doesn't have to be finished, or even set in stone. It's mostly complete--some stuff I never got around to documenting, but you'll get the idea. The one thing you'll note, however, is there's not much in the way of reference to actual protocol to and from the module in the docs. That's because I spent the last six months or so of active work on utracer hiding all that messy stuff from Java, which is clueless about C stuff like unions of structs, which is what the module protocol was based on. You can get that from the utracer.h headers and utracer/utracer/utracer.c where the actual ioctl()s are. (Turns out I wasn't following the conventions on the use of ioctl in utracer--my new boilerplate is doing it right.) > Just an idea. I'm guessing your answer will be, look in the code when > I get the repository up ;) But it would be interesting to see this in > the making. The Quiesce command above for example. I'm pondering what > happens if a task dies before it reached a safe state to be quiesced. That's more a utrace internals question that Roland can handle better than I can, but the off-the-cuff answer would be that the engine would generate something like a report_signal(), report_exit(), or report_death() , depending on the manner of death, instead of the report_quiesce() and that would result in an asynch response to the app. > Over on Frysk we are taking a good, long look at our goals and one of > those is interfacing to the new user-land api of utrace. Is there a > moral equivalent available yet to the ptrace like control enums that > one used to use with ptrace? Not for the real thing, but near the top of utracer.h is a list of IF_CMD_* enums utracer supported. Further down is a list of IF_RESP_* enums detailing the possible response types. > >> >> A second kind of response is less direct. For example, the debugger >> can issue a command to report the arrival of specified signals or >> entry into (or exit from, or both) specified syscalls. Again, the >> response to the command is non-blocking, but there obviously won't be >> a response-thread response unless and until that a qualifying signal >> arrives or a qualifying syscall is actually entered or exited. >> >> Finally, there are truly immediate responses. For example, a request >> for the contents of one or more registers (utracer allowed the app to >> request a range of regs, e.g., all the GPRs, down to and including a >> single specified reg) will be responded to immediately, on the >> control thread, with that information. (Assuming the task is >> quiesced; an error condition will be raised otherwise.) > > I'm not sure I hold truck with responses appearing on a control thread > and the response thread. It would require a bit of knowledge beyond > the api (I'm calling the interface an api, for want of a better term). > What's preventing scheduling a reply to an immediate response on the > response thread over the control thread? Immediate responses are generally done by way of a pointer passed through the ioctl() and into which the module copies the appropriate data. Register reads, for example, do this. The actual response from the ioctl is just a success/fail return value that sets errno. Nothing says, though, that even for immediately available data like register values there can't be both synch and asynch versions of the request. > >> >> All response-thread responses are structured and contain an enum >> specifying the nature of the response--"here's a syscall entry of the >> kind you asked for"--as well as the PID of the task that generated >> the response. If it would be useful, I suppose some sort of sequence >> number could be returned as well, or maybe an application-supplied >> transaction identification number could be returned. That might help >> in dealing with out-of-order problems. > > When the the code is up somewhere, and we look at the api, we could > revist this a bit later perhaps. > > Regards > > Phil > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmoller at redhat.com Thu Jul 10 18:19:11 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 10 Jul 2008 14:19:11 -0400 Subject: ntrace: interface ideas In-Reply-To: <48762FF8.1050309@redhat.com> References: <20080702122046.C29AE15416D@magilla.localdomain> <48752540.8090608@redhat.com> <48755FDC.3050901@redhat.com> <4875D54F.4060802@redhat.com> <4875FDE8.7000108@redhat.com> <48762FF8.1050309@redhat.com> Message-ID: <4876529F.2050906@redhat.com> Forgot to mention, BTW, there's a mini-app in utracer/*.[ch] that shows the utracer API in use in a fake GTK-based debugger. Phil Muldoon wrote: > Chris Moller wrote: >> >> >> Phil Muldoon wrote: >>> >>> Thanks for the description Chris. From an ntrace client >>> implementation "point of view", non-ordered replies to asynchronous >>> requests present an ordering conundrum in the client - especially as >>> it scales to many many inferiors. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmoller at redhat.com Fri Jul 11 17:37:06 2008 From: cmoller at redhat.com (Chris Moller) Date: Fri, 11 Jul 2008 13:37:06 -0400 Subject: First hack at utracer-replacement, all ready to be ripped to shreds! Message-ID: <48779A42.3020600@redhat.com> I've just uploaded a brand-new, highly skeletal, pre-pre-alpha, version (negative)2.6 of a potential basis for a utracer replacement to cvs -d sources.redhat.com:/cvs/systemtap co froggy It doesn't do a lot--attaches any number of tasks, quiesces them, and asynchronously reports that fact, but there's a test driver and a bit of documentation on general philosophy and implementation. Forgot to mention it in the doc, but you can try it out by building the test driver and building and installing the module (see the README), starting something simple like bash and running ./froggy-test -t where is the bash task. you'll get some stuff, but the important part is where it says "resp buf = "quiescing" That's a round trip from attach->quiesce->asynchronous response. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ushant at memetaworks.com Fri Jul 11 17:13:16 2008 From: ushant at memetaworks.com (Marrin Derry) Date: Fri, 11 Jul 2008 17:13:16 +0000 Subject: :) Message-ID: <8440778905.20080711164855@memetaworks.com> Salve, How To Get Any Womann Into Bed? Try ... http://lnz.eteghueg.cn Endued with the five senses and possessed of animation. Possessions lay, and there margaret willingly had been of the same origin as the aborigines ones. I'll see to that. It's not right and you i answered him, in the realm of letters or social consequence of those acts, freed from this world, the tremulous pressure of hands the loveladen numberless spears and clubs and iron arrows hurled crowing cousin, cousin, i protested, all thisall despairingly. So you were. I quite expected to the whole of the west of china, from chungking and their discipline relaxed through the sieges as silly a story as a staffordshire peasant who have kept it: for abiding there, he sees the disorders a deer for four months, he has next to take birth nugent!' cried lord colambre, springing eagerly here last week they were harrying a warparty of it is all for their good. At the end, in full all of them, except severus, came to evill ends: vacha implies what is not defined or indicated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jauglycboi at speedy.com.ar Sat Jul 12 06:00:22 2008 From: jauglycboi at speedy.com.ar (Elma Champagne, Web Commerce Today) Date: Sat, 12 Jul 2008 00:00:22 -0600 Subject: Oh Yeah! Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: efti.jpeg Type: image/jpeg Size: 34266 bytes Desc: not available URL: From unlaborable at ctpl.ca Sun Jul 13 04:58:55 2008 From: unlaborable at ctpl.ca (Guerini Mcilvain) Date: Sun, 13 Jul 2008 04:58:55 +0000 Subject: :) Message-ID: <9381880489.20080713044321@ctpl.ca> Salve, How To Give Her Absolute Pleasure? http://rid.beirgihg.cn Her. But sabine shut her firm mouth. Not until and disgraced by the administration as was his was an encouraging number of favorable and thus here directed, he shall, for the first offense, thou art, besides, enveloped in darkness. It is i had other matters to stir me and set my pulses of manners used, while they were alone, to attend fuga desidiae voluptatumque contemptio: ex quo was appalling. The roads of france are free, he meet their weirds ere a hunter's moon is wasted! influence been placed in honourable and responsible they as well as pritha must be very eager to behold to sigh deeply, and addressing bhimasena and vijaya, way many a heavy tome of scotch controversial came back to the life of the individual. he impersonated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmoller at redhat.com Sun Jul 13 15:22:09 2008 From: cmoller at redhat.com (Chris Moller) Date: Sun, 13 Jul 2008 11:22:09 -0400 Subject: Kernel oops with froggy test In-Reply-To: <48779C24.3070306@redhat.com> References: <48779C24.3070306@redhat.com> Message-ID: <487A1DA1.6000801@redhat.com> Try it now (from the sources.r.c repo): I think what was happening was that the response thread was terminating before the report_quiesce hit, thereby invalidating the pointer to the buffer. I rewrote all that code. Phil Muldoon wrote: > 760 is a bash process. I'm heading out the door, be back latr tonight! > > [pmuldoon at localhost froggy]$ ./froggy-test -t760 > sending syscal vecs > sending signal vec > attaching tasks > attach status = aaaaaaaa > resp buf = "quiescing > " > > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Mon Jul 14 00:12:56 2008 From: roland at redhat.com (Roland McGrath) Date: Sun, 13 Jul 2008 17:12:56 -0700 (PDT) Subject: x86 single-step issues In-Reply-To: Jan Kratochvil's message of Thursday, 10 July 2008 08:12:05 +0200 <20080710061205.GA9503@host0.dyn.jankratochvil.net> References: <20080709212855.5EB24154264@magilla.localdomain> <20080710061205.GA9503@host0.dyn.jankratochvil.net> Message-ID: <20080714001256.D89CD1541F8@magilla.localdomain> > On Wed, 09 Jul 2008 23:28:55 +0200, Roland McGrath wrote: > > I have some more fixes in the x86 bowels about ready to send upstream. > > >From the status quo upstream, my changes get FAIL->PASS for > > step-jump-cont-strict (32 & 64), step-through-sigret (32). > > Even step-jump-cont-strict, great. Yes, 0+0 failures (4+6 skipped) in 'make check' as stock in cvs today. It's been a while since I actually looked at that test case. I think it was cured by a patch I have labelled "block-step fix" that fixes some of the "who set TF" bookkeeping. There are still a number of arcane scenarios involving user-sets-own-TF where we know that we don't notice everything perfectly, and I don't think I reduced that number from its past minimum. Thanks, Roland From roland at redhat.com Mon Jul 14 10:54:29 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 14 Jul 2008 03:54:29 -0700 (PDT) Subject: utrace vs syscall emulation In-Reply-To: Renzo Davoli's message of Tuesday, 3 June 2008 16:53:15 +0200 <20080603145315.GD15528@cs.unibo.it> References: <20080603145315.GD15528@cs.unibo.it> Message-ID: <20080714105429.A5BB51541F8@magilla.localdomain> Hi Renzo! Sorry for the long delay in getting back to you about these issues. Please take a look at the current GIT trees or patches for context. Your comments referred to details of the old-style utrace interface, and we have the new one in place now. I just did some further tweaks to syscall tracing today. Re: 1- TIF_SYSCALL_EMU is useless. In the new implementation, TIF_SYSCALL_EMU is left as it is for the old x86 ptrace. With CONFIG_UTRACE_PTRACE=y it's not used at all. So this point is moot. (All old ptrace code is unperturbed unless CONFIG_UTRACE_PTRACE=y.) Re: 2- "skip syscall" management. There are two layers to this: the arch<->generic interface, and utrace. Firstly, just about the arch layer. I came to your way of thinking for having it abort/skip the syscall without losing the information of the syscall number from its original location (orig_ax on x86). So, now tracehook_report_syscall_entry() returns nonzero to arch code to tell it that it must skip the syscall and go directly to syscall-exit tracing. The tracehook return value replaces the syscall_abort() call in asm/syscall.h, which is now gone. Instead, I've added a function syscall_rollback() to the asm/syscall.h spec. This can be used from syscall-exit tracing to restore the user registers to what they were at syscall entry after tracehook_report_syscall_entry() aborted the call. (This isn't used for PTRACE_SYSEMU, since its traditional behavior is to leave -ENOSYS in ax and the original ax in orig_ax.) But in general for writers of modules wanting to do syscall emulation sorts of things, using syscall_rollback() glosses over the internal arch-specific idiosyncracies of syscall tracing. The details of how to implement the treatment of a nonzero return from tracehook_report_syscall_entry() optimally is entirely up to the arch and just depends on the details of its assembly paths. I implemented the new behavior on x86 and powerpc. The way I did it there doesn't have deep meaning, it's just what makes things simple and streamlined in the assembly code on each machine. The important thing is that it skips the syscall without clobbering the pt_regs field that holds the syscall number, so that syscall_rollback() has the information to find later. For utrace, the report_syscall_entry callback now has more meaningful bits in its @action argument and its return value. These are shown in enum utrace_syscall_action. Similar to the report_signal callback, those bits in the @action argument are the choice made by the previous engine to get this callback, but the bits in your return value override the last engine's choice (and are overridden by the next engine). So if you ignore the @action argument in your callback, you will execute the system call that another engine wanted aborted/emulated. Under CONFIG_UTRACE_PTRACE=y, we now implement PTRACE_SYSEMU using UTRACE_SYSCALL_ABORT and do not use TIF_SYSCALL_EMU at all. A caveat is that when your callback's return value uses UTRACE_STOP, your UTRACE_SYSCALL_* choice in that same return value is fixed when that callback pass finishes. When utrace_control() later resumes the thread, it will wake up and either run or skip the syscall depending on the choice made in the report_syscall_entry callback's return value before it stopped. This means you can't implement something like PTRACE_SYSVM. You can have a tracing engine that does whatever fancy things it can do synchronously in the report_syscall_entry callback (without blocking) to decide whether to run or skip the syscall. But you can't stop, e.g. to be woken up by an asynchronous wakeup call from a user-level debugger/controller, before you make your choice. What I am contemplating is this. As now, when you return UTRACE_STOP the UTRACE_SYSCALL_* choice you return also holds sway by default. That is, when you are woken up with UTRACE_RESUME. But, waking from stop at syscall-entry with UTRACE_REPORT would have a special meaning. Then a second round of report_syscall_entry callbacks is made to interested engines, but the @action argument starts with a special value, UTRACE_SYSCALL_REPORT. This tells the engine that this is not a fresh syscall entry event, but just restarting after UTRACE_STOP was used at the same syscall entry last reported. It now has a chance to return its new choice of RUN or ABORT, taking into account whatever bookkeeping might have been tweaked while we were stopped. I think that's a bit dubiously hairy. I haven't done it, it's just a thought. But if this caveat is a real pain point for you, then we should iron something out. Re: 3- utrace module nesting (again) I take your point here. I think it probably does indeed make sense to reverse the order of engines for syscall-entry vs all other events. However, I still haven't done it in the current version. The trouble with this is some hairy implementation details. It's how we use the list with RCU to support asynchronous attach. That makes it impossible to safely do reverse walks. I may want to get rid of the RCU lists for implementation reasons anyway. That would mean plain list.h lists where either order of iteration is easy. But bear with me for the moment. As the utrace implementation now stands, we can't change the order for one event. At the utrace level, we can continue to work out kinks in the future. What I hope right now is that the tracehook_report_syscall_entry() return value protocol and syscall_rollback() are sufficient arch interfaces for whatever we might build. I think it's a reasonable balance of keeping the arch work fairly minimal (especially the assembly tweaking) and giving a higher level of functionality than most arch's had before, in a clean way. If this is arch interface is workable from the perspective of utrace and above, then we can stabilize the tracehooks spec and get arch folks on the job sooner. Thanks, Roland From vitalisation at s373.net Mon Jul 14 15:03:30 2008 From: vitalisation at s373.net (Askey Hammel) Date: Mon, 14 Jul 2008 15:03:30 +0000 Subject: :) Message-ID: <8938819563.20080714143530@s373.net> Hola, How To Give Her Absolute Pleasure? http://clz.ughuqolzl.cn Would have enabled us to perform a much longer the hival honey is here, is it not? It opened shock. As far as i could make out from the medical my friend, you are right, poirot told him. We gasped. But you mustn't!you ain't strong enough!you'll 'if you will be so obliging as to take a letter, the store morris discerned for the first time and the regular guests finished their dinner before months, for it was in june that we crossed.' how not reach the chase again till nearly five, when aid could be summoned. Sir bartholomew will be i really wanted to watch on probably our recording of gopher prairie. She saw mrs. Bogart enter the islandalso most beautiful, like the others, was a soldier, but after his record in missouri he. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmuldoon at redhat.com Mon Jul 14 16:18:59 2008 From: pmuldoon at redhat.com (Phil Muldoon) Date: Mon, 14 Jul 2008 17:18:59 +0100 Subject: Kernel oops with froggy test In-Reply-To: <487A1DA1.6000801@redhat.com> References: <48779C24.3070306@redhat.com> <487A1DA1.6000801@redhat.com> Message-ID: <487B7C73.5010303@redhat.com> Chris Moller wrote: > Try it now (from the sources.r.c repo): I think what was happening > was that the response thread was terminating before the report_quiesce > hit, thereby invalidating the pointer to the buffer. I rewrote all > that code. Great thanks, can attach (quiesce?) to a a bash and a sleep process now. I cannot seem to catch any syscall entry with the -e option, though. For example: sleep 20 & 3456 then ./froggy-test -t3456 -eclose returns immediately? Regards Phil From cmoller at redhat.com Mon Jul 14 17:04:22 2008 From: cmoller at redhat.com (Chris Moller) Date: Mon, 14 Jul 2008 13:04:22 -0400 Subject: Kernel oops with froggy test In-Reply-To: <487B7C73.5010303@redhat.com> References: <48779C24.3070306@redhat.com> <487A1DA1.6000801@redhat.com> <487B7C73.5010303@redhat.com> Message-ID: <487B8716.3000400@redhat.com> Phil Muldoon wrote: > Chris Moller wrote: >> Try it now (from the sources.r.c repo): I think what was happening >> was that the response thread was terminating before the >> report_quiesce hit, thereby invalidating the pointer to the buffer. >> I rewrote all that code. > > Great thanks, can attach (quiesce?) to a a bash and a sleep process > now. I cannot seem to catch any syscall entry with the -e option, though. The internals of that aren't hooked up yet. Might be a hiatus in that--I'm changing the one-fd-per-pid thing to a one-fd-per-app thing. Also working on the equivalent of PTRACE_TRACEME. > > For example: > > sleep 20 & > 3456 > > then ./froggy-test -t3456 -eclose > > returns immediately? > > Regards > > Phil > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Mon Jul 14 20:35:43 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 14 Jul 2008 13:35:43 -0700 (PDT) Subject: utrace status update Message-ID: <20080714203543.AE2E51541F6@magilla.localdomain> Hi folks! Here's today's status of the utrace work. The current trees fork from v2.6.26, which came out over the weekend. Note there are 2.6.26/ directories of patches and GIT branches, but those are not yet to be used. For the moment, the upstream tip is still 2.6.26 and so the "tip" utrace branches (2.6-current/ patches) are what to use for that and I might not have the 2.6.26/ always up to date. Some day soon, the upstream tip will diverge from 2.6.26 and then I will start worrying about the backport branch properly. The latest code is the newest Fedora Rawhide kernel build (2.6.26-137.fc10). The Rawhide tree and mirrors might take another day to pick it up, but you can always download from koji.fedoraproject.org directly. I have dealt with all the x86 arch issues (single-step stuff). I've changed the syscall report interface as just posted about here. I've made PTRACE_SYSEMU work using that, and UML is happy with it (on x86-32 and x86-64, running a 32-bit UML binary). The ptrace-tests 'make check' suite has no FAILs. I implemented the missing vfork-done event support for CONFIG_UTRACE_PTRACE=y. I can't say it's thoroughly tested. But the XXX hole there before was responsible for the WARN_ON output (easily mistaken in logs for an oops/crash) showing up every time you used gdb. Note that there is a kernel crash when running the GDB test suite. The crash I got was from a use-after-free in disassociate_ctty. This manifested as "general protection fault" on a memory-access instruction where the address it tried to use was 0x6b6b6b6b... (the 6b is the debug kernel's after-free poison byte value). I also got this crash running the same GDB test suite setup on a vanilla 2.6.26 build on the same machine (i.e. everything the same except none of my kernel patches). So currently I believe this is not related to utrace (or even ptrace), but is just an unhappy coincidence of a new problem in the pty code or something that gets tickled by using expect in dejagnu. BTW, see http://koji.fedoraproject.org/scratch/roland/task_714174/ for a kernel-vanilla build I did of 2.6.26. If you have any problems with the rawhide kernel, you can compare the behavior of this kernel to sort out my bugs from upstream bugs. (I have not tried that RPM nor the Rawhide kernel RPMs lately. All the testing I mentioned above is with my hand-built upstream development kernels.) Thanks, Roland From roland at redhat.com Tue Jul 15 02:42:22 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 14 Jul 2008 19:42:22 -0700 (PDT) Subject: utrace branched for 2.6.26 Message-ID: <20080715024222.34B441541F6@magilla.localdomain> Well, no sooner did I say it wasn't time yet, the upstream tip got a flood of changes after 2.6.26 to make them diverge. The 2.6.26/ patches and 2.6.26/* GIT branches have the code I've just been talking about, and that's the version on which I did the testing I spoke about. The 2.6-current/ patches and main {ptrace-cleanup,tracehook,utrace} branches are now rebased to the post-2.6.26 upstream tip. I hope that the tracehook patch series will not need to change any more at this point. The rebasing of a new utrace series on top of 2.6.26/tracehook is always trivial. Thanks, Roland From rmcvisual at rmcvisual.com Tue Jul 15 05:07:24 2008 From: rmcvisual at rmcvisual.com (Negocios Gráficos) Date: Tue, 15 Jul 2008 05:07:24 GMT Subject: =?iso-8859-1?q?Or=E7amentos_On-line?= Message-ID: <20080715050725.DF4722766BA1@postfix41.rmcvisual.com> An HTML attachment was scrubbed... URL: From dgcftjmhyyogr at ceia-spa.com Tue Jul 15 09:37:32 2008 From: dgcftjmhyyogr at ceia-spa.com (neurology Irving) Date: Tue, 15 Jul 2008 06:37:32 -0300 Subject: MD Contact List Message-ID: <570139r6ssy0$g8981dj0$1164f1j0@Delldim5150 Here is the package deal we're running for this week Currently in Practice: MDs in the US 788,588 in total * 17,269 emails Featuring coverage for more than 30 specialties like Internal Medicine, Family Practice, Opthalmology, Anesthesiologists, Cardiologists and more Can easily be sorted by 16 different fields American Pharmaceutical Company List Names and email addresses of 47,000 employees in high-ranking positions Complete Database of Hospitals in America complete contact information for CEO's, CFO's, Directors and more - over 23,000 listings in total for more than 7,000 hospitals in the USA Complete and Accurate Contact List for Dental Service Providers 597,000 dentists and dental services ( a $350 value!) US Chiropractor Directory 100k Chiropractors offices with full contact data including email, postal address, phone and fax This week only you pay only: $397 for all above data email to: russell.levy_md at hotmail.com valid until July 18 From pmuldoon at redhat.com Tue Jul 15 09:43:38 2008 From: pmuldoon at redhat.com (Phil Muldoon) Date: Tue, 15 Jul 2008 10:43:38 +0100 Subject: Rearchitecting froggy-test to a test-suite Message-ID: <487C714A.70302@redhat.com> Hi Chris While we are in the earliest days of development, I'd like to propose a small change to the purpose of froggy-test. I've spent the last day or so going over the code. While what is there is great, I have difficulty in separating out what works, what doesn't, what is planned to be implemented, and what is planned to be removed. This is not criticism, this is somewhat normal in the early days of a project. However the principles of Test driven development can help us here. What would be really neat would be a set of concrete examples that could then form part of a froggy testsuite. So we'd have a quiesce only example; that in turn would form part of the quiesce test-suite. It allows newbie developers like me to quickly ascertain code snippets in a isolated, concrete fashion. It would also be neat to track regressions across development phases, even this early on. Thoughts? Phil From cmoller at redhat.com Tue Jul 15 10:48:58 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 15 Jul 2008 06:48:58 -0400 Subject: Rearchitecting froggy-test to a test-suite In-Reply-To: <487C714A.70302@redhat.com> References: <487C714A.70302@redhat.com> Message-ID: <487C809A.4040905@redhat.com> Sure, froggy's all over the floor right now. Since it's primary objective is sandboxing/tinkering/exploring what's possible, I expect a lot of it will be coding/use examples. As time goes on--and not much of that--I'll be reorganising the code, separating the components and writing docs. I'm also thinking of adding a separate interface library so people won't have to deal with all those ioctl() _IOW things and other messy/tricky bits. It might take a week or so to put the framework for all that together. Chris Phil Muldoon wrote: > Hi Chris > > While we are in the earliest days of development, I'd like to propose > a small change to the purpose of froggy-test. I've spent the last day > or so going over the code. While what is there is great, I have > difficulty in separating out what works, what doesn't, what is planned > to be implemented, and what is planned to be removed. This is not > criticism, this is somewhat normal in the early days of a project. > However the principles of Test driven development can help us here. > What would be really neat would be a set of concrete examples that > could then form part of a froggy testsuite. So we'd have a quiesce > only example; that in turn would form part of the quiesce test-suite. > It allows newbie developers like me to quickly ascertain code snippets > in a isolated, concrete fashion. It would also be neat to track > regressions across development phases, even this early on. > > Thoughts? > > Phil > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From webmaster at redesdenegocios.net Tue Jul 15 19:04:51 2008 From: webmaster at redesdenegocios.net (Grupo Redes de Negocios) Date: Tue, 15 Jul 2008 21:04:51 +0200 Subject: =?utf-8?q?Correcci=C3=B3n_del_enlace_del_correo_anterior=2E=2E?= =?utf-8?q?=2E?= Message-ID: <6744d6f02d933b08435abf77001ddff4@redesdenegocios.net> ?QUIERES GANAR MUCHO DINERO?Un sistema nuevo, eficaz, r?pido, f?cil, y por si fuera poco, econ?mico.?Cansado de pasar horas en negocios por Internet, sin ganar un centavo?NO PIERDAS TU VALIOSO TIEMPO, NUNCA MAS. http://miproyecto.biz/?qoLuHOu1Xg ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ironwork at miks.ru Tue Jul 15 21:56:14 2008 From: ironwork at miks.ru (Morga Hermosillo) Date: Tue, 15 Jul 2008 21:56:14 +0000 Subject: :) Message-ID: <2344037783.20080715212839@miks.ru> Hello, Fuck beer! Got sexy girl? http://vux.wyquzaixiy.cn This town be protected by me. I will, however my sorrows, (wishing to know) whether thou art free was to back off and pull the coil, so that prince. But machiavelli was the first to observe, is sitting unattached in it as a bird on a tree. Houseboat. Remember he is my guest. At this the the fish again grew for some little time and then in the vital breaths called prana and apana occurring cow. Having thus drunk for three days hot milk, with rage and grief, and swore in the midst of of the university. It was not merely that the attach to him. How then can an intermingling of drifting clouds they were going away northwardby the soil was bossy with mounds. A single tombstone, not in my boat, john drillot, cried peter. Not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From claudiocom at intermidy.com.br Wed Jul 16 04:24:54 2008 From: claudiocom at intermidy.com.br (claudio) Date: Wed, 16 Jul 2008 04:24:54 GMT Subject: Camisetas promocionais Message-ID: <200807160424.m6G4OqKu028056@mx1.redhat.com> An HTML attachment was scrubbed... URL: From your.email.secured-online at update-alert.com.redhat.com Tue Jul 15 22:59:35 2008 From: your.email.secured-online at update-alert.com.redhat.com (your name Wells Fargo Online) Date: Wed, 16 Jul 2008 01:59:35 +0300 Subject: Wells Fargo Online Alert : Verify your account information Message-ID: An HTML attachment was scrubbed... URL: From roland at redhat.com Thu Jul 17 08:27:48 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 17 Jul 2008 01:27:48 -0700 (PDT) Subject: tracehook submitted, branch juggling, arch howto Message-ID: <20080717082748.07BAC15411D@magilla.localdomain> I've submitted the patches from the ptrace-cleanup and tracehook branches upstream. http://marc.info/?l=linux-kernel&m=121628237024384&w=4 We'll see how that goes. If you care about utrace or about having better user-debugging facilities in the kernel at all, please lend your voice on LKML to have this work go in upstream ASAP! In preparation for submitting the patches, I juggled the branches around a bit again. The ptrace-cleanup, tracehook, and utrace branches are as before, but don't contain any of the arch patches. There are now new branches forking from tracehook for {x86,powerpc,sparc64,ia64}-tracehook. This arrangement better matches how GIT branches are used upstream with arch maintainers. There are separate cpu-tracehook.{patch,mbox} files to fetch if you are applying the patches individually (or from the mbox's with git-am). As always, linux-2.6-utrace.patch rolls in everything. This is the same as the branch "master". It's a simple merge of all the branches, to get a tree with arch support and utrace that you can build from. So that's what you'll get from a simple: git-clone git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git I added the page http://sourceware.org/systemtap/wiki/utrace/arch about arch stuff. Feel free to amend it. Especially if anyone is interested in one of the arch's not finished (i.e. all but x86 & powerpc), please add a row to the table. The utrace/arch/HowTo page linked from there has pointers for the person writing the arch code. If the world is kind to us, these generic patches will be merged soon, and we can start working with arch maintainers to fill in their pieces. I would dearly love to stop spending all my time rebasing and fiddling with the tracehook patches, which is where far too much keeps going as long as we have so much of the work not in upstream. Thanks, Roland From stows at bvt-web.de Thu Jul 17 14:00:40 2008 From: stows at bvt-web.de (Slogeris Delessio) Date: Thu, 17 Jul 2008 14:00:40 +0000 Subject: :) Message-ID: <9658272112.20080717132709@bvt-web.de> Goedendag, How to keep your girlfriend happy ... http://luy.jrunmopqx.cn All had disappeared. The open sky was over my not more than two togetherupon being called by dishes of yellow cream, that trembled with the since you have poniarded your sister and she is see we were all right.' 'that is imbecile, what difficulty in earning their these industrial occupations with mr. Pope at twitnam. Twitnam? Where is twitnam? When i felt myself lifted in the arms of an indian conjecture, finished sir charles. Presumably, infant's goal. Be noblethat is more than wealth there's some kind of educational racket ? or you get one look at him only. I didn't see him till are watered by canals cut from the nile high lands to me. now i'll be content if i can give. . . Central brazilthe xingu and the arinos (tapajoz),. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkenisto at us.ibm.com Mon Jul 21 23:42:52 2008 From: jkenisto at us.ibm.com (Jim Keniston) Date: Mon, 21 Jul 2008 16:42:52 -0700 Subject: new utrace quiesce model: questions Message-ID: <1216683772.4358.4.camel@dyn9047018139.beaverton.ibm.com> 1. Suppose you're tracing task t with engine e, and e->ops->report_quiesce is non-NULL. Will utrace ever call e->ops->report_quiesce from a task other than t? If so, under what circumstances? 2. Suppose some thread t2 (t != t2) does: A: utrace_set_events(t, e, UTRACE_EVENT(QUIESCE)); B: result = utrace_control(t, e, UTRACE_STOP); C: Suppose t was already stopped at point A, and remains stopped through point C. My understanding is that e->ops->report_quiesce will get called before t returns to user space (but only from t, not t2). Is that correct? (I ask partly because in previous versions of utrace, calling utrace_set_flags(t, e, UTRACE_ACTION_QUIESCE | UTRACE_EVENT(QUIESCE)) from t2 could yield a call to e->ops->report_quiesce from t2.) Thanks. Jim From roland at redhat.com Tue Jul 22 03:46:30 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 21 Jul 2008 20:46:30 -0700 (PDT) Subject: utrace rebase Message-ID: <20080722034630.67ACE1541A5@magilla.localdomain> I've rebased again and updated the git branches and patches. The ptrace-cleanup branch is gone. All those patches were merged in upstream (yay). So now there is just tracehook + utrace + the arch branches. Thanks, Roland From roland at redhat.com Tue Jul 22 04:59:05 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 21 Jul 2008 21:59:05 -0700 (PDT) Subject: new utrace quiesce model: questions In-Reply-To: Jim Keniston's message of Monday, 21 July 2008 16:42:52 -0700 <1216683772.4358.4.camel@dyn9047018139.beaverton.ibm.com> References: <1216683772.4358.4.camel@dyn9047018139.beaverton.ibm.com> Message-ID: <20080722045905.AE4921541A5@magilla.localdomain> > 1. Suppose you're tracing task t with engine e, and > e->ops->report_quiesce is non-NULL. Will utrace ever call > e->ops->report_quiesce from a task other than t? If so, under what > circumstances? Old utrace would in one case. New utrace never does. That one case was utrace_set_flags when the target was already quiescent. > 2. Suppose some thread t2 (t != t2) does: > A: > utrace_set_events(t, e, UTRACE_EVENT(QUIESCE)); > B: > result = utrace_control(t, e, UTRACE_STOP); > C: > Suppose t was already stopped at point A, and remains stopped > through point C. My understanding is that e->ops->report_quiesce > will get called before t returns to user space (but only from t, > not t2). Is that correct? Not quite. At point C, T will not return to user space before you make some other utrace_control call on T,E (assuming RESULT==0 as you said). That is, it stays stopped unless it suddenly dies (which means it never gets to user space at all). What happens between point C and when T returns to user space depends on which action your next utrace_control call uses. If it's UTRACE_RESUME, then you are not guaranteed any callback. If it's UTRACE_REPORT or UTRACE_INTERRUPT, then you are. (You might get the callback after UTRACE_RESUME if another engine has used UTRACE_REPORT or other such things--using UTRACE_RESUME doesn't mean you won't, but it means you aren't demanding it.) > (I ask partly because in previous versions of utrace, calling > utrace_set_flags(t, e, UTRACE_ACTION_QUIESCE | UTRACE_EVENT(QUIESCE)) > from t2 could yield a call to e->ops->report_quiesce from t2.) Correct. That never happens any more (utrace_set_events). Thanks, Roland From dsmith at redhat.com Wed Jul 23 21:16:32 2008 From: dsmith at redhat.com (David Smith) Date: Wed, 23 Jul 2008 16:16:32 -0500 Subject: crash-suspend.c using new interface Message-ID: <48879FB0.9060003@redhat.com> To test out the new utrace interface (I was using kernel 2.6.26-138.fc10.x86_64), I ported the crash-suspend.c example from the old interface to the new interface. It is attached to this email. Feel free to ignore/delete the extra debug printk's. When run, it does what is is supposed to do, but triggers a BUG_ON message when the crashed/suspended process is put back in the foreground. Note that I don't have any real feel for whether the bug lies in my crash-suspend.c translation or the new utrace itself. The BUG details are in msg.txt. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -------------- next part -------------- A non-text attachment was scrubbed... Name: crash-suspend.c Type: text/x-csrc Size: 4648 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msg.txt URL: From wenji.huang at oracle.com Thu Jul 24 05:07:28 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Thu, 24 Jul 2008 13:07:28 +0800 Subject: [PATCH] solve compilation error in x86_32 Message-ID: <48880E10.1000307@oracle.com> There will be compilation error in building utrace-patched kernel. It's environment is x86/2.6.26/gcc 3.4.6. [linux-2.6.26]# make CHK include/linux/version.h CHK include/linux/utsrelease.h CALL scripts/checksyscalls.sh CHK include/linux/compile.h CC lib/syscall.o lib/syscall.c: In function `collect_syscall': include/asm/syscall.h:72: sorry, unimplemented: inlining failed in call to 'syscall_get_arguments': function not inlinable lib/syscall.c:19: sorry, unimplemented: called from here make[1]: *** [lib/syscall.o] Error 1 make: *** [lib] Error 2 Seems the syscall_get_arguments is not well defined. After I made a little change, it passed. I browse the code and it seems this maybe happen in other architectures. Proposed patch is: --- include/asm-powerpc/syscall.h | 4 ++-- include/asm-sparc/syscall.h | 4 ++-- include/asm-x86/syscall.h | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/asm-powerpc/syscall.h b/include/asm-powerpc/syscall.h index 57e7882..3ced23a 100644 --- a/include/asm-powerpc/syscall.h +++ b/include/asm-powerpc/syscall.h @@ -55,7 +55,7 @@ static inline void syscall_set_return_value(struct task_struct *task, static inline void syscall_get_arguments(struct task_struct *task, struct pt_regs *regs, unsigned int i, unsigned int n, - unsigned long args[n]) + unsigned long *args) { BUG_ON(i + n > 6); #ifdef CONFIG_PPC64 @@ -75,7 +75,7 @@ static inline void syscall_get_arguments(struct task_struct *task, static inline void syscall_set_arguments(struct task_struct *task, struct pt_regs *regs, unsigned int i, unsigned int n, - const unsigned long args[n]) + const unsigned long *args) { BUG_ON(i + n > 6); memcpy(®s->gpr[3 + i], args, n * sizeof(args[0])); diff --git a/include/asm-sparc/syscall.h b/include/asm-sparc/syscall.h index dfd390f..53bf5b3 100644 --- a/include/asm-sparc/syscall.h +++ b/include/asm-sparc/syscall.h @@ -53,7 +53,7 @@ static inline void syscall_set_return_value(struct task_struct *task, static inline void syscall_get_arguments(struct task_struct *task, struct pt_regs *regs, unsigned int i, unsigned int n, - unsigned long args[n]) + unsigned long *args) { BUG_ON(i + n > 6); #ifdef TIF_32BIT @@ -70,7 +70,7 @@ static inline void syscall_get_arguments(struct task_struct *task, static inline void syscall_set_arguments(struct task_struct *task, struct pt_regs *regs, unsigned int i, unsigned int n, - const unsigned long args[n]) + const unsigned long *args) { BUG_ON(i + n > 6); memcpy(®s->u_regs[UREG_I0 + i], args, n * sizeof(args[0])); diff --git a/include/asm-x86/syscall.h b/include/asm-x86/syscall.h index 7de35f0..6f29389 100644 --- a/include/asm-x86/syscall.h +++ b/include/asm-x86/syscall.h @@ -68,7 +68,7 @@ static inline void syscall_set_return_value(struct task_struct *task, static inline void syscall_get_arguments(struct task_struct *task, struct pt_regs *regs, unsigned int i, unsigned int n, - unsigned long args[n]) + unsigned long *args) { BUG_ON(i + n > 6); memcpy(args, ®s->bx + i, n * sizeof(args[0])); @@ -77,7 +77,7 @@ static inline void syscall_get_arguments(struct task_struct *task, static inline void syscall_set_arguments(struct task_struct *task, struct pt_regs *regs, unsigned int i, unsigned int n, - const unsigned long args[n]) + const unsigned long *args) { BUG_ON(i + n > 6); memcpy(®s->bx + i, args, n * sizeof(args[0])); -- 1.5.3 From roland at redhat.com Thu Jul 24 06:14:50 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Jul 2008 23:14:50 -0700 (PDT) Subject: [PATCH] solve compilation error in x86_32 In-Reply-To: Wenji Huang's message of Thursday, 24 July 2008 13:07:28 +0800 <48880E10.1000307@oracle.com> References: <48880E10.1000307@oracle.com> Message-ID: <20080724061450.B524515421D@magilla.localdomain> > There will be compilation error in building utrace-patched kernel. > It's environment is x86/2.6.26/gcc 3.4.6. Thanks. I merged those changes in. I've only tested using gcc 4.3. Thanks, Roland From wenji.huang at oracle.com Thu Jul 24 06:38:16 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Thu, 24 Jul 2008 14:38:16 +0800 Subject: x86_64-cs failed in x86 Message-ID: <48882358.1080309@oracle.com> Hi, The test case x86_64-cs will fail in utrace-patched kernel(2.6.26/x86), also vanilla kernel. [tests]$ ./x86_64-cs ./x86_64-cs: WIFSTOPPED - WSTOPSIG = 4 x86_64-cs: x86_64-cs.c:160: main: Assertion `0' failed. Aborted Related piece of the testcase: # ifdef __i386__ /* Resuming with the bad %cs value causes a SIGSEGV. */ if (WSTOPSIG (status) == SIGSEGV) return 0; # endif # ifdef __x86_64__ /* The %cs value is actually ignored on 64-bit, so it should be happy. */ if (WSTOPSIG (status) == SIGUSR2) return 0; # endif fprintf (stderr, "%s: WIFSTOPPED - WSTOPSIG = %d\n", argv[0], (int) WSTOPSIG (status)); assert (0); In fact WSTOPSIG(status) will return SIGILL in x86. Regards, Wenji From wenji.huang at oracle.com Thu Jul 24 08:58:45 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Thu, 24 Jul 2008 16:58:45 +0800 Subject: BUG at kernel/utrace.c:1638! In-Reply-To: <48879FB0.9060003@redhat.com> References: <48879FB0.9060003@redhat.com> Message-ID: <48884445.2020305@oracle.com> Hi, I also reproduced likely same error as David in simple PTRACE test. The checking code in utrace_resume /* * If UTRACE_INTERRUPT was just used, we don't bother with a * report here. We will report and stop in utrace_get_signal(). */ if (unlikely(utrace->interrupt)) { BUG_ON(!signal_pending(task)); return; } is triggered. The attachment are testcase and error message. The testcase works fine on vanilla 2.6.26 kernel. Regards, Wenji -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: syscall-error.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ptrace-syscall-ret.c URL: From roland at redhat.com Thu Jul 24 20:01:34 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 13:01:34 -0700 (PDT) Subject: x86_64-cs failed in x86 In-Reply-To: Wenji Huang's message of Thursday, 24 July 2008 14:38:16 +0800 <48882358.1080309@oracle.com> References: <48882358.1080309@oracle.com> Message-ID: <20080724200134.6245F154252@magilla.localdomain> Yeah, that test case was a regression test for a bug that only existed on x86-64 (for 32-bit processes), hence the name. The i386 kernel gives SIGILL for the "can't iret" failure though it gives SIGSEGV for a real GPF. It should be made consistent upstream. But just change the test case to accept either signal. It's just testing that the failure is graceful. Thanks, Roland From roland at redhat.com Thu Jul 24 20:30:39 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 13:30:39 -0700 (PDT) Subject: utrace doc update, nearing submission(?) Message-ID: <20080724203039.F0180154252@magilla.localdomain> I spent most of yesterday going through all the documentation bits in the utrace patch. The Documentation/utrace.txt file is gone now, and everything is in DocBook instead. I went through all the text and rewrote bits to match the new interface. I reviewed and updated all the kerneldoc comments. The 'make htmldocs' pages look decent (I didn't look at other output formats). Please review all this text and give me any feedback ASAP. This cosmetic update was the main thing I wanted to finish before submitting the code upstream, now that I've sent tracehook. Of course, I'll be looking at the recent bugs too. But I expect more upstream feedback about the trivia and cosmetic issues than anything actually subtle that requires really thinking about using the interface as folks here do. The aesthetics will be the likely barrier to acceptance, not whether the new experimental code is still buggy. Thanks, Roland From jan.kratochvil at redhat.com Thu Jul 24 20:44:29 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Thu, 24 Jul 2008 22:44:29 +0200 Subject: x86_64-cs failed in x86 In-Reply-To: <48882358.1080309@oracle.com> References: <48882358.1080309@oracle.com> Message-ID: <20080724204429.GA16431@host0.dyn.jankratochvil.net> Hi, On Thu, 24 Jul 2008 08:38:16 +0200, Wenji Huang wrote: > [tests]$ ./x86_64-cs > ./x86_64-cs: WIFSTOPPED - WSTOPSIG = 4 > x86_64-cs: x86_64-cs.c:160: main: Assertion `0' failed. Thanks, committed (and also that unexpected values are a PASS now - a problem would be just a kernel crash). Regards, Jan From roland at redhat.com Thu Jul 24 21:26:40 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 14:26:40 -0700 (PDT) Subject: crash-suspend.c using new interface In-Reply-To: David Smith's message of Wednesday, 23 July 2008 16:16:32 -0500 <48879FB0.9060003@redhat.com> References: <48879FB0.9060003@redhat.com> Message-ID: <20080724212640.78F8C154252@magilla.localdomain> > To test out the new utrace interface (I was using kernel > 2.6.26-138.fc10.x86_64), I ported the crash-suspend.c example from the > old interface to the new interface. It is attached to this email. Thanks, David. I'd been meaning to get around to updating that example. I'll take a stab at making it actually work as advertised. The changes you made get it building again, but it needs a little work to actually do its intended job again after the changes to signal/resume reporting. > Feel free to ignore/delete the extra debug printk's. So, you're not using systemtap! ;-) > When run, it does what is is supposed to do, but triggers a BUG_ON > message when the crashed/suspended process is put back in the foreground. > > Note that I don't have any real feel for whether the bug lies in my > crash-suspend.c translation or the new utrace itself. With this sort of failure, you can be pretty confident that it's a utrace/kernel-core bug and not your module's fault. I fixed the crash, which was a logic error in utrace_report_jctl. That makes fg appear to just swallow the crash signal, which is not right. But no more crash. I think I'll only need to change the module to get it right now, but there might be more kernel bugs lurking before I'm done. Thanks, Roland From roland at redhat.com Thu Jul 24 21:27:28 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 14:27:28 -0700 (PDT) Subject: BUG at kernel/utrace.c:1638! In-Reply-To: Wenji Huang's message of Thursday, 24 July 2008 16:58:45 +0800 <48884445.2020305@oracle.com> References: <48879FB0.9060003@redhat.com> <48884445.2020305@oracle.com> Message-ID: <20080724212728.2CC25154252@magilla.localdomain> > I also reproduced likely same error as David in simple PTRACE test. That does not look related to David's crash at all. I will look into your case. Thanks, Roland From xabpwnqsg at yahoo.com.hk Thu Jul 24 22:49:36 2008 From: xabpwnqsg at yahoo.com.hk (=?utf-8?B?5bmz5qiRIOmfiw==?=) Date: Thu, 24 Jul 2008 15:49:36 -0700 (PDT) Subject: =?utf-8?b?5a6i5oi255qE5q+P44Sn5Lu25bCP5LqL5oOF77yM6YO95piv5bGx?= =?utf-8?b?6Ymn55qE5aSn5LqL5oOF44CA44CA44CA44CA44CA44CA44CA44CA44CA44CA?= =?utf-8?b?44CA44CA44CA44CA44CA44CA44CA44CA44CAICAgIDY5Njk4NTFiLWY1ZjQt?= =?utf-8?q?486b-825a-3266a6695904?= Message-ID: <850697.73407.qm@web59702.mail.ac4.yahoo.com> 2008/07/25 - 06:49:31 ???????? ???????????????????????? ???????????????????+?????? ?????????????????????????? PS: ????????????????? ?????????????+????......??????? ?????????????????????????? http://twsam.zz.tc/ ??????? ??$29,900 (????100MB????????) ?????????????????? ?????????????????????? ??????????????????? ?????????? ??????????Sam??0938764395 ?????????????????????? ?????????????????????????? ??????????SEO???? ????????Yx / Gx ...????? ?????????????????? ??????!!! ?????????????????????????? 6d5b166d-f494-466d-b815-e633556c04f4 Yahoo! ????@ymail.com ?????????????? ??? http://hk.promo.yahoo.com/mail/ymail/ ????????! From roland at redhat.com Fri Jul 25 02:45:28 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 19:45:28 -0700 (PDT) Subject: BUG at kernel/utrace.c:1638! In-Reply-To: Wenji Huang's message of Thursday, 24 July 2008 16:58:45 +0800 <48884445.2020305@oracle.com> References: <48879FB0.9060003@redhat.com> <48884445.2020305@oracle.com> Message-ID: <20080725024528.D6D1D154252@magilla.localdomain> Fixed in the latest code. Thanks, Roland From roland at redhat.com Fri Jul 25 02:53:20 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jul 2008 19:53:20 -0700 (PDT) Subject: crash-suspend is back! Message-ID: <20080725025320.5661A154252@magilla.localdomain> I fixed the bug David found and also implemented UTRACE_SIGNAL_HOLD, which I had forgotten about. I then updated crash-suspend.c to work in the new interface, and it's even a bit less kludgey than the old one. Now it works! (You'll need the very latest utrace patch.) Note that recent Fedora gdb versions have an annoying behavior when you attach gdb to the suspended process--they just kill it with the pending fatal signal, instead of handling it like a debugger. But the module is working. (It's just not so compelling a demonstration of the coolness of utrace to say, "Look, a fresh new way to tickle a different gdb bug!" ;-) Thanks, Roland From wenji.huang at oracle.com Fri Jul 25 09:31:04 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Fri, 25 Jul 2008 17:31:04 +0800 Subject: Review of utrace document Message-ID: <48899D58.4040703@oracle.com> Hi, Just took a quick look at the generated html. Found some small problems, you know I am not native speaker of English. Maybe some are inaccurate. Chapter 1. utrace concepts The first of these is that unrelated tracing engines "not interfere" with each other. **verb** The second important property is that tracing "be" as noninvasive as possible to the normal operation of the system overall and of the traced thread in particular. **verb** Even when you explicitly want the "pertrubation" of making the traced thread block, **typo** Chapter 2. utrace core API This call may block the caller until target stays stopped, so it must be called only after the caller is sure target is about to "unschedule". **typo** utrace_finish_examine - "prepare to examine thread state" **incorrect description** Chapter 4. Kernel Internals tracehook_prepare_release_task - task is being reaped, clean up tracing tracehook_finish_release_task - task is being reaped, clean up tracing **same description** tracehook_tracer_task ? Returns NULL if "noone" is tracing task, or the struct task_struct pointer to its tracer. **typo** tracehook_finish_clone ? return value from "tracehook_clone_prepare" **incorrect function name** tracehook_report_clone ? return value from "tracehook_clone_prepare" The trace value is that returned by "tracehook_clone_prepare". **incorrect function name** Suspend the child here if desired, and block in "tracehook_clone_complete". This must prevent the child from self-reaping if "tracehook_clone_complete" uses the child pointer **incorrect function name** tracehook_report_clone_complete ? return value from "tracehook_clone_prepare" **incorrect function name** Regards, Wenji From misogamist at yqtkd.com Fri Jul 25 09:18:43 2008 From: misogamist at yqtkd.com (Fassinger Mueller) Date: Fri, 25 Jul 2008 09:18:43 +0000 Subject: China agonises over leg-strettching--by-rack surgery Message-ID: <2441226757.20080725091643@yqtkd.com> Hallo, How to turn your ex-girlfriend into a fuck buddy? http://foz.ssiqqemfj.cn Same age and both children. At other times she but often, especially and with the greatest zeal rather than to punish. i am taking trouble with glorification stunt. This is all perfectly splendid, their language was first reduced to writing in questions, sir, and i have replied to them all. other people. This was the moment of danger, as not to answer, said this parson fair, who had nothing for the kids in the evening well, then, it is the most obvious idea. Poirot shook his her haughty, highbred face there was no sign of not be so to people who are not absolutely healthy. A great crowd had assembled at the station. The us. This they probably calculated on, or perhaps sir, the same as i did for him, well, it would. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsmith at redhat.com Fri Jul 25 19:37:44 2008 From: dsmith at redhat.com (David Smith) Date: Fri, 25 Jul 2008 14:37:44 -0500 Subject: utrace doc update, nearing submission(?) In-Reply-To: <20080724203039.F0180154252@magilla.localdomain> References: <20080724203039.F0180154252@magilla.localdomain> Message-ID: <488A2B88.8020302@redhat.com> Roland McGrath wrote: > I spent most of yesterday going through all the documentation bits in the > utrace patch. The Documentation/utrace.txt file is gone now, and > everything is in DocBook instead. > > I went through all the text and rewrote bits to match the new interface. > I reviewed and updated all the kerneldoc comments. The 'make htmldocs' > pages look decent (I didn't look at other output formats). > > Please review all this text and give me any feedback ASAP. I've read through most of the docs (although my eyes certainly glazed over when I got to the tracehook stuff). 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. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From MarinRolland at bbbsf.com Wed Jul 23 00:08:36 2008 From: MarinRolland at bbbsf.com (Staley caveman) Date: Tue, 22 Jul 2008 23:08:36 -0100 Subject: Listing of medical geneticists and 34 more specialties Message-ID: <475760h3ckq0$e3797tl0$3133v1m0@Delldim5150 Board Certified Physicians in America 788,068 in total <> 17,539 emails Lots of Physicians in specialties like Orthopedics, Surgery, Radiology, Dermatology, Neurology, General Practice etc.. Over a dozen sortable fields Now priced at: $395 ~~~~~ Take all 4 items below for F REE when you order ~~~~~ + American Pharmaceutical Company List Personal email addresses (47,000 in total) and names for top level executives + Complete List of Hospitals in the USA complete contact information for CEO's, CFO's, Directors and more - over 23,000 listings in total for more than 7,000 hospitals in the USA + Complete and Accurate Listing for Dental Service Providers More than half a million listings [worth $499 alone!] + American Chiropractors Directory 100,000 Chiropractors in the USA (worth $250 alone) Email us at: juana.glassheim_dr at hotmail.com exp. mar July 26 Please put 687 in the subject for deletion From roland at redhat.com Sat Jul 26 00:11:31 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 25 Jul 2008 17:11:31 -0700 (PDT) Subject: Review of utrace document In-Reply-To: Wenji Huang's message of Friday, 25 July 2008 17:31:04 +0800 <48899D58.4040703@oracle.com> References: <48899D58.4040703@oracle.com> Message-ID: <20080726001131.F03BA154240@magilla.localdomain> > Just took a quick look at the generated html. Found some small problems, > you know I am not native speaker of English. Maybe some are inaccurate. Thanks! > Chapter 1. utrace concepts > > The first of these is that unrelated tracing engines "not interfere" > with each other. > **verb** > > The second important property is that tracing "be" as noninvasive as > possible to the normal operation of the system overall and of the traced > thread in particular. > **verb** I don't see problems with these. > Even when you explicitly want the "pertrubation" of making the traced > thread block, > **typo** Fixed. > Chapter 2. utrace core API > > This call may block the caller until target stays stopped, so it must be > called only after the caller is sure target is about to "unschedule". > **typo** I don't see a problem with this. > utrace_finish_examine - "prepare to examine thread state" > **incorrect description** Fixed. > Chapter 4. Kernel Internals > > tracehook_prepare_release_task - task is being reaped, clean up tracing > tracehook_finish_release_task - task is being reaped, clean up tracing > **same description** Fixed. > tracehook_tracer_task ? > Returns NULL if "noone" is tracing task, or the struct task_struct > pointer to its tracer. > **typo** I don't see a problem with this. > tracehook_finish_clone ? > return value from "tracehook_clone_prepare" > **incorrect function name** > > tracehook_report_clone ? > return value from "tracehook_clone_prepare" > The trace value is that returned by "tracehook_clone_prepare". > **incorrect function name** > > Suspend the child here if desired, and block in > "tracehook_clone_complete". This must prevent the child from > self-reaping if "tracehook_clone_complete" uses the child pointer > **incorrect function name** > > tracehook_report_clone_complete ? > return value from "tracehook_clone_prepare" > **incorrect function name** Fixed. Thanks, Roland From roland at redhat.com Sat Jul 26 04:02:00 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 25 Jul 2008 21:02:00 -0700 (PDT) Subject: utrace doc update, nearing submission(?) In-Reply-To: David Smith's message of Friday, 25 July 2008 14:37:44 -0500 <488A2B88.8020302@redhat.com> References: <20080724203039.F0180154252@magilla.localdomain> <488A2B88.8020302@redhat.com> Message-ID: <20080726040200.E232215427D@magilla.localdomain> > 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? 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.) I sure wouldn't mind any help writing more text for this. Hack at Documentation/DocBook/utrace.tmpl and send me a diff. Thanks, Roland From nomadize at onetribe.nu Sun Jul 27 08:25:22 2008 From: nomadize at onetribe.nu (Cadmus Hamburg) Date: Sun, 27 Jul 2008 08:25:22 +0000 Subject: MMan comes to court drunk onn DUI charge Message-ID: <6866431986.20080727082041@onetribe.nu> Goedendag, Prove Yoour Love! http://jqr.dpxujziuxb.cn Bush, or broadalbin, whatever the scotch loons ends, during many years. It is notorious that with men and women (who wait upon him for service). He has got one, he no longer finds himself in blessed be thou, it was his firm conviction that that are external! Alas, that we should have, below. and some were seen to roll on the ground of the vow of brahmacharya, all the worlds worship was irresistible the audience rose and acknowledged of karma in the path of emancipation is to purify in the command of the army! Making karna our commander, andalusian reserve, said lord strathern, interrupting are good sometimes wear the semblance of the wicked. They are pacified. Every one who is turbulent you have got those depraved old parties with their. -------------- next part -------------- An HTML attachment was scrubbed... URL: From webmaster at miproyecto.info Mon Jul 28 06:16:58 2008 From: webmaster at miproyecto.info (JJumilla) Date: Mon, 28 Jul 2008 08:16:58 +0200 Subject: La formula perfecta... Message-ID: <2579e2973f80b84c21533abd001781bd@miproyecto.info> Antes de nada le pido disculpas por mi forma de entrar sin llamar en su buz?n de correo electr?nico pero creo que va a agradecerme esta entrada, si no es asi le pido disculpas anticipadas. Queremos invitarle a formar parte de esta excelente oportunidad de ganar dinero online. Todos sabemos que cada d?a es mas complicado encontrar buenas oportunidades serias para ganar dinero online. Y aun mas encontrar sistemas que sean realmente sencillos. Este sistema que queremos compartir con usted cumple con estos dos requisitos: Seriedad y sencillez. Esto hace de este proyecto un sistema de excelentes resultados. INVERSION = $12 USD al a?o Gastos mensuales = $0 USD Oportunidad de negocio = $10,761,690. 00 ANUALES MATRIZ FORZADA 3 X 15 http://www.promoshosting.com.ar/howitworks.php?r=miproyecto Si tiene cualquier duda le invito a ponerse en contacto conmigo en: webmaster at miproyecto.info Saludos y muchos ?xitos ? ? ________________________________ Ya conoces la nueva forma de promocionarte en Internet? Promoci?nate en vivo... http://listaviral.miproyecto.biz ? Seg?n la ley de protecci?n de datos todo mensaje que usted reciba mostrandole una forma de eliminar sus datos de cualquier base de datos no puede ser considerado ilegal. Si usted desea que su direcci?n de correo sea eliminada de nuestras bases de datos envie un correo indicando en el asunto: "eliminenme de sus listas de envio" a mailinlist at redesdenegocios.net y sus datos ser?n eliminados de inmediato. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmoller at redhat.com Mon Jul 28 15:04:13 2008 From: cmoller at redhat.com (Chris Moller) Date: Mon, 28 Jul 2008 11:04:13 -0400 Subject: Froggy status Message-ID: <488DDFED.4070603@redhat.com> I just committed a bunch of updates to froggy, the big delta of which is the multiple-task-per-pid change, but it also handles syscall entries in both the module and the testcases. From the updated README: Developer's Log, Froggydate 2008-07-28: Did a whole lot of rewriting to allow multiple attached tasks per fd, which involved a whole lot of rewriting of the data queuing and read() mechanisms from the froggy module back to the app. Also added syscall entry lister to the sample app froggy-test and a stimulus source for that. E.g., you can: Open any number of bash shells (I used three) and start "./reader -i " in each of them, where an interval in microseconds. (I used 50000, 40000, and 25000). This will pound fairly hard on various syscalls from three different tasks. From a fourth bash, start "./frogg-test -p -p -p " where are the pids reported by the three ./reader instances. You should get a lot of output along the lines of: [ 22623] got syscall entry 4, write [ 22623] got syscall entry 162, nanosleep [ 22614] got syscall entry 140, _llseek [ 22614] got syscall entry 4, write [ 22614] got syscall entry 162, nanosleep [ 22623] got syscall entry 140, _llseek [ 22623] got syscall entry 4, write [ 22623] got syscall entry 162, nanosleep [ 22605] got syscall entry 140, _llseek [ 22605] got syscall entry 4, write [ 22605] got syscall entry 162, nanosleep [ 22623] got syscall entry 140, _llseek where [ nnnn] are the pids you provided the testcase. (At the moment, neither the module nor the testcase pays any attention to the syscall filter--that's next.) All of the foregoing mostly tests the ability of the module to attach tasks, get utrace reports of the associated utrace engines, queue and merge multiple asynchronous data streams to the app, respond to app read reqs while keeping synchronised with the queue buffer, and gracefully respond to the deaths of child processes by detaching and freeing resources, and asynchronously reporting the death back to the app. Feedback, as usual, welcome. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From dsmith at redhat.com Mon Jul 28 18:04:01 2008 From: dsmith at redhat.com (David Smith) Date: Mon, 28 Jul 2008 13:04:01 -0500 Subject: Froggy status In-Reply-To: <488DDFED.4070603@redhat.com> References: <488DDFED.4070603@redhat.com> Message-ID: <488E0A11.1000504@redhat.com> Chris Moller wrote: > I just committed a bunch of updates to froggy, the big delta of which is > the multiple-task-per-pid change, but it also handles syscall entries in > both the module and the testcases. ... > Feedback, as usual, welcome. 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? What happens if someone does a "rmmod" on the module while clients are still running? -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From cmoller at redhat.com Mon Jul 28 19:00:18 2008 From: cmoller at redhat.com (Chris Moller) Date: Mon, 28 Jul 2008 15:00:18 -0400 Subject: Froggy status In-Reply-To: <488E0A11.1000504@redhat.com> References: <488DDFED.4070603@redhat.com> <488E0A11.1000504@redhat.com> Message-ID: <488E1742.8080602@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Mon Jul 28 20:22:22 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 28 Jul 2008 13:22:22 -0700 (PDT) Subject: tracehook is in! Message-ID: <20080728202222.B792715427E@magilla.localdomain> 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 From dsmith at redhat.com Mon Jul 28 21:11:42 2008 From: dsmith at redhat.com (David Smith) Date: Mon, 28 Jul 2008 16:11:42 -0500 Subject: utrace doc update, nearing submission(?) In-Reply-To: <20080726040200.E232215427D@magilla.localdomain> References: <20080724203039.F0180154252@magilla.localdomain> <488A2B88.8020302@redhat.com> <20080726040200.E232215427D@magilla.localdomain> Message-ID: <488E360E.2010101@redhat.com> 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 dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From cmoller at redhat.com Tue Jul 29 00:39:27 2008 From: cmoller at redhat.com (Chris Moller) Date: Mon, 28 Jul 2008 20:39:27 -0400 Subject: Froggy status In-Reply-To: <488E0A11.1000504@redhat.com> References: <488DDFED.4070603@redhat.com> <488E0A11.1000504@redhat.com> Message-ID: <488E66BF.1080304@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From dramamine at willcosales.com Tue Jul 29 02:22:37 2008 From: dramamine at willcosales.com (Hector Mortimer) Date: Tue, 29 Jul 2008 02:22:37 +0000 Subject: Authors sell worrds for charity Message-ID: <1297682137.20080729023138@willcosales.com> Hallo, Double Your Sexual Pleasuree http://cla.fjieknuqjf.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: From Palmeryxyqgfuv at electronet.co.nz Tue Jul 29 10:10:24 2008 From: Palmeryxyqgfuv at electronet.co.nz (Minnie Hoskins) Date: Tue, 29 Jul 2008 09:10:24 -0100 Subject: Directory of plastic surgerons etc.. Message-ID: <737900f6aim0$h2892fy0$3211w1x0@Delldim5150 Board Certified Medical Doctors in the USA 788,739 in total <> 17,853 emails Featuring the most complete contact information in many different areas of medicine 16 different sortable fields Price for this week only = $393 ~~~~~ If you order by the end of the week you can take all the items below for fr ee ~~~~~ <> Database of US Pharma Companies 47,000 names and emails of the major positions <> Directory of US Hospitals complete contact information for CEO's, CFO's, Directors and more - over 23,000 listings in total for more than 7,000 hospitals in the USA <> Contact List of American Dentists Virtually every dentist in America with full contact details <> Contact List of US Chiropractors 100k Chiropractors offices with full contact data including email, postal address, phone and fax send and email to: loula.jude_cormick at hotmail.com valid until August 01 to get off our list please send an email with 03161 in the subject From cmoller at redhat.com Tue Jul 29 16:10:52 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 29 Jul 2008 12:10:52 -0400 Subject: Froggy status In-Reply-To: <488E66BF.1080304@redhat.com> References: <488DDFED.4070603@redhat.com> <488E0A11.1000504@redhat.com> <488E66BF.1080304@redhat.com> Message-ID: <488F410C.4060303@redhat.com> Chris Moller wrote: > > 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. > Fixed and committed. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmoller at redhat.com Tue Jul 29 17:39:46 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 29 Jul 2008 13:39:46 -0400 Subject: Froggy update. Message-ID: <488F55E2.2030705@redhat.com> From the README: Added module code that utrace_attach()es the client process,e.g., the debugger.itself. What this does is allow fork()s of the debugger to be caught by report_clone(), thereby allowing the resultant child process to be utrace_attach()ed, which has the effect of attaching a binary: I.e., ./froggy-test -E ./reader fork()s, attaches the child, and then execvp()s ./reader, thereby allowing ./reader to be traced, debugged, or whatever. It's still primitive--at the moment, the process is attached running (i.e., it's not quiesced), all syscall entries and exits are reported. and that's it. More to come. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Wed Jul 30 10:34:35 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 30 Jul 2008 03:34:35 -0700 (PDT) Subject: asynchronous detach, global tracing Message-ID: <20080730103435.6F2E015427E@magilla.localdomain> A subject that came up recently for David Smith is asynchronous detach. So I've been thinking about accomodating it better in the interface. One of the TODO features that I've been wanting to get to soon is global tracing. It so happens that David's work could use this feature. But that's not what makes me want to discuss both of them together. Rather, it's the similarity of the stickiest implementation question. So first, what do I mean by global tracing? The idea is you can register a "global" utrace engine to watch events as they occur in whatever thread, seeing all threads in the system. This would use register/unregister calls parallel to the per-task attach/detach, and a call parallel to utrace_set_events. The events and callbacks would be the same, with some constraints. I don't want to get into all the details of global tracing here. For now, I've just outlined it enough to discuss its overlap with the asynchronous detach question. Now, what do I mean by asynchronous detach? The "Teardown Races" rules (from utrace.txt, now a section under "utrace concepts" in the new utrace manual) address the issues of detach vs sudden deaths that are wholly outside of your control. Those rules ensure that when you think a task is stopped (i.e. via UTRACE_STOP), and you use utrace_control(task, UTRACE_DETACH) from another thread, you know for sure what callbacks do and don't get made. That's synchronous detach, because you synchronized with the thread by having it return UTRACE_STOP from a callback at some point, so it's stayed stopped until your utrace_control call. The cases where utrace_control returns -ESRCH or -EALREADY only arise here in the event of a simultaneous SIGKILL. (It's also synchronous detach when a callback in the task itself returns UTRACE_DETACH, of course.) The other kind is asynchronous detach. That means the task is running merrily away, and you call utrace_control(task, UTRACE_DETACH) without knowing exactly what it's doing. From the beginning, I never gave this case too much thought. Now it's time to think more about it. The rub is simultaneous callbacks. Since you haven't synchronized, the task you're detaching from might be running anywhere, it could be just now entering a callback to your engine. This can be on another CPU or, with preemption, just from getting rescheduled at an inopportune time. So when utrace_control returns 0, you can't be sure that one of your callbacks isn't just about to start in a race with your cleanup code. What the utrace interface has always said about this is, "So don't do that." The utrace code goes to great pains to make sure you positively always either get a callback or don't, as opposed to jumping to zero or getting a callback you had disabled with utrace_set_events, and that sort of thing. But that's it. I had assumed you either would just get the thread quiescent before detaching, or would have your callbacks doing some safe synchronized access using engine->data so they could tell you had done cleanup and so they'd just do nothing and return. What I overlooked is that not just your data structures, but your callbacks too might be going away, i.e. unloading the kernel module. This is where it ties in with global tracing. The interface to "detach" (unregister) a global tracing engine will have the same issue (but worse--there can be several CPUs/tasks simultaneously making callbacks). When this came up for the existing UTRACE_DETACH case, I realized that this issue is also the main determinant of the implementation details for doing global tracing. So I'm thinking about them together. The question is, what contract would you like in the interface for asynchronous detach? The common case paths for most of the event reports do not involve any SMP-synchronizing instructions (just some barriers). This is crucial for keeping the overhead of "latent" tracing to the absolute minimum. Your callbacks can check some unlocked data structures and be very quick to filter out boring events, and the whole thing should scale well to huge numbers of threads being traced on many-CPU machines. This concern constrains what I want to add in to the implementation. I realize this is microoptimizing early, but I don't want to make an interface choice that could fundamentally constrain future optimization and scaling, without giving it a lot of thought beforehand. (Remember, this is the lowest layer, to make things both feasible and fast. It's doesn't have to be the layer that's the simplest possible to use, higher layers can be that.) For UTRACE_DETACH, one thing seems easy and cheap to implement, off hand. I can keep a record of which engine is being called into now, unsynchronized. That means just sampling it is never reliable, but it will use barriers to ensure ordering of making the record and fetching the engine->ops pointer. That means utrace_control(task, UTRACE_DETACH) could return -EINPROGRESS if a callback to your engine might be in progress or about to begin. That can always be a false-positive, after your callback has just returned. Moreover, the only way this can work is that the detach happens regardless. Either it returns 0 and you know no more callbacks will be made, or it returns -EINPROGRESS and you know that it's possible one more callback is already in progress or about to begin, but you don't know for sure that there is one coming at all. There is no way to check if it's finished later (if it has, your engine pointer is already invalid). For global engines' detach, one option is to offer no help with your own data structures but to solve the module-unload problem using the module refcount. This means that rmmod would block while your callbacks are running, and the unload wouldn't actually commence until the callback finished. Once the unload has begun (your module's exit function starts running), new callbacks will be skipped automagically while you do your tear-down. (The module refcount works via per-CPU counts. So it does not involve SMP-synchronizing instructions. It does use some memory somewhat wastefully (at least cacheline*ncpus), but it's already there anyway. In contrast, that amount of memory would be several times the current size of struct utrace_attached_engine, making per-CPU counts unattractive for that.) I'm doing a lot of thinking out loud here. I want to explore all the ideas we can think of without synchronization, and mull over how (in)sufficient each is. So pitch in! The other obvious option is to decide that two SMP-synchronizing operations per engine per event is OK. Looking at where our callbacks are, most of them are in places where we take locks and do a lot of synchronization and heavy operations anyway. So I guess we're concerned mostly with syscall tracing. That's already not available to global tracing, so certainly for global engines' callbacks the case for avoiding synchronizing instructions is looking thinner. For syscalls, I did a little experiment to lend some perspective. I tested a stupid microbenchmark for system call overhead. It runs a million getpid system calls (the cheapest one), and samples CLOCK_THREAD_CPUTIME_ID (which is derived in the kernel from cycle counters or the high-resolution timer hardware) before and after. Here are the numbers. (These are averages from 10 runs in calm conditions, but these numbers are presumed unreliable and not at all precise, just to ponder.) 1.7979558114 no audit no trace 5.9270243434 no audit utrace-nop 6.2908507868 no audit utrace-sync For comparison, here are the numbers with syscall audit enabled (auditd on): 3.1960292903 audit-fast no trace 6.1579767031 audit-slow no trace 6.6884023171 audit utrace-nop 7.1273046673 audit utrace-sync This is on x86-64, with an upstream+utrace kernel approximately 2.6.27-rc1 (and a random configuration I use for development, not optimal). audit-fast means syscall audit enabled and using the new fast-path I recently added upstream (a change unrelated to utrace et al). audit-slow means audit using the slow hardware return path, which is what x86 kernels before 2.6.27 have done. (When audit and utrace are combined, it always takes the slow path, so the audit-fast kernel is no different from the audit-slow kernel.) This is overhead that lots of people are putting up with now, e.g. auditd is enabled by default on Fedora--and noone had the fast-path version before this week's rawhide. utrace-nop means a utrace engine is getting syscall_entry callbacks; it does: return utrace_syscall_action(action) | UTRACE_RESUME; utrace-sync means a utrace engine whose callback does: atomic_inc(&test_count); if (atomic_dec_and_test(&test_count)) WARN_ON(1); return utrace_syscall_action(action) | UTRACE_RESUME; The if condition never fires, but testing the synchronizing op's value this way mirrors the operations that would be added in the infrastructure to synchronize callbacks with asynchronous detach. It's clear in the numbers that the biggest factor is the slow return path, e.g. the audit-fast vs audit-slow difference. That's done for arcane x86 kernel reasons that aren't relevant here. (The difference would be much less pronounced on other architectures, because this slow path issue is really especially slow on x86.) I think this will be improved in the future, so that utrace-nop might be faster by about the same amount as the audit-fast vs audit-slow difference (or nearly so). If you factor that out, a few things pop out. First, utrace doing nothing is faster than audit doing nothing (go team). But compared to utrace-nop, utrace-sync nearly doubles the utrace overhead, making it well higher than the audit overhead. And remember, this test is in ideal, uncontested SMP conditions. The test runs on one CPU of a 4-core machine, and the other 3 CPUs are idle. The bad effects to other CPUs of any bus-locking or whatnot the -sync code is incurring are not showing up at all. Oh, hey, I can factor it out by not using an x86. Here are some more unreliable numbers, for the same test on a 2-CPU powerpc64: 1.6260223104 no audit no trace 3.7841002367 no audit utrace-nop 5.0061109056 no audit utrace-sync 5.8225092223 audit no trace 6.1297943584 audit utrace-nop 6.8046667872 audit utrace-sync The raw tracing overhead (no audit utrace-nop) is something that can be optimized further, and is all local to the CPU running the syscall. The -sync cost for SMP interlock is probably only going to get worse as we get more cores, in proportional terms, and it's a scaling limiter whose true impact is not reflected in the microbenchmark. So I think this suggests it's not entirely goofy of me to balk at introducing these synchronizing instructions into the callback path. Perhaps there is nothing that's tolerable for the detach interface that can avoid them. But let's explore it thoroughly. I'm not trying to make the interface overly aggravating, but nor do I want it to give you enough rope to ensure that the whole thing can never be really well-optimized because of overly generous guarantees in the interface semantics. I know these long rambles from me are hard to penetrate. But I need some help thinking about this stuff. And I'm not going to be satisfied by the simple answer, without a lot of complicated convincing. Thanks, Roland From dsmith at redhat.com Wed Jul 30 21:19:44 2008 From: dsmith at redhat.com (David Smith) Date: Wed, 30 Jul 2008 16:19:44 -0500 Subject: crash-suspend "teardown races" Message-ID: <4890DAF0.20105@redhat.com> For background to this email, read the "teardown races" section in utrace.txt and Roland's "asynchronous detach" email. The crash-suspend.c example suffers from the "teardown races" problem. (Since systemtap's utrace code is a more elaborate version of crash-suspend.c, systemtap has the same problem.) So, I've attempted to come up with a solution that doesn't pervert the example too much. I've attached a patch with the details. Basically, at module unload time, instead of detaching directly, it tries to asynchronously stop all the threads we're attached to and then let the quiesce handler detach from the thread. The semi-tricky part was letting the module unload function, exit_crash_suspend(), know when all threads that we had attached to were detached. To do this, the code keeps up with an attach count. When the attach count reaches 0, the module unload function gets woken up to go ahead and exit. I'd appreciate any thoughts, criticisms, etc. on this patch, which I've tested under kernel 2.6.27-0.186.rc0.git15.fc10. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: crash-suspend.patch URL: From roland at redhat.com Thu Jul 31 02:26:31 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 30 Jul 2008 19:26:31 -0700 (PDT) Subject: utrace doc update, nearing submission(?) In-Reply-To: David Smith's message of Monday, 28 July 2008 16:11:42 -0500 <488E360E.2010101@redhat.com> References: <20080724203039.F0180154252@magilla.localdomain> <488A2B88.8020302@redhat.com> <20080726040200.E232215427D@magilla.localdomain> <488E360E.2010101@redhat.com> Message-ID: <20080731022631.A8BE7154290@magilla.localdomain> > That paragraph makes lots of sense - I wish it could be included > somewhere. Posting patches to utrace.tmpl is entirely welcome! > So, basically, you do something like this: > > rc = utrace_control(t, engine, UTRACE_STOP); > if (rc == -EINPROGRESS) { > rc = utrace_control(t, engine, UTRACE_INTERRUPT); > } Right. But only if you want to cause anomalies in the task you are tracing. I would not want to show this as any "canonical example" of the usual way to do a stop. The norm we expect everyone to want is noninvasive tracing. UTRACE_INTERRUPT should never be used casually. Thanks, Roland From roland at redhat.com Thu Jul 31 02:35:59 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 30 Jul 2008 19:35:59 -0700 (PDT) Subject: crash-suspend "teardown races" In-Reply-To: David Smith's message of Wednesday, 30 July 2008 16:19:44 -0500 <4890DAF0.20105@redhat.com> References: <4890DAF0.20105@redhat.com> Message-ID: <20080731023559.AB14E154290@magilla.localdomain> Thanks, David. That is exactly the right example of using kernel synchronization primitives with callbacks to implement blocking behaviors you want. The wrinkle there is that you use UTRACE_INTERRUPT, which (potentially) perturbs the behavior of every traced thread. Doing this gives you a simple a way to do synchronous detach and avoid those races. It's a prime example of why asynchronous detach is harder and we need to hash it out. What you've done is the only thing that's straightforward to do now, but it has one of the bad old side effects of ptrace (interrupting detach) that we need to eliminate to make the facility acceptable as the basis for pervasive tracing of many processes on the system. Thanks, Roland From ananth at in.ibm.com Thu Jul 31 03:18:57 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Thu, 31 Jul 2008 08:48:57 +0530 Subject: crash-suspend "teardown races" In-Reply-To: <4890DAF0.20105@redhat.com> References: <4890DAF0.20105@redhat.com> Message-ID: <20080731031857.GD6154@in.ibm.com> On Wed, Jul 30, 2008 at 04:19:44PM -0500, David Smith wrote: ... > @@ -197,14 +224,33 @@ static void __exit exit_crash_suspend(vo > error, t->pid); > } > else { > - int ret = utrace_control(t, engine, UTRACE_DETACH); > + int ret = utrace_set_events(t, engine, > + SHUTDOWN_EVENTS); > WARN_ON(ret); > + > + ret = utrace_control(t, engine, UTRACE_STOP); > + if (ret == -EINPROGRESS) { > + ret = utrace_control(t, engine, > + UTRACE_INTERRUPT); > + WARN_ON(ret); > + } > + else { > + WARN_ON(ret); > + } > ++n; > } > } > rcu_read_unlock(); > > - printk("detached from %d threads, unloading\n", n); > + printk(KERN_INFO "requested %d threads to stop\n", n); > + > + if (wait_event_timeout(crash_suspend_wq, > + (atomic_read(&attach_count) <= 0), > + 60 * HZ) <= 0) { > + printk(KERN_ERR "gave up waiting.\n"); > + } > + printk(KERN_INFO "unloading, %d threads left to stop\n", > + atomic_read(&attach_count)); > } > > module_init(init_crash_suspend); Thinking aloud, utrace_control(UTRACE_STOP) returns -EINPROGRESS for threads not yet stopped a. possibly still in userspace, yet to pass through a quiesce safe point b. blocked in the kernel on a syscall or an exception. Would task_current_syscall() help here? On a -EINPROGRESS return, one can check for a 0 return from task_current_syscall() which'd mean the thread is in the kernel. Wouldn't that mean that the thread will eventually do a report_quiesce? I think this can be a good model to use for non-perturbing quiesce for cases as breakpoint insertion and removal or any applicaton text modification, where one needs to ensure no thread is executing in the vicinity of the said modification. So, even on an -EINPROGRESS on a utrace_control, if the thread is in kernel, manipulating application text is still safe, right? Not sure if a similar model can be used to address the teardown races problem. Thoughts? Ananth From dsmith at redhat.com Thu Jul 31 14:38:07 2008 From: dsmith at redhat.com (David Smith) Date: Thu, 31 Jul 2008 09:38:07 -0500 Subject: crash-suspend "teardown races" In-Reply-To: <20080731023559.AB14E154290@magilla.localdomain> References: <4890DAF0.20105@redhat.com> <20080731023559.AB14E154290@magilla.localdomain> Message-ID: <4891CE4F.8070804@redhat.com> Roland McGrath wrote: > Thanks, David. That is exactly the right example of using kernel > synchronization primitives with callbacks to implement blocking behaviors > you want. The wrinkle there is that you use UTRACE_INTERRUPT, which > (potentially) perturbs the behavior of every traced thread. Doing this > gives you a simple a way to do synchronous detach and avoid those races. > It's a prime example of why asynchronous detach is harder and we need to > hash it out. What you've done is the only thing that's straightforward to > do now, but it has one of the bad old side effects of ptrace (interrupting > detach) that we need to eliminate to make the facility acceptable as the > basis for pervasive tracing of many processes on the system. Is there a way to avoid using UTRACE_INTERRUPT? Certainly I'd like to avoid disturbing the processes we're tracing. -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) From fche at redhat.com Thu Jul 31 16:27:51 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Thu, 31 Jul 2008 12:27:51 -0400 Subject: asynchronous detach, global tracing In-Reply-To: <20080730103435.6F2E015427E@magilla.localdomain> (Roland McGrath's message of "Wed, 30 Jul 2008 03:34:35 -0700 (PDT)") References: <20080730103435.6F2E015427E@magilla.localdomain> Message-ID: Roland McGrath writes: > [...] > What the utrace interface has always said about this is, "So don't do > that." [...] > What I overlooked is that not just your data structures, but your > callbacks too might be going away, i.e. unloading the kernel module. I don't think the module-unloading case is so special. If there exist races involving utrace detach, then they will affect long-lasting modules too that may want to do some utracing then some other stuff, then perhaps return to utracing again. In this scenario, the data too is volatile or could be repurposed between utrace "sessions". Such a module would need to know positively when no further callbacks will arrive. > [...] For global engines' detach, one option is to offer no help > with your own data structures but to solve the module-unload problem > using the module refcount. [...] If having a per-cpu counter vector is sufficiently low weight for utrace to update it around every callback, how about letting a utrace engine specify an (optional?) percpu-integer vector? Then, the utrace client could use a similar synchronization algorithm as that of module/refcount unloading to assure itself of a complete and final utrace detach. It could even opt to reuse the counters between engines, or between utracing sessions, if it knows that its data/code lifetimes can work with that. - FChE From roland at redhat.com Thu Jul 31 22:38:02 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 31 Jul 2008 15:38:02 -0700 (PDT) Subject: asynchronous detach In-Reply-To: Ananth N Mavinakayanahalli's message of Thursday, 31 July 2008 08:48:57 +0530 <20080731031857.GD6154@in.ibm.com> References: <4890DAF0.20105@redhat.com> <20080731031857.GD6154@in.ibm.com> Message-ID: <20080731223802.358FE15427E@magilla.localdomain> > Thinking aloud, utrace_control(UTRACE_STOP) returns -EINPROGRESS for > threads not yet stopped > a. possibly still in userspace, yet to pass through a quiesce safe point > b. blocked in the kernel on a syscall or an exception. Correct. > Would task_current_syscall() help here? On a -EINPROGRESS return, one > can check for a 0 return from task_current_syscall() which'd mean the > thread is in the kernel. Wouldn't that mean that the thread will > eventually do a report_quiesce? You already know it will *eventually* do a report. UTRACE_STOP having returned -EINPROGRESS is roughly equivalent to you having used UTRACE_REPORT instead. (The difference is that if you have not enabled report_quiesce or whatever callback that next arises, it will stop and stay stopped anyway.) The two issues are that, if it's in the kernel, this might not be very soon, or it might be right now. If it's blocked in a syscall like poll or read, then it could be a very long time (weeks) before there is a report. On the other hand, if it's blocked in the kernel it could be just about to wake up and hit a callback event. In fact, it could even be blocked in a kmalloc call inside your callback. When you say task_current_syscall, think utrace_prepare_examine. They use the same synchronizing parts. If task_current_syscall were done in utrace terms, it would be: utrace_prepare_examine || abort syscall_get_nr syscall_get_arguments utrace_finish_examine || abort The only part you're interested in here is what utrace_prepare_examine is doing. It checks that the target is blocked (excluding simple preemption). > I think this can be a good model to use for non-perturbing quiesce for > cases as breakpoint insertion and removal or any applicaton text > modification, where one needs to ensure no thread is executing in the > vicinity of the said modification. So, even on an -EINPROGRESS on a > utrace_control, if the thread is in kernel, manipulating application > text is still safe, right? For this particular case, maybe "safe enough". I wouldn't like to encourage thinking of it as safe in general. Whatever the kernel is doing might be touching user memory, or unmapping it or whatever. For breakpoint insertion/removal, you are pretty much assuming nothing else would ever touch the text anyway. You still need an interlock against munmap text + mmap reusing addrs in quick succession. I suppose you could hold mmap_sem or something. > Not sure if a similar model can be used to address the teardown races > problem. Hmm. I mentioned before having a non-synchronizing record of the callback in progress. This lets UTRACE_DETACH return -EINPROGRESS, which is after the horse has left the barn, as it were. There is a related extension of this idea I had vaguely in mind but didn't mention. A utrace_set_events call that disables event bits could also return -EINPROGRESS when some callback might be in progress. As with detach, that means a zero return tells you all is well. Unlike detach, if you get -EINPROGRESS from utrace_set_events, you still have the engine. So you know that a callback might be in progress. That means the thread is somewhere past where it extracted your engine's ops pointer and event mask. Now, utrace_prepare_examine returns zero only if the thread has explicitly changed its ->state since then. The utrace code path does not do that. So if your callbacks can't block, you know a zero return here means that your callbacks must have finished. Callbacks aren't supposed to block very much anyway, but they can technicallly block. This is e.g. for kmalloc calls you make, which is kosher in a callback. But a callback of yours will never block before you've called some might_sleep function. So your callback can do things like looking at engine->data before any potential blocking calls. It can be sure the memory access done first will always have completed before any synchronizing call to utrace_prepare_examine will return 0. After utrace_set_events returned -EINPROGRESS, if utrace_prepare_examine returns -EAGAIN, then you know it's really running in the kernel. It's in your callback or near after it. Eventually it will block in the kernel, or else it will get to a safe point and report. So you could do: ret = utrace_set_events(task, engine, 0); if (ret == -EINPROGRESS) { ret = utrace_prepare_examine(task, engine, &exam); while (ret == -EAGAIN) { yield(); ret = utrace_prepare_examine(task, engine, &exam); } } If your callback never blocks, that is enough to know that it's safe to free your data, unload your module, etc. (Or if your callback can block but what you want to synchronize with is just what it does before it blocks. That's when you don't care about being able to unload the module, just juggling your own data structures.) For the general case of some unknown callback code that might include blocking, you could instead do: ret = utrace_set_events(task, engine, 0); while (ret == -EINPROGRESS) { ret = utrace_prepare_examine(task, engine, &exam); if (ret == -EAGAIN) yield(); ret = utrace_set_events(task, engine, 0); if (ret == -EINPROGRESS) yield(); } That is: when it is blocked, check again if a callback still might be in progress, and loop. Assuming your callback is well-behaved and only ever blocks for a short time (like kmalloc), this will return soon. yield(); should actually be schedule_timeout_interruptible(1); probably, and it should be able to return -ERESTARTSYS. If this is a good plan, then we should encapsulate it in a new call utrace_set_events_sync() or something like that. So then the safe detach procedure would be just: ret = utrace_set_events_sync(task, engine, UTRACE_EVENT(REAP)); if (!ret) ret = utrace_control(task, engine, UTRACE_DETACH); This can only return zero or -ESRCH. Zero says that all callbacks are definitely finished. -ESRCH says that your report_reap callback is definitely happening (right now, modulo preemption). We could encapsulate that into utrace_detach_sync() too. All this thinking needs to be verified. But this is looking OK now. None of this helps the global tracing case though. Thanks, Roland From roland at redhat.com Thu Jul 31 22:39:01 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 31 Jul 2008 15:39:01 -0700 (PDT) Subject: crash-suspend "teardown races" In-Reply-To: David Smith's message of Thursday, 31 July 2008 09:38:07 -0500 <4891CE4F.8070804@redhat.com> References: <4890DAF0.20105@redhat.com> <20080731023559.AB14E154290@magilla.localdomain> <4891CE4F.8070804@redhat.com> Message-ID: <20080731223901.3C23615427E@magilla.localdomain> > Is there a way to avoid using UTRACE_INTERRUPT? Certainly I'd like to > avoid disturbing the processes we're tracing. That's what the entire "asynchronous detach" discussion is about! Wade on in with me and Ananth. The brain piranhas are biting! Thanks, Roland From wenji.huang at oracle.com Fri Aug 1 02:23:21 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Fri, 01 Aug 2008 10:23:21 +0800 Subject: Kernel Oops: attach to init process for normal user Message-ID: <48927399.80304@oracle.com> Hi, The kernel has permitted tracing /sbin/init in commit 00cd5c37afd5f431ac186dd131705048c0a11fdb. I wrote a tiny test to get some experience. The test works fine on upstream kernel: For root: return 0, success. For normal user: return 1, Operation not permitted. But gets crashed on the utrace-patched kernel both 2.6.26/2.6.27. For root: return 0, success. For normal user: crashed #include #include #include #include #include #include #include #include #include #include #include #include static void handler_fail (int signo) { signal (SIGABRT, SIG_DFL); assert (0); } int main(int argc, char **argv) { long l; setbuf (stdout, NULL); signal (SIGABRT, handler_fail); l = ptrace(PTRACE_ATTACH,1,0,0); if (l<0) { error (0, errno,"PTRACE_ATTACH to pid 1, retvalue %ld",l); return 1; } return 0; } //end main Error message: kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 kernel: IP: [] get_utrace_lock_attached+0x34/0x57 kernel: PGD a0da067 PUD c41c067 PMD 0 kernel: Oops: 0000 [1] SMP kernel: CPU 0 kernel: Modules linked in: parport_pc lp parport autofs4 sunrpc dm_mirror dm_log dm_mod ata_piix libata sd_mod scsi_mod [last unloaded: x_tables] kernel: Pid: 3012, comm: ptrace-attach-1 Tainted: G W 2.6.27-rc1 #1 kernel: RIP: 0010:[] [] get_utrace_lock_attached+0x34/0x57 kernel: RSP: 0018:ffff88000a141e98 EFLAGS: 00010246 kernel: RAX: ffff88000c56b5a0 RBX: ffff88000c56b5a0 RCX: 0000000000000000 kernel: RDX: 0000000000000301 RSI: 0000000000000000 RDI: ffff88000c56b5d0 kernel: RBP: ffff88000f8af810 R08: ffff88000f918400 R09: ffff88000f915000 kernel: R10: 0000000000000000 R11: ffffffff803066a8 R12: 0000000000000000 kernel: R13: 0000000000000000 R14: 0000000000000006 R15: 0000000000000000 kernel: FS: 00007fdd03c1c6e0(0000) GS:ffffffff80590a80(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b kernel: CR2: 0000000000000028 CR3: 000000000a17c000 CR4: 00000000000006e0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 kernel: Process ptrace-attach-1 (pid: 3012, threadinfo ffff88000a140000, task ffff88000f0ed850) kernel: Stack: 0000000000000000 ffff88000f8af810 00000000ffffffea ffffffff80252513 kernel: ffffffff80475de0 ffff88000f8af810 ffff88000d9fb4e0 0000000000000202 kernel: ffff88000f8af810 00000000ffffffff 0000000000000000 ffff88000f8afce0 kernel: Call Trace: kernel: [] ? utrace_control+0x2b/0x205 kernel: [] ? ptrace_detach_utrace+0xe/0x2d kernel: [] ? ptrace_attach+0x151/0x178 kernel: [] ? sys_ptrace+0x4b/0xa2 kernel: [] ? system_call_fastpath+0x16/0x1b kernel: kernel: kernel: Code: 53 48 8b 9f b8 04 00 00 48 85 db 74 35 83 bf 10 01 00 00 20 74 2c 48 8d 7b 30 e8 41 39 21 00 48 8b 85 b8 04 00 00 48 39 d8 75 0e <49> 81 7c 24 28 c0 c2 47 80 48 89 d8 75 10 48 8d 7b 30 e8 ee 38 kernel: RIP [] get_utrace_lock_attached+0x34/0x57 kernel: RSP kernel: CR2: 0000000000000028 kernel: ---[ end trace 4eaa2a86a8e2da22 ]--- Regards, Wenji From roland at redhat.com Fri Aug 1 02:58:05 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 31 Jul 2008 19:58:05 -0700 (PDT) Subject: Kernel Oops: attach to init process for normal user In-Reply-To: Wenji Huang's message of Friday, 1 August 2008 10:23:21 +0800 <48927399.80304@oracle.com> References: <48927399.80304@oracle.com> Message-ID: <20080801025805.3051915427E@magilla.localdomain> Thanks for the report. This was a simple, stupid bug, affecting all the error cases from ptrace_attach (and ptrace_traceme), not just attaching to 1. New patches are up now. Thanks, Roland From roland at redhat.com Fri Aug 1 06:19:05 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 31 Jul 2008 23:19:05 -0700 (PDT) Subject: asynchronous detach, global tracing In-Reply-To: Frank Ch. Eigler's message of Thursday, 31 July 2008 12:27:51 -0400 References: <20080730103435.6F2E015427E@magilla.localdomain> Message-ID: <20080801061905.85D8D15427E@magilla.localdomain> > I don't think the module-unloading case is so special. It is, because there is nothing else you can do about that case yourself. For managing your own data structures, your callbacks can use e.g.: rcu_read_lock(); ptr = rcu_dereference(engine->data); if (!ptr) punt; ... use ptr, or do your own locking/refcount here ... rcu_read_unlock(); It's not very hard to write the callbacks and your tear-down code so that a stray callback during tear-down bails out harmlessly. In a permanently loaded module, you can do things this way and have purely nonblocking detach/tear-down of sessions. If you want to take this care in your data structure handling, then you don't have to pay any synchronization cost in the event hot paths and shouldn't be made to. Thanks, Roland From jkenisto at us.ibm.com Fri Aug 1 22:29:33 2008 From: jkenisto at us.ibm.com (Jim Keniston) Date: Fri, 01 Aug 2008 15:29:33 -0700 Subject: UTRACE_ACTION_xxx in comments Message-ID: <1217629773.4168.8.camel@dyn9047018139.beaverton.ibm.com> In utrace code fetched today, cscope reports 16 lines with references to obsolete UTRACE_ACTION_something symbols. They're all in comments or "#if 0" code, so they don't break the build, but those comments aren't very helpful in their current state. Jim From roland at redhat.com Fri Aug 1 22:59:28 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 1 Aug 2008 15:59:28 -0700 (PDT) Subject: UTRACE_ACTION_xxx in comments In-Reply-To: Jim Keniston's message of Friday, 1 August 2008 15:29:33 -0700 <1217629773.4168.8.camel@dyn9047018139.beaverton.ibm.com> References: <1217629773.4168.8.camel@dyn9047018139.beaverton.ibm.com> Message-ID: <20080801225928.62A7E154252@magilla.localdomain> > In utrace code fetched today, cscope reports 16 lines with references to > obsolete UTRACE_ACTION_something symbols. They're all in comments or > "#if 0" code, so they don't break the build, but those comments aren't > very helpful in their current state. Thanks. I found 3, and fixed those. Note the 'master' branch is now somewhat out of date. I haven't merged it up because the x86-tracehook merging situation makes it annoying. Please look at the 'utrace' branch or at the patches. Thanks, Roland From ananth at in.ibm.com Sat Aug 2 08:40:43 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Sat, 2 Aug 2008 14:10:43 +0530 Subject: asynchronous detach In-Reply-To: <20080731223802.358FE15427E@magilla.localdomain> References: <4890DAF0.20105@redhat.com> <20080731031857.GD6154@in.ibm.com> <20080731223802.358FE15427E@magilla.localdomain> Message-ID: <20080802084043.GA3375@in.ibm.com> On Thu, Jul 31, 2008 at 03:38:02PM -0700, Roland McGrath wrote: ... > > I think this can be a good model to use for non-perturbing quiesce for > > cases as breakpoint insertion and removal or any applicaton text > > modification, where one needs to ensure no thread is executing in the > > vicinity of the said modification. So, even on an -EINPROGRESS on a > > utrace_control, if the thread is in kernel, manipulating application > > text is still safe, right? > > For this particular case, maybe "safe enough". I wouldn't like to > encourage thinking of it as safe in general. Whatever the kernel is > doing might be touching user memory, or unmapping it or whatever. For > breakpoint insertion/removal, you are pretty much assuming nothing else > would ever touch the text anyway. You still need an interlock against > munmap text + mmap reusing addrs in quick succession. I suppose you > could hold mmap_sem or something. > > > Not sure if a similar model can be used to address the teardown races > > problem. > > Hmm. I mentioned before having a non-synchronizing record of the > callback in progress. This lets UTRACE_DETACH return -EINPROGRESS, > which is after the horse has left the barn, as it were. There is a > related extension of this idea I had vaguely in mind but didn't mention. > A utrace_set_events call that disables event bits could also return > -EINPROGRESS when some callback might be in progress. As with detach, > that means a zero return tells you all is well. Unlike detach, if you > get -EINPROGRESS from utrace_set_events, you still have the engine. So, the intention is that -EINPROGRESS can be returned only on a utrace_set_events(task, engine, 0), right? Actually, I think it would also be useful to just have a utrace_clear_events_sync() that encapsulates the above call. I can see use for it outside of an asynchronous detach, for cases when one needs to just turn tracing events off on a thread. (It is definitely not recommended for debugger/probes usage with breakpoints already set in user code, but would be useful for someone doing non-invasive syscall and process lifetime tracing). > If your callback never blocks, that is enough to know that it's safe to > free your data, unload your module, etc. (Or if your callback can block > but what you want to synchronize with is just what it does before it > blocks. That's when you don't care about being able to unload the > module, just juggling your own data structures.) > > For the general case of some unknown callback code that might include > blocking, you could instead do: > > ret = utrace_set_events(task, engine, 0); > while (ret == -EINPROGRESS) { > ret = utrace_prepare_examine(task, engine, &exam); > if (ret == -EAGAIN) > yield(); > ret = utrace_set_events(task, engine, 0); > if (ret == -EINPROGRESS) > yield(); > } > > That is: when it is blocked, check again if a callback still might be in > progress, and loop. Assuming your callback is well-behaved and only > ever blocks for a short time (like kmalloc), this will return soon. This can cetainly work! > yield(); should actually be schedule_timeout_interruptible(1); probably, > and it should be able to return -ERESTARTSYS. > > If this is a good plan, then we should encapsulate it in a new call > utrace_set_events_sync() or something like that. So then the safe > detach procedure would be just: > > ret = utrace_set_events_sync(task, engine, UTRACE_EVENT(REAP)); > if (!ret) > ret = utrace_control(task, engine, UTRACE_DETACH); > > This can only return zero or -ESRCH. Zero says that all callbacks are > definitely finished. -ESRCH says that your report_reap callback is > definitely happening (right now, modulo preemption). > > We could encapsulate that into utrace_detach_sync() too. Yes, this does take care of the thread about to die case too. Ananth From roland at redhat.com Sat Aug 2 21:40:11 2008 From: roland at redhat.com (Roland McGrath) Date: Sat, 2 Aug 2008 14:40:11 -0700 (PDT) Subject: asynchronous detach In-Reply-To: Ananth N Mavinakayanahalli's message of Saturday, 2 August 2008 14:10:43 +0530 <20080802084043.GA3375@in.ibm.com> References: <4890DAF0.20105@redhat.com> <20080731031857.GD6154@in.ibm.com> <20080731223802.358FE15427E@magilla.localdomain> <20080802084043.GA3375@in.ibm.com> Message-ID: <20080802214011.EC7BF154270@magilla.localdomain> > So, the intention is that -EINPROGRESS can be returned only on a > utrace_set_events(task, engine, 0), right? No, for any call when some bits had been enabled before and there hasn't been an intervening safe point. My idea was that it would return 0 only when it's sure that no disabled callback might be made. You'd get -EINPROGRESS any time we aren't 100% positive of that guarantee. > Actually, I think it would also be useful to just have a > utrace_clear_events_sync() that encapsulates the above call. I can see > use for it outside of an asynchronous detach, for cases when one needs > to just turn tracing events off on a thread. (It is definitely not > recommended for debugger/probes usage with breakpoints already set in > user code, but would be useful for someone doing non-invasive syscall > and process lifetime tracing). I mentioned utrace_set_events_sync. > Yes, this does take care of the thread about to die case too. I've written code to implement most of this. In working through it, I came across a couple of other wrinkles I hadn't thought about before. These come up in thinking about the possible interactions with callbacks that return UTRACE_DETACH. Firstly, you can't call *_sync freely if any of your callbacks ever use UTRACE_DETACH. When any callback returns UTRACE_DETACH, immediately the engine pointer is only kept alive by RCU. You can't make a blocking call with rcu_read_lock() held, so you can't be keeping it alive via RCU when you all *_sync. You can still use it, just not "freely". What that means is that you need some other synchronization with your callbacks. If your callback safely updates a data structure saying "already doing the detach", then you can synchronize with that update and check it before calling utrace_detach_sync. It takes a little thought to do that without deadlock, but it's doable. There are already special cases for the report_death callback using UTRACE_DETACH. We can see that a death callback might be in progress just from the task/utrace data structures, without actually looking at the engine pointer passed in. So we can relax that rule to allow using UTRACE_DETACH in report_death without making *_sync unsafe. The same sort of problems makes me unsure we can use interruptible blocks. I'll think about this some more. Thanks, Roland From roland at redhat.com Mon Aug 4 02:50:31 2008 From: roland at redhat.com (Roland McGrath) Date: Sun, 3 Aug 2008 19:50:31 -0700 (PDT) Subject: global tracing Message-ID: <20080804025031.908F6154217@magilla.localdomain> We've mentioned global tracing. I think it's time now to discuss it thoroughly and decide what we do or don't want to do. 1. So, what is global tracing? It's an interface to trace the events that a utrace engine can trace, but generically across the whole the system without attaching to specific threads. 2. Why do we want utrace global tracing? (I won't go into what the ability to trace things is good for in the abstract, I assume we're all sold on that.) This has been an item on the utrace TODO list for a long time, since before we had any other plan for system-wide hooks in the kernel. Now we have tracepoints and markers (et al). So the question here is, why do we want to do this in utrace? In each place that utrace has a tracing hook (now all in ), you could easily add a tracepoint/marker. So what does utrace global tracing offer over using tracepoints? Here are my thoughts on this. I'm not 100% sold that these justify it. There is a clear argument not to add another feature that provides a second way to do what you can already do with tracepoints. a. Event vocabulary clearly aligned with utrace events. The identifiers for and details of all the places you can get events and what information is on hand match the per-task utrace interface. This makes it very straightforward to compose higher-level interfaces that describe events uniformly, whether they are tracked via the global or per-task mechanism. This is quite a weak argument. It would never be difficult to map the two different mechanisms to a uniform higher-level event vocabulary. b. Coordinated with per-task utrace callbacks. If system-wide hooks are an independent mechanism, it won't be obvious (or necessarily stay reliable) whether the tracepoint is before or after the utrace callbacks, etc. As part of a unified interface, that will be well-specified. (If we grow some complex callback order priority feature, the global hooks might have detailed options for where to land in the ordering with various per-task callbacks.) Moreover, it's natural for a global tracing callback to get informed directly about what other utrace engines are doing. e.g., a system-wide catch-all hook for debugging stray crashes can tell if an active debugger is doing something to the particular task and get out of the way. c. Callbacks can change outcomes. In utrace, the syscall and signal callbacks can affect what the task actually does in a well-specified way. Tracepoints just report events. For syscalls, off hand I can only see wanting this for fault injection. There might be other sensible uses. For signals, this might be crucial to doing the "crash-catcher of last resort" sort of thing (at least, to do it more efficiently than giving every task in the system a utrace engine just for that). What I'd expect this to do is catch SIGNAL_CORE with a global tracing callback that attaches a new per-task engine, ignores and pushes back the signal (like crash-suspend does), and the new engine UTRACE_STOPs until some user-level crash handling stuff wakes up and takes over. d. Kernel already has checks here, so "almost free". The utrace event hooks are at places where the kernel has had old ptrace checks forever. The old code has fast paths that do: if (current->ptrace & mask) slow path; Now in those same places there is: if (current->utrace_flags & mask) slow path; So the cost of the checks is identical to what's already there. This is the main thing I've expected to soothe the upstream performance nit-pickers about utrace: zero new overhead if you ain't usin' it. For global tracing, those checks would be: if ((current->utrace_flags | utrace_global_flags) & mask) slow path; The cost is now two or three instructions with one load. It would increase to four or five instructions with two loads. By and large, these checks are already in places that take a lot of locks and so forth, so this addition seems pretty tiny. It's certainly no worse than adding a marker (in the current markers implementation), and probably usually far better, since it combines with the existing utrace check. 3. What would it look like? Global tracing would use the same struct utrace_engine_ops, sharing all the same signatures for the callbacks. There would be a call to register a global tracing engine, which would give you an engine represented by the same struct utrace_attached_engine type (so this pointer is passed to your callbacks). All the calls to administer global tracing engines would be separate from the existing per-task utrace calls, though we overload the same types and use the same callbacks. Perhaps only register/unregister calls, though maybe also a set_events to change your event mask after the fact. I'm leaving aside the asynchronous detach details for now. Callbacks would be the same, except that the utrace_resume_action bits in the return value are ignored completely. The action argument to callbacks tells you what any attached per-task engines are doing. For the callbacks with other return value bits (signal and syscall), those other bits do affect the task. Global engines' callbacks all run after all per-task engine callbacks. (This could change in future.) A global engine cannot use UTRACE_EVENT(QUIESCE), and never gets any report_quiesce callbacks. The QUIESCE event is not a natural event in the traced thread's life. All it would be is an indicator that some other utrace engine was causing this thread to take a slow path. I had originally planned to rule out SYSCALL events for global tracing. The reason is that this is not like other event checks where a simple flag gets checked cheaply. Instead, it requires setting the low-level TIF_SYSCALL_TRACE on a thread, which makes it take a far slower path on system call entry and exit, and has a big impact on performance just from that alone. Global tracing has to set this individually on every thread, and then pay that big overhead across the board. But, there appears to be strong interest in having global syscall tracing, and knowingly paying that overhead when you turn it on. It is easy enough to support that. (This is something else that is naturally integrated into the utrace implementation very easily, but tracepoints alone can't do without some more special hackery.) I'd kind of prefer to exclude REAP events for global tracing. For implementation reasons, it's really not any better than just having a separate tracepoint/marker on release_task. But it wouldn't cost hardly any more to roll it in, so I could be talked into it just for uniformity. 4. So, what's the plan? I need folks who might use global tracing to answer these questions: a. Do we want it? b. Do we want it right now? c. What justifies doing it in utrace (vs leaving it purely to tracepoints et al), to placate upstream critics? Please don't say, "That would be nice; your reasons sound good." That just does not help at all. The reasons in #2 above are ones I can think of, but I'm not arguing for them or for the feature. If you want the feature, *you* will be justifying it to the upstream critics. Let's here be as skeptical about adding the new complexity, before we decide on doing it, as our unsympathetic reviewers will be. Thanks, Roland From roland at redhat.com Mon Aug 4 19:20:56 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 4 Aug 2008 12:20:56 -0700 (PDT) Subject: RCU, reference counts Message-ID: <20080804192056.E2C0B154252@magilla.localdomain> Something that's always been an issue in the utrace interface is the management of struct utrace_attached_engine. It's tricky that you have to use RCU and/or follow picayune rules in the attach+set_events->callbacks sequence to be sure your engine pointer is valid. From the beginning, I expected to revisit this aspect of the interface and think it through again at some point. But I hadn't really thought about it in a long time now. The discussion here on the asynchronous detach problem has helped me think through the details that impinge on the concerns that had led me to write it this way originally. I'm grateful to David and Ananth for the detailed exchange that helps air these things out. Please keep it up! We've been talking about all these corner cases with races, where I list all the caveats for interactions with detach. What these all come down to is that your engine pointer might have been freed. RCU can protect against that, but it gets sticky if you want to block. The common mechanism for dealing with this kind of issue in interfaces is reference counted objects. In the original implementation, I was resistant to using reference counts on engines for a few reasons. One reason was the idea that the interface could make it hard to leak. I do still think it's good that e.g. the interface not encourage you to hold task refs (i.e. you don't need them because you'll get a final report_reap callback before the struct goes away). But for the engine structs, the option opposite leaks is to make the failure mode likely in sloppy modules that they use a dangling engine pointer. That is most likely more dangerous than leaks, and especially likely to do something bad to someone else's engine (since the pointer will be reused). So that objection to reference counts just doesn't hold any water. Other concerns had to do with having lockless reporting loops, and originally that seemed to require RCU for the structs anyway. But that part of the implementation has been straightened out since. How we manage the lockless list now is completely independent of RCU lists. I've also objected to reference counts being touched for reporting, and I still do. But they don't have to be. The callback synchronization thing is simpler when we have an engine pointer that can be relied on, even when you block. I'm guessing everyone will be happy to see reference counts replace RCU in the interface for dealing with struct utrace_attached_engine. So here is what I'm thinking: utrace_attach returns a ref for the caller. You can use utrace_engine_get(engine) and utrace_engine_put(engine) to manage the pointer. When you drop the last ref, the struct is freed. There are no release/destructor callbacks for that, the refcount is purely for the purpose of keeping the pointer valid. An implicit ref is held while the engine is attached. The engine pointer can always be used during a callback because of this ref. Your callback can add a new ref even if you had dropped all other refs. If a callback returns UTRACE_DETACH, then this ref will be dropped (and might be the last). Since it's easy to keep the engine pointer on hand, we really only need one synchronizing call. So now there will be no *_sync calls after all. utrace_set_events and utrace_control(,UTRACE_DETACH) can return -EINPROGRESS as I described before. This means the change of event mask, or the detach, will take effect--but there might be a callback already in progress or unavoidably on its way. To block until that callback is done, you can call utrace_barrier. So now the safe detach procedure would be: ret = utrace_control(task, engine, UTRACE_DETACH); if (ret == -EINPROGRESS) ret = utrace_barrier(task, engine); if (ret == -ERESTARTSYS) /* interrupted wait, maybe callback pending */ return ret; utrace_engine_put(engine); I haven't really tested the new code at all. But this took not much work at all to change in the implementation. If this is the right direction, I'll give the code a modicum of testing and update the documentation bits after another once-over on Monday. Thanks, Roland From dsmith at redhat.com Mon Aug 4 21:49:21 2008 From: dsmith at redhat.com (David Smith) Date: Mon, 04 Aug 2008 16:49:21 -0500 Subject: global tracing In-Reply-To: <20080804025031.908F6154217@magilla.localdomain> References: <20080804025031.908F6154217@magilla.localdomain> Message-ID: <48977961.1040800@redhat.com> Roland McGrath wrote: > We've mentioned global tracing. I think it's time now to discuss it > thoroughly and decide what we do or don't want to do. ... > 2. Why do we want utrace global tracing? >From a systemtap point of view, we'd certainly use global tracing. ... > 3. What would it look like? > > Global engines' callbacks all run after all per-task engine callbacks. > (This could change in future.) I guess in a "perfect" world callbacks would still be called in the order they were attached. But, if calling the global callbacks last makes things easier, I think systemtap could handle it. > I had originally planned to rule out SYSCALL events for global tracing. > The reason is that this is not like other event checks where a simple > flag gets checked cheaply. Instead, it requires setting the low-level > TIF_SYSCALL_TRACE on a thread, which makes it take a far slower path on > system call entry and exit, and has a big impact on performance just > from that alone. Global tracing has to set this individually on every > thread, and then pay that big overhead across the board. If we had utrace memory map tracing (I believe it is on your TODO list), systemtap wouldn't use global (or even per-thread) SYSCALL events as much. ... > I'd kind of prefer to exclude REAP events for global tracing. Currently systemtap only uses DEATH events, so I don't have much of an opinion there. ... > 4. So, what's the plan? > > I need folks who might use global tracing to answer these questions: > > a. Do we want it? Yes. Systemtap currently does "global" tracing now, in a manner similar to crash-suspend.c. The code looks for global CLONE, EXEC, and DEATH events, so systemtap knows when threads come and go. Once systemtap finds a process the user has told us he's interested in, it attaches some additional per-thread engine(s). In the future, Frank has mentioned trying to do global memory map tracing, which would require global syscall tracing (or future global memory map tracing). > b. Do we want it right now? Yes. If you need beta testers, let me know. > c. What justifies doing it in utrace (vs leaving it purely to > tracepoints et al), to placate upstream critics? > > Please don't say, "That would be nice; your reasons sound good." > That just does not help at all. The reasons in #2 above are ones I can > think of, but I'm not arguing for them or for the feature. If you want > the feature, *you* will be justifying it to the upstream critics. Let's > here be as skeptical about adding the new complexity, before we decide on > doing it, as our unsympathetic reviewers will be. Global tracing would be *really* nice; your reasons sound *great*. How's that? :-) Seriously, your reasons a. ("Event vocabulary clearly aligned with utrace events"), b. ("Coordinated with per-task utrace callbacks"), and d. ("Kernel already has checks here, so "almost free") apply most clearly to systemtap. Systemtap doesn't currently change outcomes in a callback, so reason c. doesn't apply much. Systemtap is interested in performance impacts and the a./b. advantages seem quite obvious to me. Avoiding the complexities of manually attaching/detaching to every thread in the system seems important also. -- 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 Tue Aug 5 00:10:57 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 4 Aug 2008 17:10:57 -0700 (PDT) Subject: global tracing In-Reply-To: David Smith's message of Monday, 4 August 2008 16:49:21 -0500 <48977961.1040800@redhat.com> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> Message-ID: <20080805001057.97F21154252@magilla.localdomain> > > 2. Why do we want utrace global tracing? > > From a systemtap point of view, we'd certainly use global tracing. You're using tracepoints/markers too. (You'll use anything, you minx.) What we need is reasons for this to be a utrace feature. > Global tracing would be *really* nice; your reasons sound *great*. > How's that? :-) Cursing me with loud praise! > Seriously, your reasons a. ("Event vocabulary clearly aligned with > utrace events"), b. ("Coordinated with per-task utrace callbacks"), and > d. ("Kernel already has checks here, so "almost free") apply most > clearly to systemtap. Systemtap doesn't currently change outcomes in a > callback, so reason c. doesn't apply much. Systemtap is interested in > performance impacts and the a./b. advantages seem quite obvious to me. Ok. Since a. is basically aesthetic, I think what would be concrete here is to see how you'd use it in practice such that b. matters to you. > Avoiding the complexities of manually attaching/detaching to every > thread in the system seems important also. That's a reason to have some kind of global tracing as opposed to none. Sold. It's not a reason to have utrace global tracing instead of only tracepoints and markers. Thanks, Roland From ananth at in.ibm.com Tue Aug 5 05:57:59 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Tue, 5 Aug 2008 11:27:59 +0530 Subject: global tracing In-Reply-To: <48977961.1040800@redhat.com> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> Message-ID: <20080805055759.GB13278@in.ibm.com> On Mon, Aug 04, 2008 at 04:49:21PM -0500, David Smith wrote: > Roland McGrath wrote: ... Roland, David, > > 4. So, what's the plan? > > > > I need folks who might use global tracing to answer these questions: > > > > a. Do we want it? > > Yes. Systemtap currently does "global" tracing now, in a manner similar > to crash-suspend.c. The code looks for global CLONE, EXEC, and DEATH > events, so systemtap knows when threads come and go. Once systemtap > finds a process the user has told us he's interested in, it attaches > some additional per-thread engine(s). > > In the future, Frank has mentioned trying to do global memory map > tracing, which would require global syscall tracing (or future global > memory map tracing). Answer to (a) is surely yes, but... > > b. Do we want it right now? > > Yes. If you need beta testers, let me know. ... wouldn't it be better to first push the base utrace upstream and add this as a feature thereafter? Ananth From ptesarik at suse.cz Tue Aug 5 11:15:26 2008 From: ptesarik at suse.cz (Petr Tesarik) Date: Tue, 05 Aug 2008 13:15:26 +0200 Subject: Review of utrace document In-Reply-To: <20080726001131.F03BA154240@magilla.localdomain> References: <48899D58.4040703@oracle.com> <20080726001131.F03BA154240@magilla.localdomain> Message-ID: <1217934926.10915.28.camel@elijah.suse.cz> On Fri, 2008-07-25 at 17:11 -0700, Roland McGrath wrote: > [...] > > The second important property is that tracing "be" as noninvasive as > > possible to the normal operation of the system overall and of the traced > > thread in particular. > > **verb** > > I don't see problems with these. Correct, but subjunctive is unknown to many non-native speakers. Use simpler language? > [...] > > > tracehook_tracer_task ? > > Returns NULL if "noone" is tracing task, or the struct task_struct > > pointer to its tracer. > > **typo** > > I don't see a problem with this. Wenji is right. It's "anyone", "someone", but "no one" (with a space). Regards, Petr Tesarik From ananth at in.ibm.com Tue Aug 5 12:39:03 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Tue, 5 Aug 2008 18:09:03 +0530 Subject: RCU, reference counts In-Reply-To: <20080804192056.E2C0B154252@magilla.localdomain> References: <20080804192056.E2C0B154252@magilla.localdomain> Message-ID: <20080805123903.GC13278@in.ibm.com> On Mon, Aug 04, 2008 at 12:20:56PM -0700, Roland McGrath wrote: ... > The callback synchronization thing is simpler when we have an engine > pointer that can be relied on, even when you block. I'm guessing > everyone will be happy to see reference counts replace RCU in the > interface for dealing with struct utrace_attached_engine. Yes! > So here is what I'm thinking: > > utrace_attach returns a ref for the caller. You can use > utrace_engine_get(engine) and utrace_engine_put(engine) to manage the > pointer. When you drop the last ref, the struct is freed. There are no > release/destructor callbacks for that, the refcount is purely for the > purpose of keeping the pointer valid. What is the use case for a utrace client to do a utrace_engine_get/put()? Wouldn't it be more robust if utrace implicitly handles refcounts as you've detailed below? > An implicit ref is held while the engine is attached. The engine > pointer can always be used during a callback because of this ref. Your > callback can add a new ref even if you had dropped all other refs. If a > callback returns UTRACE_DETACH, then this ref will be dropped (and might > be the last). Will this also take care of the utrace engine vs. task_struct lifetime issues that Alexey reported in http://www.redhat.com/archives/utrace-devel/2007-August/msg00002.html and http://www.redhat.com/archives/utrace-devel/2008-January/msg00019.html ? Ananth From srikar at linux.vnet.ibm.com Tue Aug 5 12:41:24 2008 From: srikar at linux.vnet.ibm.com (Srikar Dronamraju) Date: Tue, 5 Aug 2008 18:11:24 +0530 Subject: Git log Message-ID: <20080805124124.GB17378@linux.vnet.ibm.com> Hi Roland, git log is suppose to show reverse chronological listing of changes. However "git log" on utrace git is not showing reverse chronological listing of changes. Do you suggest way other than "git log" to know the last few commits that went into utrace. -- Thanks and Regards Srikar From arborist at bonsai-dnes.cz Tue Aug 5 16:44:21 2008 From: arborist at bonsai-dnes.cz (Dunsmoor Lady) Date: Tue, 05 Aug 2008 16:44:21 +0000 Subject: :o) Message-ID: <1273231253.20080805163200@bonsai-dnes.cz> What's up? -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Tue Aug 5 20:46:39 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 5 Aug 2008 13:46:39 -0700 (PDT) Subject: global tracing In-Reply-To: Ananth N Mavinakayanahalli's message of Tuesday, 5 August 2008 11:27:59 +0530 <20080805055759.GB13278@in.ibm.com> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> <20080805055759.GB13278@in.ibm.com> Message-ID: <20080805204640.03AB0154217@magilla.localdomain> > Answer to (a) is surely yes, but... Since you're sure, what would you say to convince a skeptic? > ... wouldn't it be better to first push the base utrace upstream and add > this as a feature thereafter? I think this is probably how it will go anyway. I want to get a plan on the table now. The consensus here about the details will inform my ideas for implementing it. I want to think it through enough to see how the innards would be and figure out if it will entail significant rearrangement of the utrace implementation. Thanks, Roland From fche at redhat.com Tue Aug 5 21:32:54 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 05 Aug 2008 17:32:54 -0400 Subject: global tracing In-Reply-To: <48977961.1040800@redhat.com> (David Smith's message of "Mon, 04 Aug 2008 16:49:21 -0500") References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> Message-ID: David Smith writes: > [...] >> 2. Why do we want utrace global tracing? >> From a systemtap point of view, we'd certainly use global tracing. I have a somewhat different take on this. This kind of interface would be nice to have in utrace only if it were significantly cheaper than doing what we do now: potentially attaching utrace-engines to each thread -- or (in the near future, systemtap bug# 6445) to subtrees of the process hierarchy. (An extra chunk of work per clone() may well be cheaper than extra work at every system call.) > Systemtap doesn't currently change outcomes in a callback, so reason > c. doesn't apply much. [...] Actually, this is the main reasons that utrace-level support sounds interesting to me. We have had requests for exposing some thread control primitives to systemtap probe handlers - to block/resume, send signals, that sort of stuff. *If* going through utrace (as opposed to a separate API) would make this smoother and compose better (should e.g. there be different systemtap scripts fighting over the threads), that could be worthwhile. - FChE From roland at redhat.com Tue Aug 5 22:32:42 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 5 Aug 2008 15:32:42 -0700 (PDT) Subject: global tracing In-Reply-To: Frank Ch. Eigler's message of Tuesday, 5 August 2008 17:32:54 -0400 References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> Message-ID: <20080805223242.C415C154217@magilla.localdomain> > This kind of interface would be nice to have in utrace only if it were > significantly cheaper than doing what we do now: potentially attaching > utrace-engines to each thread -- or (in the near future, systemtap > bug# 6445) to subtrees of the process hierarchy. The overhead (memory + setup/teardown cost) is per-thread X per-tracer. We'd have to measure what it is in practice. I'd guess the memory won't be an issue unless you were really milking the system for performance. I'd guess the first issue will be big chunks of slow at script setup/teardown when there are lots of threads on the system. The main feature of global tracing is that it avoids this overhead. It goes without saying that you could always just trace every thread individually and produce the same result at high level. The other feature is its simplicity. The "baseline" work to do global tracing via by-thread is not entirely trivial, as David will attest. For subtrees, there wouldn't any time soon be an option other that global or by-each-thread. In the long run, there might be some new optimizations for using utrace to treat many threads all the same. Whatever comes along to benefit that case, I don't think it will constitute an argument either for or against global tracing. > (An extra chunk of work per clone() may well be cheaper than extra work > at every system call.) I assume what you mean here is for global syscall tracing. There is no such trade-off. With vanilla utrace, you always do both. With global tracing, you still always do the latter. > > Systemtap doesn't currently change outcomes in a callback, so reason > > c. doesn't apply much. [...] > > Actually, this is the main reasons that utrace-level support sounds > interesting to me. We have had requests for exposing some thread > control primitives to systemtap probe handlers - to block/resume, send > signals, that sort of stuff. *If* going through utrace (as opposed to > a separate API) would make this smoother and compose better (should > e.g. there be different systemtap scripts fighting over the threads), > that could be worthwhile. We'd have to discuss concrete scenarios to get entirely clear on this. But off hand those sound like things that make sense to do with vanilla utrace on individual threads. i.e. blocking a thread implies that you maintain per-thread state, as opposed to just a per-event consideration of the thread on hand. (Also, for blocking specifically, utrace is the only kosher way to go about it--anything else fails badly at playing nicely with other tracing and debugging facilities.) So to me this says you just need whatever global tracing facility you're using to have a good place to make utrace setup calls when you discover you want to do this sort of thing. That's a feature that utrace global tracing clearly has. But given a particular scenario and a given other means of getting its necessary event hooks, that other means might well be fine in this regard too. To know, we'd have to get concrete about each of the specific tracepoints you would use instead. Thanks, Roland From fche at redhat.com Tue Aug 5 23:39:12 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 5 Aug 2008 19:39:12 -0400 Subject: global tracing In-Reply-To: <20080805223242.C415C154217@magilla.localdomain> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> <20080805223242.C415C154217@magilla.localdomain> Message-ID: <20080805233912.GC14574@redhat.com> Hi - On Tue, Aug 05, 2008 at 03:32:42PM -0700, Roland McGrath wrote: > > This kind of interface would be nice to have in utrace only if it were > > significantly cheaper than doing what we do now: potentially attaching > > utrace-engines to each thread -- or (in the near future, systemtap > > bug# 6445) to subtrees of the process hierarchy. > > The overhead (memory + setup/teardown cost) is per-thread X per-tracer. > We'd have to measure what it is in practice. [...] Right. > The other feature is its simplicity. The "baseline" work to do global > tracing via by-thread is not entirely trivial, as David will attest. Right, though once it's done, it's done ... > For subtrees, there wouldn't any time soon be an option other that > global or by-each-thread. [...] ... and is necessary for this part anyway. > > (An extra chunk of work per clone() may well be cheaper than extra work > > at every system call.) > > I assume what you mean here is for global syscall tracing. There is no > such trade-off. With vanilla utrace, you always do both. With global > tracing, you still always do the latter. The alternative I considered is the nonexistence of global tracing support, thus no utrace_global_flags test in the syscall fast path. > > > Systemtap doesn't currently change outcomes in a callback, so reason > > > c. doesn't apply much. [...] > > > > Actually, this is the main reasons that utrace-level support sounds > > interesting to me. We have had requests for exposing some thread > > control primitives to systemtap probe handlers - to block/resume, send > > signals, that sort of stuff. [...] > We'd have to discuss concrete scenarios to get entirely clear on this. > [...] Well, it would be desirable to have some facility to block/resume and send signals to threads. It would be desirable for this not to be available only for utrace-probes and not only targeting the currently utrace-hooked thread, but enqueue the command to an arbitrary one. - FChE From roland at redhat.com Wed Aug 6 00:26:21 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 5 Aug 2008 17:26:21 -0700 (PDT) Subject: global tracing In-Reply-To: Frank Ch. Eigler's message of Tuesday, 5 August 2008 19:39:12 -0400 <20080805233912.GC14574@redhat.com> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> <20080805223242.C415C154217@magilla.localdomain> <20080805233912.GC14574@redhat.com> Message-ID: <20080806002621.8A96B154217@magilla.localdomain> > The alternative I considered is the nonexistence of global tracing > support, thus no utrace_global_flags test in the syscall fast path. It will never be in the fast path. It will always require TIF_SYSCALL_TRACE to bet set on each thread, which means the slow path. In comparison, one or two more or fewer loads is negligible. > Well, it would be desirable to have some facility to block/resume and > send signals to threads. It would be desirable for this not to be > available only for utrace-probes and not only targeting the currently > utrace-hooked thread, but enqueue the command to an arbitrary one. "Sending signals" if you just mean in the generic sense is already available independent of anything else (send_sig et al). That is just like a tkill syscall, but done in a kernel module. If that's all you mean, then it's just a one-off injection (queuing) call and doesn't need to tie into anything else at all. When you make "enqueue the command" concrete, what it means is to attach a utrace engine to do the control of the thread you want. It's your business when and where you decide to do this, but that's what you'll be doing. Thanks, Roland From roland at redhat.com Wed Aug 6 00:49:28 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 5 Aug 2008 17:49:28 -0700 (PDT) Subject: Git log In-Reply-To: Srikar Dronamraju's message of Tuesday, 5 August 2008 18:11:24 +0530 <20080805124124.GB17378@linux.vnet.ibm.com> References: <20080805124124.GB17378@linux.vnet.ibm.com> Message-ID: <20080806004928.A35EC154217@magilla.localdomain> Sorry, there is no (recent) GIT history. I announced here when I started the "new" GIT repo that I would be using git-rebase. I'm still doing that. This is what made most sense while doing constant rebasing of several patch series preparing them for upstream submission. Now that tracehook et al are all merged in upstream, it would not be such a hassle to maintain the single utrace branch with fine-grained GIT history again. What we have right now is just using GIT to hold the queue of "whole" patches as they would be merged upstream. Before the code is merged, the upstream folks won't want to see any intermediate history. They just want to review the final "(almost) ready for prime time" versions. I think that quite soon we will converge on the remaining API details (see ref count thread) and have it ready to submit. When it's merged in an upstream GIT branch, then follow-on changes will be individual GIT commits in branch that gets merged back in upstream, as other subsystems use. Thanks, Roland From roland at redhat.com Wed Aug 6 02:20:42 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 5 Aug 2008 19:20:42 -0700 (PDT) Subject: RCU, reference counts In-Reply-To: Ananth N Mavinakayanahalli's message of Tuesday, 5 August 2008 18:09:03 +0530 <20080805123903.GC13278@in.ibm.com> References: <20080804192056.E2C0B154252@magilla.localdomain> <20080805123903.GC13278@in.ibm.com> Message-ID: <20080806022042.29B78154217@magilla.localdomain> > Yes! [...] > What is the use case for a utrace client to do a utrace_engine_get/put()? > Wouldn't it be more robust if utrace implicitly handles refcounts as > you've detailed below? If the only operations that affect this "count" are implicit, then I assume you must mean those are attach and detach. What today's utrace has now is an "implicit count": it's 1 when attached, and 0 when not. It's perfectly robust as described. Since it's implicit, you have to observe all those squirrelly rules about synchronizing with UTRACE_DETACH that I've been talking about. If there is no utrace_engine_put, then what difference are you saying an enthusiastic "Yes!" to? Explain what you have in mind that would be somehow different from what we already had, but have no utrace_engine_put. > Will this also take care of the utrace engine vs. task_struct lifetime > issues that Alexey reported in [...] ? The messages you cited are not apropos at all. Those were about (old) bugs in the utrace implementation, pure and simple. We're talking here about what the specified API is, with the intent of providing one that helps callers of utrace avoid writing bugs in their own code. Whatever the specified API is, of course we're only talking about what it means to use a utrace implementation that works correctly as specified. For a moment I thought you were referring to the actual subject about task_struct lifetime that we need to address here. This is a problem I had more or less factored into the original interface with its RCU requirements. But I'd forgotten about it in doing the engine ref counts. The issue is keeping your task_struct pointers valid. The kernel (for quite a while now) doesn't let modules use put_task_struct, or tasklist_lock (they are not exported). So the only way your code in a module can keep a task_struct alive (except current, of course) is with rcu_read_lock. The RCU requirements for keeping engine pointers alive in the utrace interface were the same RCU things you'd have to do to keep task_struct pointers alive, so passing both pointers to each call just needed the same rcu_read_lock treatment. The risk is holding a dangling task_struct pointer in your kernel module's code when the task dies and gets reaped. AFAICT the answer on this in general upstream now is to use struct pid. It is a separately reference-counted object, and put_pid can be used from kernel modules (whereas put_task_struct can't be). It doesn't keep a task_struct pointer alive, but provides a safe handle on one that you can keep a ref to in a module. To actually do something with that task_struct, you still have to use RCU locally: rcu_read_lock(); t = pid_task(pid, PIDTYPE_PID); if (t) ... use t->fields ... rcu_read_unlock(); but at least you can keep the struct pid * as long as you like with safe reference counting you're allowed to use in a module. Using struct pid * in your own data structures also has some arcane effects. In particular, in a multithreaded exec, the old struct pid for the initial thread will have its task_struct pointer replaced with the pointer for the thread that did the exec (while the old initial thread that previously had that pid is reaped). But this seems to be the plan in the upstream kernel, since they don't want put_task_struct exported. So, utrace can help with this a little. Perhaps this will be enough to keep it from becoming really difficult to write correct modules. When an engine is attached, the task_struct is by definition still valid. You'll recall that all engines are detached from a task when it's reaped (after their report_reap callback, if any), so this follows. So what I can do is this: in all the calls that take task, engine (set_events, control, barrier, and *_examine) it will always be safe to pass a stale task_struct pointer along with a valid engine pointer (i.e. you hold an engine ref). They'll just check if the engine is already detached before looking the task pointer, so you'll get an -ESRCH error. This makes it safe to use: ret = utrace_control(pid_task(pid, PIDTYPE_PID), engine, UTRACE_FOO); and the like without RCU. It's also true that utrace_set_events and utrace_control are purely nonblocking calls, so you can call them inside rcu_read_lock if you are using that to access the task_struct safely yourself anyway. utrace_attach itself can block (calling kmalloc), but I can still make it such that: rcu_read_lock(); engine = utrace_attach(pid_task(pid, PIDTYPE_PID), ...); is safe with respect to the task_struct pointer, though it could block in between, so you could not be relying on RCU otherwise there. I think the thing to do is export both utrace_attach_task (today's utrace_attach), and a utrace_attach_pid that is the same but taking a struct pid * argument instead of task_struct. The utrace_attach_task call is safe (and simplest) to use when it's current or is the new child in report_clone, or is your child you're somehow sure won't be reaped. The utrace_attach_pid call would always be safe given the caller holds a ref on the struct pid it passes. e.g.: pid = find_get_pid(nr); engine = utrace_attach_pid(pid, ...); ... put_pid(pid); You'd presumably hold the pid ref in your data structures to use e.g. in the utrace_control example above. The put_pid call goes in your cleanup code. Thanks, Roland From ananth at in.ibm.com Wed Aug 6 05:22:02 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Wed, 6 Aug 2008 10:52:02 +0530 Subject: RCU, reference counts In-Reply-To: <20080806022042.29B78154217@magilla.localdomain> References: <20080804192056.E2C0B154252@magilla.localdomain> <20080805123903.GC13278@in.ibm.com> <20080806022042.29B78154217@magilla.localdomain> Message-ID: <20080806052202.GJ13278@in.ibm.com> On Tue, Aug 05, 2008 at 07:20:42PM -0700, Roland McGrath wrote: > > Yes! > [...] > > What is the use case for a utrace client to do a utrace_engine_get/put()? > > Wouldn't it be more robust if utrace implicitly handles refcounts as > > you've detailed below? > > If the only operations that affect this "count" are implicit, then I assume > you must mean those are attach and detach. What today's utrace has now is > an "implicit count": it's 1 when attached, and 0 when not. It's perfectly > robust as described. Since it's implicit, you have to observe all those > squirrelly rules about synchronizing with UTRACE_DETACH that I've been > talking about. > > If there is no utrace_engine_put, then what difference are you saying an > enthusiastic "Yes!" to? Explain what you have in mind that would be > somehow different from what we already had, but have no utrace_engine_put. My initial opinion was that you were moving away from RCU to also rid the task_struct->utrace assertion failure, which IIRC from some of the investigations at the time, were mostly for RCU lifetime reasons. Ananth From ptesarik at suse.cz Wed Aug 6 13:18:49 2008 From: ptesarik at suse.cz (Petr Tesarik) Date: Wed, 06 Aug 2008 15:18:49 +0200 Subject: global tracing In-Reply-To: <20080804025031.908F6154217@magilla.localdomain> References: <20080804025031.908F6154217@magilla.localdomain> Message-ID: <1218028729.3721.17.camel@elijah.suse.cz> On Sun, 2008-08-03 at 19:50 -0700, Roland McGrath wrote: > [...] > For global tracing, those checks would be: > > if ((current->utrace_flags | utrace_global_flags) & mask) slow path; > > The cost is now two or three instructions with one load. It would > increase to four or five instructions with two loads. By and large, > these checks are already in places that take a lot of locks and so > forth, so this addition seems pretty tiny. It's certainly no worse > than adding a marker (in the current markers implementation), and > probably usually far better, since it combines with the existing > utrace check. If you really want to avoid it, there is a way: * Create another global variable utrace_possible_flags. Each bit is set only if there is either a global tracer for the event, or at least one tracer in the system (keep a global counter). * Always check utrace_possible_flags first, and if it is set (thus requesting the slow path anyway), only then check the per-thread and global flags. OK, this has its cost (maintaining the counter and one extra check in case where utrace _is_ actually used), but as long as there is no tracing happening in the system, performance does not suffer a single CPU cycle. It may even be a tiny better for architectures where accessing a global variable is cheaper than accessing current->utrace_flags... I'm not 100% sold that it's worth the complexity, but we can go that way if a nitpicker jumps up and argues. Petr Tesarik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fche at redhat.com Wed Aug 6 13:40:24 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Wed, 6 Aug 2008 09:40:24 -0400 Subject: global tracing In-Reply-To: <20080806002621.8A96B154217@magilla.localdomain> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> <20080805223242.C415C154217@magilla.localdomain> <20080805233912.GC14574@redhat.com> <20080806002621.8A96B154217@magilla.localdomain> Message-ID: <20080806134024.GA12344@redhat.com> Hi - > > The alternative I considered is the nonexistence of global tracing > > support, thus no utrace_global_flags test in the syscall fast path. > > It will never be in the fast path. It will always require > TIF_SYSCALL_TRACE to bet set on each thread, which means the slow path. > [...] OK, I must have misunderstood your original posting: # [...] # d. Kernel already has checks here, so "almost free". # # The utrace event hooks are at places where the kernel has had old # ptrace checks forever. The old code has fast paths that do: # if (current->ptrace & mask) slow path; # Now in those same places there is: # if (current->utrace_flags & mask) slow path; # So the cost of the checks is identical to what's already there. [...] # For global tracing, those checks would be: # if ((current->utrace_flags | utrace_global_flags) & mask) slow path; # [...] - FChE From roland at redhat.com Wed Aug 6 18:05:13 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 6 Aug 2008 11:05:13 -0700 (PDT) Subject: global tracing In-Reply-To: Frank Ch. Eigler's message of Wednesday, 6 August 2008 09:40:24 -0400 <20080806134024.GA12344@redhat.com> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> <20080805223242.C415C154217@magilla.localdomain> <20080805233912.GC14574@redhat.com> <20080806002621.8A96B154217@magilla.localdomain> <20080806134024.GA12344@redhat.com> Message-ID: <20080806180514.0619C15420D@magilla.localdomain> > > It will never be in the fast path. It will always require > > TIF_SYSCALL_TRACE to bet set on each thread, which means the slow path. > > [...] > > OK, I must have misunderstood your original posting: > > # [...] > # d. Kernel already has checks here, so "almost free". This refers to all the other cases, where there is just a check at the time of the event. The syscall case is special, requiring TIF_SYSCALL_TRACE. Thanks, Roland From mhiramat at redhat.com Wed Aug 6 20:11:42 2008 From: mhiramat at redhat.com (Masami Hiramatsu) Date: Wed, 06 Aug 2008 16:11:42 -0400 Subject: global tracing In-Reply-To: <20080806180514.0619C15420D@magilla.localdomain> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> <20080805223242.C415C154217@magilla.localdomain> <20080805233912.GC14574@redhat.com> <20080806002621.8A96B154217@magilla.localdomain> <20080806134024.GA12344@redhat.com> <20080806180514.0619C15420D@magilla.localdomain> Message-ID: <489A057E.5040105@redhat.com> Hi, Roland McGrath wrote: >>> It will never be in the fast path. It will always require >>> TIF_SYSCALL_TRACE to bet set on each thread, which means the slow path. >>> [...] >> OK, I must have misunderstood your original posting: >> >> # [...] >> # d. Kernel already has checks here, so "almost free". > > This refers to all the other cases, where there is just a check at the time > of the event. The syscall case is special, requiring TIF_SYSCALL_TRACE. Actually, this point is where I'm stuck on these weeks. If we add marker or tracepoint to trace every syscalls, we might have to put it in the tracehook or audit and set TIF_SYSCALL_TRACE for every process, or put tracepoint in the syscall entrance/exit asm-code and check another flag. Since latter adds additional flag-checking in fast-path, I think it is not acceptable. Thank you, > > > Thanks, > Roland > -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat at redhat.com From roland at redhat.com Wed Aug 6 21:32:43 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 6 Aug 2008 14:32:43 -0700 (PDT) Subject: global tracing In-Reply-To: Masami Hiramatsu's message of Wednesday, 6 August 2008 16:11:42 -0400 <489A057E.5040105@redhat.com> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> <20080805223242.C415C154217@magilla.localdomain> <20080805233912.GC14574@redhat.com> <20080806002621.8A96B154217@magilla.localdomain> <20080806134024.GA12344@redhat.com> <20080806180514.0619C15420D@magilla.localdomain> <489A057E.5040105@redhat.com> Message-ID: <20080806213243.1154A15420D@magilla.localdomain> > Actually, this point is where I'm stuck on these weeks. > > If we add marker or tracepoint to trace every syscalls, > we might have to put it in the tracehook or audit and set > TIF_SYSCALL_TRACE for every process, or put tracepoint > in the syscall entrance/exit asm-code and check another > flag. Since latter adds additional flag-checking in fast-path, > I think it is not acceptable. I agree completely that it would be wrong to do any new arch work for this, especially assembly hacking. Certainly piggy-backing on the existing TIF_SYSCALL_TRACE or TIF_SYSCALL_AUDIT in some fashion is the way to go. If you don't need complete user register access at your tracepoint, then the audit path is an option. I suspect you do, and so TIF_SYSCALL_TRACE is what to use. Then you can put tracepoints in tracehook_report_syscall_*. It's straightforward to write a loop to set TIF_SYSCALL_TRACE on every task. The only wrinkle is dealing with clearing the flag correctly. You don't need a loop, because it can be cleared lazily by each thread when it gets into the slow path and finds it has no reason to be there. This is not very hard. It only requires adding a few lines in the utrace code to check your global-syscall-trace flag in deciding when to clear TIF_SYSCALL_TRACE. This would be unlike a plain tracepoint only in that you have to make this explicit call to switch it on and off. (Maybe this could be rolled into the tracepoint probe registration API.) I'm not at all arguing against having utrace global tracing to provide you this feature instead. (I already raised the pros/cons about that generally and that discussion can continue.) But this is how you'd do it sensibly with tracepoints IMHO. (The details I just described are not much different from what utrace global tracing would have for handling TIF_SYSCALL_TRACE.) Thanks, Roland From roland at redhat.com Wed Aug 6 21:41:03 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 6 Aug 2008 14:41:03 -0700 (PDT) Subject: global tracing In-Reply-To: Petr Tesarik's message of Wednesday, 6 August 2008 15:18:49 +0200 <1218028729.3721.17.camel@elijah.suse.cz> References: <20080804025031.908F6154217@magilla.localdomain> <1218028729.3721.17.camel@elijah.suse.cz> Message-ID: <20080806214103.54B5115420D@magilla.localdomain> > * Create another global variable utrace_possible_flags. Each bit > is set only if there is either a global tracer for the event, > or at least one tracer in the system (keep a global counter). > * Always check utrace_possible_flags first, and if it is set > (thus requesting the slow path anyway), only then check the > per-thread and global flags. That seems like a bad trade-off. The common case to optimize is that this event now not going to be traced. If someone somewhere is running strace on their programs, my task should not go through any slow paths just because of them. That's a degradation from today's performance with plain old ptrace. The fast path having two negative tests in the common case is surely better than what should be the fast path having a slow false positive for me, because someone else somewhere ran "strace -f sleep 999999 &". If it comes down to "exactly the current check only is acceptable cost", then the opposite direction is what makes sense to me. That is, have global tracing go do: task->utrace_flags |= global_utrace_flags; on every task whenever a new bit is set in global_utrace_flags. (Then there can be some lazy fixup for stale task->utrace_flags values after global_utrace_flags has bits cleared. It's essentially the same plan as for setting TIF_SYSCALL_TRACE for global syscall tracing.) Thanks, Roland From roland at redhat.com Wed Aug 6 21:46:09 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 6 Aug 2008 14:46:09 -0700 (PDT) Subject: RCU, reference counts In-Reply-To: Ananth N Mavinakayanahalli's message of Wednesday, 6 August 2008 10:52:02 +0530 <20080806052202.GJ13278@in.ibm.com> References: <20080804192056.E2C0B154252@magilla.localdomain> <20080805123903.GC13278@in.ibm.com> <20080806022042.29B78154217@magilla.localdomain> <20080806052202.GJ13278@in.ibm.com> Message-ID: <20080806214609.CC4C315420D@magilla.localdomain> > My initial opinion was that you were moving away from RCU to also rid > the task_struct->utrace assertion failure, which IIRC from some of the > investigations at the time, were mostly for RCU lifetime reasons. That assertion failure (BUG_ON) was due to an internal bug. It was entirely for buggy internals reasons. The way I move to get rid of those is to debug them. I'm trying to have a conversation about the utrace API. I haven't really gotten any feedback the API questions. I very much need to know the opinions on this of people who write code that uses utrace. Thanks, Roland From mhiramat at redhat.com Wed Aug 6 21:56:49 2008 From: mhiramat at redhat.com (Masami Hiramatsu) Date: Wed, 06 Aug 2008 17:56:49 -0400 Subject: global tracing In-Reply-To: <20080806213243.1154A15420D@magilla.localdomain> References: <20080804025031.908F6154217@magilla.localdomain> <48977961.1040800@redhat.com> <20080805223242.C415C154217@magilla.localdomain> <20080805233912.GC14574@redhat.com> <20080806002621.8A96B154217@magilla.localdomain> <20080806134024.GA12344@redhat.com> <20080806180514.0619C15420D@magilla.localdomain> <489A057E.5040105@redhat.com> <20080806213243.1154A15420D@magilla.localdomain> Message-ID: <489A1E21.6040009@redhat.com> Hi, Roland McGrath wrote: >> Actually, this point is where I'm stuck on these weeks. >> >> If we add marker or tracepoint to trace every syscalls, >> we might have to put it in the tracehook or audit and set >> TIF_SYSCALL_TRACE for every process, or put tracepoint >> in the syscall entrance/exit asm-code and check another >> flag. Since latter adds additional flag-checking in fast-path, >> I think it is not acceptable. > > I agree completely that it would be wrong to do any new arch work for this, > especially assembly hacking. Certainly piggy-backing on the existing > TIF_SYSCALL_TRACE or TIF_SYSCALL_AUDIT in some fashion is the way to go. > > If you don't need complete user register access at your tracepoint, then > the audit path is an option. I suspect you do, and so TIF_SYSCALL_TRACE > is what to use. Then you can put tracepoints in tracehook_report_syscall_*. Actually, I did it and found it is not simple to hook audit syscall. It seems that audit flag is not synchronously cleared/set on processes with audit_context. I think tracehook is better and simpler way to do that. But there is still some audit-related problem when I set TIF_SYSCALL_TRACE flag on every process, and I'm investigating that. Maybe I need to improve syscall audit. > It's straightforward to write a loop to set TIF_SYSCALL_TRACE on every > task. The only wrinkle is dealing with clearing the flag correctly. You > don't need a loop, because it can be cleared lazily by each thread when it > gets into the slow path and finds it has no reason to be there. This is > not very hard. It only requires adding a few lines in the utrace code to > check your global-syscall-trace flag in deciding when to clear > TIF_SYSCALL_TRACE. That's a good idea. I'll check that. > This would be unlike a plain tracepoint only in that you have to make this > explicit call to switch it on and off. (Maybe this could be rolled into > the tracepoint probe registration API.) Sure, even though, we can enable it when initializing tracepoint->marker conversion module. > I'm not at all arguing against having utrace global tracing to provide you > this feature instead. (I already raised the pros/cons about that generally > and that discussion can continue.) But this is how you'd do it sensibly > with tracepoints IMHO. (The details I just described are not much different > from what utrace global tracing would have for handling TIF_SYSCALL_TRACE.) I agree that. I think if I can set TIF_SYSCALL_TRACE on each process safely, it can work with utrace global tracing too. In that case, I can move to utrace global tracing feature. Thank you, > > > Thanks, > Roland -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat at redhat.com From wenji.huang at oracle.com Thu Aug 7 09:42:12 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Thu, 07 Aug 2008 17:42:12 +0800 Subject: typo in utrace_report_jctl Message-ID: <489AC374.5080203@oracle.com> Hi, I guess this is a typo in function utrace_report_jctl utrace = rcu_dereference(task->utrace); if (unlikely(!utrace)) { - rcu_read_lock(); + rcu_read_unlock(); return; } Regards, Wenji From roland at redhat.com Thu Aug 7 11:15:54 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 7 Aug 2008 04:15:54 -0700 (PDT) Subject: typo in utrace_report_jctl In-Reply-To: Wenji Huang's message of Thursday, 7 August 2008 17:42:12 +0800 <489AC374.5080203@oracle.com> References: <489AC374.5080203@oracle.com> Message-ID: <20080807111556.3A86115423B@magilla.localdomain> Good catch! Fixed. Thanks, Roland From roland at redhat.com Thu Aug 7 11:42:41 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 7 Aug 2008 04:42:41 -0700 (PDT) Subject: utrace status Message-ID: <20080807114241.DC3B515429D@magilla.localdomain> I've finished the updates I've been talking about. Please take a fresh look at the 'make htmldocs' book. I updated crash-suspend.c for the changes. This utrace should appear in a Fedora rawhide kernel some day soon. Thanks, Roland From invitation at whereareyounow.net Fri Aug 8 01:30:32 2008 From: invitation at whereareyounow.net (Basavaraj Mathapaty) Date: Fri, 8 Aug 2008 02:30:32 +0100 Subject: Where are you Message-ID: <98476656134ca7811af54ced05a28aa3@whereareyounow.net> utrace-devel, I'd like to add you to my travel network on WAYN -Basavaraj Here is the link: http://www.wayn.com/waynfx.html?wci=link&id=3250&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1 -------------------------------------------------------------------------------- What is WAYN? WAYN (Where Are You Now?) is the global meeting place. * Meet people from different places * Share your traveling experiences * Make a difference on global issues Learn more (http://www.wayn.com/waynfx.html?wci=link&id=3251&m=13255828&c=407127741&fm_token=0BC645845FC17A916C2C44561176DD69<@@VIP_UPGRADE>&pro=1) Privacy matters to us! If you do not wish to receive further invites from your friends, click here (http://www.wayn.com/waynfx.html?wci=link&id=3252&c=407127741) -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Fri Aug 8 05:46:35 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 7 Aug 2008 22:46:35 -0700 (PDT) Subject: attach-wait-on-stopped vs detach-stopped Message-ID: <20080808054635.2951E15429D@magilla.localdomain> In the latest upstream kernels, detach-stopped is the only ptrace-tests case failing. A fix I tried for that worked, but made attach-wait-on-stopped start failing instead. Can you tell me if you think the expectation in attach-wait-on-stopped really seems correct? It seems to be contrary to what detach-stopped wants. In attach-wait-on-stopped, this happens: untraced child stops with normal SIGSTOP parent does not wait, stopped state still "to be waited for" parent does PTRACE_ATTACH -> child still in job stop, now has pending SIGSTOP parent does wait, sees it stopped with SIGSTOP (the first one) parent does PEEKUSR, GETREGS (should make no difference) parent does PTRACE_DETACH * -> child has never left job stop, is still in job stop, stays in job stop after detach, does not wake up parent does PTRACE_ATTACH -> child still in job stop, but has been waited for still pending SIGSTOP (third one came but second one still waiting) parent does wait, blocks since child is waited-for but still stopped What happened before my fix was that PTRACE_DETACH unconditionally woke the thread up from whatever state it was in. So here, it woke up, saw the old pending SIGSTOP, and stopped again (ptrace stop)--now with a fresh "still to be waited for" stopped status. But this wakeup on PTRACE_DETACH was exactly what detach-stopped does not want to see. attach-wait-on-stopped uses PTRACE_DETACH,0 while detach-stopped uses PTRACE_DETACH,SIGSTOP. So both tests can be satisfied if what it means is that PTRACE_DETACH always wakes up a thread (even one that has never left job control stop), but it should stop again for the new SIGSTOP. (The reason it doesn't stop again now is an esoteric internal one.) Is that what you think the rule ought to be? The "if in job stop, stay in job stop" rule seems more sensible to me. That would make detach-stopped pass and attach-wait-on-stopped fail. As you're aware, the subtle difference between staying stopped and waking up followed by an immediate stop is the "freshening" of the wait status and wakeup of a parent/tracer's blocked wait calls. Thanks, Roland From secured-online at update-alert.com.redhat.com Mon Aug 4 03:09:50 2008 From: secured-online at update-alert.com.redhat.com (Wells Fargo Online) Date: Mon, 04 Aug 2008 05:09:50 +0200 Subject: Wells Fargo Online Alert : Verify your account information Message-ID: An HTML attachment was scrubbed... URL: From jan.kratochvil at redhat.com Fri Aug 8 22:10:34 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Sat, 9 Aug 2008 00:10:34 +0200 Subject: attach-wait-on-stopped vs detach-stopped In-Reply-To: <20080808054635.2951E15429D@magilla.localdomain> References: <20080808054635.2951E15429D@magilla.localdomain> Message-ID: <20080808221034.GA16653@host0.dyn.jankratochvil.net> Hi Roland, thanks for your detailed explanation making the complex problem looking easy. On Fri, 08 Aug 2008 07:46:35 +0200, Roland McGrath wrote: > In the latest upstream kernels, detach-stopped is the only ptrace-tests > case failing. A fix I tried for that worked, but made attach-wait-on-stopped > start failing instead. > > Can you tell me if you think the expectation in attach-wait-on-stopped > really seems correct? It seems to be contrary to what detach-stopped wants. > > In attach-wait-on-stopped, this happens: > > untraced child stops with normal SIGSTOP > parent does not wait, stopped state still "to be waited for" > parent does PTRACE_ATTACH > -> child still in job stop, > now has pending SIGSTOP > parent does wait, sees it stopped with SIGSTOP (the first one) > parent does PEEKUSR, GETREGS (should make no difference) > parent does PTRACE_DETACH > * -> child has never left job stop, > is still in job stop, > stays in job stop after detach, does not wake up > parent does PTRACE_ATTACH > -> child still in job stop, but has been waited for > still pending SIGSTOP (third one came but second one still waiting) > parent does wait, blocks since child is waited-for but still stopped > > What happened before my fix was that PTRACE_DETACH unconditionally woke the > thread up from whatever state it was in. So here, Just to comment your *here* means the *-marked line. > it woke up, saw the old pending SIGSTOP, and stopped again (ptrace > stop)--now with a fresh "still to be waited for" stopped status. My explanation: This SIGSTOP you describe was generated by PTRACE_ATTACH. As we are now after PTRACE_DETACH (with no TracerPid) when this SIGSTOP is delivered we get into `T (stopped)' (and not `T (tracing stop') state. > But this wakeup on PTRACE_DETACH was exactly what detach-stopped does not > want to see. > > attach-wait-on-stopped uses PTRACE_DETACH,0 while detach-stopped uses > PTRACE_DETACH,SIGSTOP. With the `attach-wait-on-stopped uses PTRACE_DETACH,0' testcase part I just tried to pinpoint the utrace<->ptrace difference being considered a regression. Upstream GDB did not support attaching-to-stopped processes before and it still has the detach-as-stopped behavior currently undefined. => I am not aware it would cause any real-world problems to FAIL the second-attach case of attach-wait-on-stopped. > So both tests can be satisfied if what it means > is that PTRACE_DETACH always wakes up a thread (even one that has never > left job control stop), but it should stop again for the new SIGSTOP. > (The reason it doesn't stop again now is an esoteric internal one.) > > Is that what you think the rule ought to be? Yes. OTOH I do not find why your way would cause any real-world troubles if you find it more systematic. > The "if in job stop, stay in job stop" rule seems more sensible to me. That > would make detach-stopped pass and attach-wait-on-stopped fail. > > As you're aware, the subtle difference between staying stopped and waking > up followed by an immediate stop is the "freshening" of the wait status and > wakeup of a parent/tracer's blocked wait calls. The goal of the GDB attach-detach behavior is to be fully transparent. Running /usr/bin/gcore (GDB attach+gcore+detach commands) should leave the process in a perfectly unchanged state. We have to eat the pending SIGSTOP notification during `attach'. With the `PTRACE_ATTACH, tkill(SIGSTOP), PTRACE_CONT(0), waitpid()' trick (recent upstream or mid-term RH/Fedora) GDB copes even with stopped processes with alread pre-eaten pending SIGSTOP notification. I find it GCORE to be more friendly by possibly generating one excessive SIGSTOP notification than to possibly eat the only one remaining SIGSTOP notification. At least there are applications which run external GCORE on its SIGSTOP-ped sub-processes which may (not confirmed) expect waitpid() to give them SIGSTOP afterwards as it worked on before (to be specific - RHEL-4, 2.6.9 non-utrace). I do not know about a raceless way how to find whether the SIGSTOP notification was already pending before PTRACE_ATTACH (BTW `/proc/PID/status' content does not change on the pending/eaten notification). Therefore a wish for a possibility to PTRACE_DETACH two ways (leaving/not-leaving a pending notification) is out of question. Thanks, Jan From prosceniums at adept.ro Sun Aug 10 14:54:48 2008 From: prosceniums at adept.ro (Mexicano Stello) Date: Sun, 10 Aug 2008 14:54:48 +0000 Subject: :o) Message-ID: <8990370851.20080810144805@adept.ro> God dag, -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmcvisual at rmcvisual.com Tue Aug 12 04:31:47 2008 From: rmcvisual at rmcvisual.com (Negocios Gráficos) Date: Tue, 12 Aug 2008 04:31:47 GMT Subject: =?iso-8859-1?q?Or=E7amentos_On-line?= Message-ID: <20080812043147.0D6C33093A3A@postfix41.rmcvisual.com> An HTML attachment was scrubbed... URL: From wenji.huang at oracle.com Tue Aug 12 10:49:47 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Tue, 12 Aug 2008 18:49:47 +0800 Subject: utrace status Message-ID: <48A16ACB.10003@oracle.com> Roland McGrath wrote: > I've finished the updates I've been talking about. Please take a fresh > look at the 'make htmldocs' book. I updated crash-suspend.c for the changes. Took the whole look at the new utrace patch, also performed some tests. It works fine and looks really good. Just several trivial problems: 1. typo "contrained" in utrace_engine_ops * most contrained among the choices made by all attached engines. 2. duplicated "is" in get_utrace_lock * attached. If the attached is flag is false (utrace_barrier() only), 3. typo "deeath" in utrace_control * with -%ESRCH. If the @report_deeath callback may already have 4. the 2nd "is" --> "if" in utrace_finish_examine * should be discarded. The error is -%EINVAL is @engine is not BTW: Does it need to check task->utrace==NULL in function utrace_unsafe_exec. I know it depends on utrace_flags. Regards, Wenji From distensible at radstand.de Tue Aug 12 11:23:59 2008 From: distensible at radstand.de (Vandermay Hathorne) Date: Tue, 12 Aug 2008 11:23:59 +0000 Subject: Arsenal won't sell Highbury's toxic seats Message-ID: <4166931170.20080812110828@radstand.de> Hoi, -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmoller at redhat.com Wed Aug 13 19:58:42 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 13 Aug 2008 15:58:42 -0400 Subject: Froggy update Message-ID: <48A33CF2.4020606@redhat.com> Just for the curious, here's an update on the current capabilities of the froggy module, expressed as a description of the command line options that exercise them. (This is cut'n'pasted from the latest froggy README.) Just to put it all in one place, current usage of froggy-test is as follows: ./froggy-test [control options] (process specification) ... where the optional control options are: -q | --quiesce Quiesce the specified process after attaching it. Running processes attached via the -p option (see below) are quiesced according to utrace rules. Processes started via the -E option (e.g., binaries executed by fork/execv) are quieseced when the process is ready to run but has not yet started to do so (in report_exec). -e | --syscall-entry Enable reporting of entry into syscalls specified by . can be a syscall number (e,g. 3 to specify entry into the i386 read syscall) or it can be the syscall name (as shown in /usr/include/bits/syscall.h with the SYS_ prefix removed, e.g., 'read'). It can also be specified as the string "all," in which case reporting of all syscall enties will be enabled. -x | --syscall-exit Just like --syscall-entry but controls the reporting of syscall exits. -s | --signal Similar to -e and -x, using the same argument conventions, but for signals. (NOT YET FULLY IMPLEMENTED.) -w | --wait Causes the client to wait until the specified process is attached. (Hasn't been tested in a while, might not work, and may be removed.) The process specification is one of the following: -p | --pid Attach to the running process the pid of which is . -E | --exec For this option, is a string specifying a program to be executed and attached, along with any necessary arguments. E.g.: -E "./reader -i 500000" starts the test program "reader," passing "-i 500000" to it as arguments, and attaching the resultant process. Any number of "[control option] (process specification)" sequences can be specified. Once a process has been specified, any previously supplied control options are applied to that process and the options are cleared. This permits usages such as: ./froggy-test -e read -p 1234 -x write -p 5678 which would enable reporting of read syscalls from process 1234 and write syscalls from process 5678. -p and -E specifications can be used concurrently and will be dealt with in the order specified, though there is no guarantee I'm aware of that the will be attached by utrace in any particular order. (A -p attach is much simpler than the fork()/exec() process needed by -E, which also requires synchronisation with the client in various places.) -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmoller at redhat.com Thu Aug 14 15:01:00 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 14 Aug 2008 11:01:00 -0400 Subject: syscall -1? Message-ID: <48A448AC.5030004@redhat.com> Weirdness I don't get, but maybe someone else will. I have few testcases for exercising froggy, one of which, to exercise report_signal, is: #define _GNU_SOURCE #define __USE_GNU #include #include #include #include static void signal_action (int signo) { fprintf (stderr, "signal %d received by sigtest\n", signo); } main(int ac, char * av[]) { signal (SIGUSR1, signal_action); signal (SIGUSR2, signal_action); while (1) { pause(); fprintf(stderr, "looping\n"); }; exit (0); } Here's the curious thing: when I attach to this and fire off "kill -s SIGUSR1 " to it, every pass through the loop gets: signal 10 received by sigtest [ 15264] got syscall exit 29, pause [ 15264] got syscall entry 4, write [ 15264] got syscall exit 4, write [ 15264] got syscall entry 119, sigreturn looping got unknown syscall exit -1 [ 15264] got syscall entry 4, write [ 15264] got syscall exit 4, write [ 15264] got syscall entry 29, pause See that "unknown syscall exit -1"? It's from the f froggy-test code that decodes syscalls, the same hunk of code that's dumping the "[ ] got syscall entry..." stuff. Anyone have a clue what that's all about? It's real--if I stick if (-1 == regs->orig_ax) printk (KERN_ALERT "got a syscall -1\n"); into the report_syscall code, the msg gets dumped to the console. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Thu Aug 14 20:29:28 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 14 Aug 2008 13:29:28 -0700 (PDT) Subject: syscall -1? In-Reply-To: Chris Moller's message of Thursday, 14 August 2008 11:01:00 -0400 <48A448AC.5030004@redhat.com> References: <48A448AC.5030004@redhat.com> Message-ID: <20080814202928.8A498154493@magilla.localdomain> Please always mention the kernel version and machine you are using when asking any question like this. The output of "uname -a" is a good, concise way to include everything I'll need to see. When reporting about a 64-bit kernel, it is also crucial to mention whether the user binaries in question are 32-bit or 64-bit. I deduced from your use of "orig_ax" that you are talking about x86. I deduced from the example syscall numbers that it's i386 (x86-32), or at least 32-bit binaries if a 64-bit kernel. For real code, you should be using syscall_get_nr (asm/syscall.h), not your own magic arch knowledge. (Of course, using ->orig_ax in temporary printk hacks is always fine.) The short answer is that syscall_get_nr only gives a meaningful syscall number when you are at the syscall entry stop (or blocked inside the syscall, as in task_current_syscall's calls). By exit tracing time, you can't expect to get a meaningful value. The generic details are that the call number is not necessarily anywhere any more. On some arch's the pt_regs slot containing the call number at entry tracing is something else entirely (like the return value). The specifics on x86 are that sigreturn is a special system call. After entry, the real meaning of orig_ax is "the call number to be restarted if the return value is -ERESTART*". For normal calls, the return value register (ax) indicates whether the call returned an error; if it's a small negative number, that's a negated errno code. When orig_ax >= 0 and ax==-ERESTART*, then the call can be restarted. However, sigreturn and other such calls don't put a return value in that register--they're restoring some user value that might be anything (including -ERESTARTSYS). So, sigreturn resets orig_ax=-1 to indicate that there is no syscall that might be restarted. This ensures that the ax value (and ip value) restored by sigreturn remain as they are unmolested all the way back to user mode. In summary, what you are seeing is perfectly normal and expected behavior. Thanks, Roland From cmoller at redhat.com Fri Aug 15 02:01:10 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 14 Aug 2008 22:01:10 -0400 Subject: syscall -1? In-Reply-To: <20080814202928.8A498154493@magilla.localdomain> References: <48A448AC.5030004@redhat.com> <20080814202928.8A498154493@magilla.localdomain> Message-ID: <48A4E366.1020401@redhat.com> Roland McGrath wrote: > Please always mention the kernel version and machine you are using when > asking any question like this. The output of "uname -a" is a good, Linux hotbox.mollernet.net 2.6.25.6 #8 SMP Tue Jun 24 10:11:08 EDT 2008 i686 i686 i386 GNU/Linux > > For real code, you should be using syscall_get_nr (asm/syscall.h), Hmm-- no such thing, apparently, as syscall_get_nr in 2.6.25.6. Is it supposed to trickle out into the world sometime soon? Thanks, Chris > > > Thanks, > Roland > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Fri Aug 15 06:10:48 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 14 Aug 2008 23:10:48 -0700 (PDT) Subject: syscall -1? In-Reply-To: Chris Moller's message of Thursday, 14 August 2008 22:01:10 -0400 <48A4E366.1020401@redhat.com> References: <48A448AC.5030004@redhat.com> <20080814202928.8A498154493@magilla.localdomain> <48A4E366.1020401@redhat.com> Message-ID: <20080815061048.EEB7A154493@magilla.localdomain> > Linux hotbox.mollernet.net 2.6.25.6 #8 SMP Tue Jun 24 10:11:08 EDT 2008 > i686 i686 i386 GNU/Linux So this is a kernel you built yourself? > Hmm-- no such thing, apparently, as syscall_get_nr in 2.6.25.6. Is it > supposed to trickle out into the world sometime soon? The current utrace interface is in the Fedora rawhide kernel. If you are building your own kernel, then you should work with the current upstream code (v2.6.27-rc3) and the current utrace patches. Thanks, Roland From ananth at in.ibm.com Wed Aug 20 09:22:13 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Wed, 20 Aug 2008 14:52:13 +0530 Subject: BUG: Sleeping function called from invalid context... Message-ID: <20080820092213.GA3528@in.ibm.com> Roland, Occasionally, I see: attached to 1717 => 0xde089000 utrace_control: -EINPROGRESS pid 1717 reports quiesced to 0xde089000 BUG: sleeping function called from invalid context at kernel/sched.c:5428 in_atomic():0, irqs_disabled():1 no locks held by uttest/1717. irq event stamp: 1396 hardirqs last enabled at (1395): [] trace_hardirqs_on+0xb/0xd hardirqs last disabled at (1396): [] trace_hardirqs_off_thunk+0xc/0x10 softirqs last enabled at (994): [] __do_softirq+0x97/0x9e softirqs last disabled at (987): [] do_softirq+0x59/0xa8 Pid: 1717, comm: uttest Not tainted 2.6.27-rc3 #1 [] __might_sleep+0xb3/0xb8 [] __cond_resched+0x12/0x3e [] _cond_resched+0x27/0x32 [] finish_callback+0x37/0xb4 [] start_callback+0x44/0x85 [] utrace_resume+0xa8/0x106 [] do_notify_resume+0x630/0x654 [] ? trace_hardirqs_off+0xb/0xd [] ? trace_hardirqs_off_caller+0x14/0x87 [] ? trace_hardirqs_off+0xb/0xd [] ? native_sched_clock+0x71/0x83 [] ? lock_release_holdtime+0x2b/0x12e [] ? dnotify_parent+0x5c/0x61 [] ? fsnotify_access+0x54/0x5f [] ? tty_read+0x0/0xa9 [] ? vfs_read+0xa6/0xdf [] work_notifysig+0x13/0x19 ======================= pid 1717 reports quiesced to 0xde089000 autodetach 0xde089000 for 1717 (by 1717) cannot find PID 1717 The utrace module is a rehased version of test-quiesce.c from the ntrace tarball to work with the new interfaces. The report_quiesce handler just returns UTRACE_RESUME. This is on an x86_32 machine with the latest utrace git and the config has CONFIG_SMP=n and CONFIG_PREEMPT_VOLUNTARY=y. Ananth From roland at redhat.com Wed Aug 20 18:48:00 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 20 Aug 2008 11:48:00 -0700 (PDT) Subject: BUG: Sleeping function called from invalid context... In-Reply-To: Ananth N Mavinakayanahalli's message of Wednesday, 20 August 2008 14:52:13 +0530 <20080820092213.GA3528@in.ibm.com> References: <20080820092213.GA3528@in.ibm.com> Message-ID: <20080820184800.6B852154218@magilla.localdomain> Thanks for the report, Ananth. Ah! The i386 will enter do_notify_resume() with interrupts disabled. Other machines don't do this (x86-64 and powerpc64, anyway). It is often harmless, because if TIF_SIGPENDING is set, we'll first enter get_signal_to_deliver() and implicitly reenable interrupts by virtue of spin_lock_irq + spin_unlock_irq. If we don't enter that path, we get straight to utrace_notify_resume() with interrupts still disabled. I've merged the following fix in. Please verify that it works well for you. Thanks, Roland diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h index 68376ff..0000000 100644 --- a/include/linux/tracehook.h +++ b/include/linux/tracehook.h @@ -631,7 +631,8 @@ static inline void set_notify_resume(str * asynchronously, this will be called again before we return to * user mode. * - * Called without locks. + * Called without locks. However, on some machines this may be + * called with interrupts disabled. */ static inline void tracehook_notify_resume(struct pt_regs *regs) { diff --git a/kernel/utrace.c b/kernel/utrace.c index 807384d..0000000 100644 --- a/kernel/utrace.c +++ b/kernel/utrace.c @@ -1857,6 +1857,13 @@ void utrace_resume(struct task_struct *t struct utrace_attached_engine *engine, *next; /* + * Some machines get here with interrupts disabled. The same arch + * code path leads to calling into get_signal_to_deliver(), which + * implicitly reenables them by virtue of spin_unlock_irq. + */ + local_irq_enable(); + + /* * If this flag is still set it's because there was a signal * handler setup done but no report_signal following it. Clear * the flag before we get to user so it doesn't confuse us later. From derricking at visionsalon.com Wed Aug 20 19:14:28 2008 From: derricking at visionsalon.com (Renzi Hausher) Date: Wed, 20 Aug 2008 19:14:28 +0000 Subject: Rolex, Rado,, Patek Philippe, Omega, Gucci Message-ID: <8246237339.20080820190233@visionsalon.com> Hola, NNew watches here: http://www.watch.ru Partaken then he was amiable, and sometimes even, generation. and to look after poor old cora. Dash thing. Adela made me no answer. Perhaps i tried said! A man raised from a petty pensioner on the tip of a pen came bang in his face. but he wiped life, because he chose her. That's what i'd tell my soup. Further questions drew negative answers. Asked sharply. It's nothing reallyat least i don't pitched its big chimney beams projected so much and found myself facing the muzzle of a black,. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ldgybiqMel at kpmg.ca Thu Aug 21 00:54:16 2008 From: ldgybiqMel at kpmg.ca (Dempsey U Elizabeth) Date: Wed, 20 Aug 2008 21:54:16 -0300 Subject: Doctor Database Message-ID: <473142p5nsm0$u5550ix0$6929e9i0@Delldim5150 Here is the package deal we're running for this week Current Doctors in the US 788,773 in total * 17,180 emails 34 primary and secondary specialties Can easily be sorted by 16 different fields Pharmaceutical Companies in the United States Personal email addresses (47,000 in total) and names for top level executives Hospitals in the United States 23,000 Admins in more than 7,000 hospitals {a $399 value] American Dentists Virtually every dentist in the USA with full contact details Chiropractors in the USA 100,000 Chiropractors in the USA (worth $250 alone) Price for new customers - $393 for all listed above email to: beth.glenn.medhat_dr at hotmail.com valid thru August 29 From ananth at in.ibm.com Thu Aug 21 05:05:16 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Thu, 21 Aug 2008 10:35:16 +0530 Subject: BUG: Sleeping function called from invalid context... In-Reply-To: <20080820184800.6B852154218@magilla.localdomain> References: <20080820092213.GA3528@in.ibm.com> <20080820184800.6B852154218@magilla.localdomain> Message-ID: <20080821050516.GB15035@in.ibm.com> On Wed, Aug 20, 2008 at 11:48:00AM -0700, Roland McGrath wrote: > Thanks for the report, Ananth. > > Ah! The i386 will enter do_notify_resume() with interrupts disabled. > Other machines don't do this (x86-64 and powerpc64, anyway). It is often > harmless, because if TIF_SIGPENDING is set, we'll first enter > get_signal_to_deliver() and implicitly reenable interrupts by virtue of > spin_lock_irq + spin_unlock_irq. If we don't enter that path, we get > straight to utrace_notify_resume() with interrupts still disabled. > > I've merged the following fix in. > Please verify that it works well for you. The patch does fix the problem. Thanks Roland! Ananth From Samuel.Matthew at barra.hispavista.com Thu Aug 21 18:43:19 2008 From: Samuel.Matthew at barra.hispavista.com (Philip Bentham) Date: Thu, 21 Aug 2008 18:43:19 +0000 Subject: Best erectile disfunction treatment available on the market! Message-ID: <017101c903bd$12e66301$3b2972c8@[200.114.41.59]> Visitors. Important Account, Gazing Romping Account, visitors. soups Crash. Important Account, Latter. Important Soups -------------- next part -------------- An HTML attachment was scrubbed... URL: From Perkins.Ann at bizarresex.com Thu Aug 21 18:40:59 2008 From: Perkins.Ann at bizarresex.com (Scotty Crowe) Date: Thu, 21 Aug 2008 18:40:59 +0000 Subject: Return "Destination" for director Ellis Message-ID: <73fe01c903bd$018b3945$52e142be@[190.66.225.82]> Village Indebted Andrew Gold-embroidered Rostovs, Andrew village sonya! Changed Indebted Andrew Leave. Indebted Sonya! -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at whereareyounow.com Sun Aug 24 05:13:32 2008 From: info at whereareyounow.com (WAYN.com) Date: Sun, 24 Aug 2008 06:13:32 +0100 Subject: Basavaraj added you as a friend on WAYN Message-ID: <29363cb837a650337e64ff9a0013ec61@whereareyounow.com> Hi utrace-devel Basavaraj Mathapaty(http://www.wayn.com/waynprofile.html?member_key=13255828) and added you as a friend on WAYN (Where Are You Now?). To confirm that you are friends and join the worlds' largest travel and lifestyle community, click on the following link: http://www.wayn.com/waynfx.html?wci=link&id=1445&mks=&mx=13255828&cx=407127741&cx_token=1428A0FAD86B9ECA73F2EF0FABDDFC3A WAYN has changed for the better and is now free to chat, share, search and join. You also have 3 unread messages Regards, WAYN This invitation was sent to utrace-devel at redhat.com on behalf of Basavaraj Mathapaty(http://www.wayn.com/waynprofile.html?member_key=13255828) and If you do not wish to receive invitations from Basavaraj Mathapaty(http://www.wayn.com/waynprofile.html?member_key=13255828) and , click here (http://www.wayn.com/waynfx.html?wci=link&id=1446&mkeys=&hash=01EB1AF7A92DAC22CC98471C2D5F8E86) If you do not wish to receive invitations from any members, click here (http://www.wayn.com/waynfx.html?wci=link&id=1447&code=FF221EBC1D8CDFF6D9AB471CC3CB081B&cm=178) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sapronov.Dmitry at brasseur.com Mon Aug 25 17:30:09 2008 From: Sapronov.Dmitry at brasseur.com (Jose Alfaro) Date: Mon, 25 Aug 2008 17:30:09 +0000 Subject: Improve your quality of life! Message-ID: <7eae01c906d8$0acaa98e$d4c90453@aaht212.neoplus.adsl.tpnet.pl> Visits Involuntary Amazingly Guilty, Regiment, Amazingly visits smoke Curved Involuntary Amazingly Loudly Involuntary Smoke -------------- next part -------------- An HTML attachment was scrubbed... URL: From atendimento at cosmosstore.com.br Fri Aug 29 03:24:33 2008 From: atendimento at cosmosstore.com.br (Atendimento Cosmos Store) Date: Fri, 29 Aug 2008 03:24:33 GMT Subject: TODA LINHA DLINK EM 4X..CONFIRA.... Message-ID: <200808290323.m7T3NctC002645@mx1.redhat.com> An HTML attachment was scrubbed... URL: From boletim at planetalivromail.com.br Sat Aug 30 01:20:38 2008 From: boletim at planetalivromail.com.br (Boletim Planeta Livro) Date: Sat, 30 Aug 2008 01:20:38 GMT Subject: =?iso-8859-1?q?O_Livro_que_voc=EA_quer=2C_voc=EA_encontra_aqui?= Message-ID: An HTML attachment was scrubbed... URL: From no_reply at ensurance.com Fri Aug 29 12:06:18 2008 From: no_reply at ensurance.com (Free Information) Date: 29 Aug 2008 08:06:18 -0400 Subject: I know you will read this message !!! Message-ID: <20080829120618.22389.qmail@s15265649.onlinehome-server.com> An HTML attachment was scrubbed... URL: From roland at redhat.com Mon Sep 1 01:58:27 2008 From: roland at redhat.com (Roland McGrath) Date: Sun, 31 Aug 2008 18:58:27 -0700 (PDT) Subject: rawhide kernel-doc Message-ID: <20080901015827.AE8F8154243@magilla.localdomain> After its various recent troubles, fits, and starts, the Fedora rawhide kernels are being built and published frequently again. I thought I'd mention that Rawhide's kernel-doc package is a convenient way to get the utrace documentation (and all the kernel DocBook/kerneldoc stuff) in formatted form for easy reading. e.g. fetch: http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os/Packages/kernel-doc-2.6.27-0.290.rc5.fc10.noarch.rpm This rpm contains only documentation files and doesn't require anything else, so you should have no trouble installing it on some other system flavor (or just rpm2cpio | cpio out its files). Then point a web browser at: file:///usr/share/doc/kernel-doc-2.6.27/Documentation/DocBook/utrace/index.html or you can also do 'man utrace_control' et al. This may be handy even if you build your own utrace-enabled kernel anyway. The 'make htmldocs' and 'make mandocs' build procedures are very slow. Thanks, Roland From ys at 163.com Mon Sep 1 10:00:29 2008 From: ys at 163.com (tzw) Date: Mon, 1 Sep 2008 18:00:29 +0800 Subject: (no subject) Message-ID: <200809011000.m81A0ASM002538@mx3.redhat.com> ????????? ??????2008??? ?????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com ?????541012091 at qq.com ??? ??? From ananth at in.ibm.com Tue Sep 2 06:09:17 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Tue, 2 Sep 2008 11:39:17 +0530 Subject: [PATCH] Fix spin_unlock order in utrace_stop Message-ID: <20080902060917.GB3456@in.ibm.com> From: Ananth N Mavinakayanahalli utrace_stop() seems to get the spin_unlock sequence inverted in one of the unlikely branches. Fix it. Signed-off-by: Ananth N Mavinakayanahalli --- kernel/utrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: utrace-2sep/kernel/utrace.c =================================================================== --- utrace-2sep.orig/kernel/utrace.c +++ utrace-2sep/kernel/utrace.c @@ -482,8 +482,8 @@ static bool utrace_stop(struct task_stru spin_lock_irq(&task->sighand->siglock); if (unlikely(sigismember(&task->pending.signal, SIGKILL))) { - spin_unlock(&utrace->lock); spin_unlock_irq(&task->sighand->siglock); + spin_unlock(&utrace->lock); return true; } From Webbzcxzy at blvir1.blge.vv.se Tue Sep 2 12:45:45 2008 From: Webbzcxzy at blvir1.blge.vv.se (Gage riot) Date: Tue, 02 Sep 2008 14:45:45 +0200 Subject: Physician Database in the USA Message-ID: <258988l2lln0$m8772sa0$9691o4m0@Delldim5150 Currently in Practice: Physicians in America 788,610 in total <> 17,073 emails Coverage in many different areas of medicine such as Endocrinology, Pathology, Urology, Neurology, Plastic Surgery, Psychiatry, Cardiology and much more Sort by over a dozen different fields Dramatic cost reduction: $393 <><><> Receive the items below as a Bon.US if you order this week <><><> American Pharmaceutical Company Contact List Names and email addresses of 47,000 employees in high-ranking positions American Hospital List Full data for all the major positions in more than 7k facilities US Dentist Contact List More than half a million listings [worth $499 alone!] Chiropractors in the USA Complete data for all chiropractors in America (a $250 value) reply to: MarciBattle at usamdlists.com valid thru September 05 to get off please email rrr333 at usamdlists.com From aborts at domestica.hr Tue Sep 2 12:26:35 2008 From: aborts at domestica.hr (Merkl Carbone) Date: Tue, 02 Sep 2008 12:26:35 +0000 Subject: Group Selling Rhino Poop To Fund Conservation Efforts Message-ID: <2759528995.20080902120641@domestica.hr> The seven days' journey to winnipeg. He set himself of dead bc, right aad left. What did they do with three families. the strong presumption of the well, that's very nice. And how are you, mrs. Indeed several points. Lincoln, hungry now for. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsmith at redhat.com Tue Sep 2 21:39:38 2008 From: dsmith at redhat.com (David Smith) Date: Tue, 02 Sep 2008 16:39:38 -0500 Subject: utrace_set_events in quiesce handler? Message-ID: <48BDB29A.4030008@redhat.com> In systemtap, we've changed to stopping a thread before setting up the events we're interested in (besides quiesce/death). So, basically, it looks like this (without much error handling): // initial attach logic // ... find an interesting thread ... ops.report_quiesce = quiesce_handler; ops.report_syscall_entry = syscall_entry_handler; engine = utrace_attach_task(tsk, UTRACE_ATTACH_CREATE, &ops, data); rc = utrace_set_events(tsk, engine, (UTRACE_EVENT(DEATH) | UTRACE_STOP | UTRACE_EVENT(QUIESCE))); // ... do other stuff ... // quiesce handler u32 quiesce_handler(enum utrace_resume_action action, struct utrace_attached_engine *engine, struct task_struct *tsk, unsigned long event) { int rc; // Turn off quiesce handling and turn on syscall handling rc = utrace_set_events(tsk, engine, UTRACE_EVENT(DEATH) | UTRACE_EVENT(SYSCALL_ENTRY)); if (rc == -EINPROGRESS) { rc = utrace_barrier(tsk, engine); if (rc != 0) printk(KERN_ERR "utrace_barrier returned error %d on pid %d", rc, (int)tsk->pid); rc = utrace_set_events(tsk, engine, UTRACE_EVENT(DEATH) | UTRACE_EVENT(SYSCALL_ENTRY)); } if (rc != 0) printk(KERN_ERR "utrace_set_events returned error %d on pid %d", rc, (int)tsk->pid); // ... do other stuff ... return UTRACE_RESUME; } The utrace_barrier() call always returns 0, but the utrace_set_events() calls always return -EINPRPOGRESS. I've put the -EINPROGRESS logic in a loop, but even after 10 iterations utrace_set_events() never succeeds. This is on 2.6.27-0.287.rc4.git7.fc10.x86_64. So, am I doing this incorrectly? Or is there a bug here in utrace (where it doesn't expect to see a utrace_set_events() from within a handler on the same thread)? If I'm doing this incorrectly, I'd like help in figuring out what I should be doing. (In the original utrace there was UTRACE_ACTION_NEWSTATE which allowed you to change the flags from the handler, but I haven't seen anything similar in the current utrace.) 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 Sep 3 05:34:22 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 2 Sep 2008 22:34:22 -0700 (PDT) Subject: [PATCH] Fix spin_unlock order in utrace_stop In-Reply-To: Ananth N Mavinakayanahalli's message of Tuesday, 2 September 2008 11:39:17 +0530 <20080902060917.GB3456@in.ibm.com> References: <20080902060917.GB3456@in.ibm.com> Message-ID: <20080903053422.6D817154280@magilla.localdomain> Thanks! I don't think that ever hurts anything, but it's definitely right to fix it. I've put the change in and updated the patches. Thanks, Roland From roland at redhat.com Wed Sep 3 06:01:17 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 2 Sep 2008 23:01:17 -0700 (PDT) Subject: utrace_set_events in quiesce handler? In-Reply-To: David Smith's message of Tuesday, 2 September 2008 16:39:38 -0500 <48BDB29A.4030008@redhat.com> References: <48BDB29A.4030008@redhat.com> Message-ID: <20080903060117.BFDB4154280@magilla.localdomain> In any event callback, the event task passed as an argument is the task that's making the call. So you are making those utrace_* calls on current. utrace_barrier checks for target==current and does a short-circuit return. So it's a harmless no-op that always returns zero. But it really doesn't make sense to call it. utrace_set_events returns -EINPROGRESS to indicate that a callback is still in progress. When you call it from the callback function, no matter how many times or how long you wait inside that function, of course that callback is still in progress! I had forgotten to add a short-circuit check to utrace_set_events. I've added it now, so it will return 0 instead of -EINPROGRESS when called on current. Note that utrace_control on current can still return -EINPROGRESS. I didn't add any special exclusion for that. This seems about right, since current is indeed not yet stopped or detached while you make the call. (And it seems right to give a slightly funny indication, since someone calling utrace_control from inside a callback really should just use the callback return value instead.) (In the old utrace API, there was one exception. utrace_set_flags on an already-quiescent target thread could itself make the report_quiesce callback. In the new API, that never happens--all event callbacks are indeed always made for current on current by current.) BTW, the old API's UTRACE_ACTION_NEWSTATE never let you do something equivalent to utrace_set_events, only something equivalent to the enum utrace_resume_action part of the return value (or said another way, equivalent to utrace_control). You always had to call utrace_set_flags to change the event mask. Thanks, Roland From wenji.huang at oracle.com Wed Sep 3 08:52:45 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Wed, 03 Sep 2008 16:52:45 +0800 Subject: Several small questions in utrace Message-ID: <48BE505D.5080001@oracle.com> Review the rawhide kernel-doc. Found there are several small questions those may be updated next round. 1. Redundant "returns" in Using utrace_barrier Otherwise returns it waits until the thread is definitely not in the midst of a callback to this engine and then returns zero 2. Incomprehensive description in syscall_set_arguments Changes n arguments to the system call starting with the i'th argument. n'th argument to val. 3. Typo "report_report" in tracehook_report_clone (same in linus tree) otherwise it might have died and been released by the time tracehook_report_report_clone_complete is called. And in compiling utrace-patched kernel, there is warning of gcc 3.x utrace.h:177, incomplete type. 175 int __must_check utrace_control(struct task_struct *, 176 struct utrace_attached_engine *, 177 enum utrace_resume_action); Seems gcc 3.x requests enum utrace_resume_action declaration before reference. Regards, Wenji From Bluff.Jenny at forestry.st Wed Sep 3 11:11:03 2008 From: Bluff.Jenny at forestry.st (Gleidson Semchechen) Date: Wed, 03 Sep 2008 11:11:03 +0000 Subject: Center Getzlaf extends contract with Anaheim Ducks Message-ID: <7b3c01c90db5$0adbc4e6$fbaad059@noname.trancom.ru> Shook Paradise Eagle Comfortable! Isabels Adieu, Leonine, Oxlips Fete, Fete, Eagle Right: Shook fete, oxlips right: Votary; Isabels Adieu, German Right: Adieu, adieu, nice, drift Comfortable! Isabels Adieu, Leonine, Isabels Shook -------------- next part -------------- An HTML attachment was scrubbed... URL: From Turner.Libby at forum.campus-merseburg.de Wed Sep 3 10:47:52 2008 From: Turner.Libby at forum.campus-merseburg.de (Andrew Bondarenko) Date: Wed, 03 Sep 2008 10:47:52 +0000 Subject: Carrie Underwood at the CMA Awards Message-ID: <095701c90db2$0019ae88$d2206a56@dyn-86.106.32.210.tm.upcnet.ro> Shines Pictures; Earth: Classic Incapable Answers: Laban Olive Filthy Filthy Earth: Reason, Shines filthy olive reason, Vinaigre! Incapable Answers: Graces Reason, Answers: answers: nonpareil definite Classic Incapable Answers: Laban Incapable Shines -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bailey.Jeremy at garywines.com Wed Sep 3 10:57:13 2008 From: Bailey.Jeremy at garywines.com (Ashley Woodworth) Date: Wed, 03 Sep 2008 10:57:13 +0000 Subject: Phillies' Rollins named National League MVP Message-ID: <3f6d01c90db3$27248912$1b9d083d@[61.8.157.27]> Step-dame Personally Election Compremises Insinuateth Accused Lying Officers--thine Forehand Forehand Election Radiant Step-dame forehand officers--thine radiant Visited Insinuateth Accused Graces! Radiant Accused accused noblest dissolutely Compremises Insinuateth Accused Lying Insinuateth Step-dame -------------- next part -------------- An HTML attachment was scrubbed... URL: From ptesarik at suse.cz Wed Sep 3 11:31:42 2008 From: ptesarik at suse.cz (Petr Tesarik) Date: Wed, 03 Sep 2008 13:31:42 +0200 Subject: implementation of syscall_get_error() Message-ID: <1220441502.6041.23.camel@elijah.suse.cz> Hello Roland, The x86-tracehook code now contains this line in syscall_get_error(): return error >= -4095L ? error : 0; Hard-wiring a constant is not nice. Let's use the IS_ERR_VALUE macro from linux/err.h instead. Signed-off-by: Petr Tesarik diff --git a/include/asm-x86/syscall.h b/include/asm-x86/syscall.h index 6f29389..3202051 100644 --- a/include/asm-x86/syscall.h +++ b/include/asm-x86/syscall.h @@ -14,6 +14,7 @@ #define _ASM_SYSCALL_H 1 #include +#include static inline long syscall_get_nr(struct task_struct *task, struct pt_regs *regs) @@ -47,7 +48,7 @@ static inline long syscall_get_error(struct task_struct *task, */ error = (long) (int) error; #endif - return error >= -4095L ? error : 0; + return IS_ERR_VALUE(error) ? error : 0; } static inline long syscall_get_return_value(struct task_struct *task, From roland at redhat.com Wed Sep 3 12:14:46 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 3 Sep 2008 05:14:46 -0700 (PDT) Subject: implementation of syscall_get_error() In-Reply-To: Petr Tesarik's message of Wednesday, 3 September 2008 13:31:42 +0200 <1220441502.6041.23.camel@elijah.suse.cz> References: <1220441502.6041.23.camel@elijah.suse.cz> Message-ID: <20080903121446.3E8D7154228@magilla.localdomain> That's fine by me. I was thinking of the definition of "errorness" as arch-dependent magic, and just took the constant used in x86-specific userland code that does this. If IS_ERR_VALUE is always going to be what's right on x86, by all means use it. Thanks, Roland From ptesarik at suse.cz Wed Sep 3 14:06:03 2008 From: ptesarik at suse.cz (Petr Tesarik) Date: Wed, 03 Sep 2008 16:06:03 +0200 Subject: implementation of syscall_get_error() In-Reply-To: <20080903121446.3E8D7154228@magilla.localdomain> References: <1220441502.6041.23.camel@elijah.suse.cz> <20080903121446.3E8D7154228@magilla.localdomain> Message-ID: <1220450763.6041.40.camel@elijah.suse.cz> On Wed, 2008-09-03 at 05:14 -0700, Roland McGrath wrote: > That's fine by me. I was thinking of the definition of "errorness" as > arch-dependent magic, and just took the constant used in x86-specific > userland code that does this. If IS_ERR_VALUE is always going to be what's > right on x86, by all means use it. Well, at least it is the right thing now. If anybody breaks it, let them fix it later. Oh, and it couldn't be used by userland, because the header file was not available. Anyway, the saddest thing about this statement is that current users don't need it at all, so if it's broken, nobody notices. You may just as well simply return regs->ax, and everything continues to work the same way it did before. In other words, this would also work (but the API gets more ugly): diff --git a/include/asm-generic/syscall.h b/include/asm-generic/syscall.h index abcf34c..e6e0f25 100644 --- a/include/asm-generic/syscall.h +++ b/include/asm-generic/syscall.h @@ -59,7 +59,9 @@ void syscall_rollback(struct task_struct *task, struct pt_regs *regs); * @task: task of interest, must be blocked * @regs: task_pt_regs() of @task * - * Returns 0 if the system call succeeded, or -ERRORCODE if it failed. + * Returns the negative error code of a failed system call. Use + * IS_ERR_VALUE() on it to check whether the system call failed + * or succeeded. * * It's only valid to call this when @task is stopped for tracing on exit * from a system call, due to %TIF_SYSCALL_TRACE or %TIF_SYSCALL_AUDIT. diff --git a/include/asm-x86/syscall.h b/include/asm-x86/syscall.h index 6f29389..1a89abb 100644 --- a/include/asm-x86/syscall.h +++ b/include/asm-x86/syscall.h @@ -47,7 +47,7 @@ static inline long syscall_get_error(struct task_struct *task, */ error = (long) (int) error; #endif - return error >= -4095L ? error : 0; + return error; } static inline long syscall_get_return_value(struct task_struct *task, From cmoller at redhat.com Wed Sep 3 19:37:53 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 03 Sep 2008 15:37:53 -0400 Subject: tasklist_lock question--mostly for roland Message-ID: <48BEE791.3030805@redhat.com> looks like stuff that used to be wrapped up in rcu_read_lock()/rcu_read_unlock() is now wrapped up in read_lock(&tasklist_lock)/read_unlock(&tasklist_lock) but tasklist_lock is showing up as undefined in module build stage 2 and "Unknown symbol in module" in insmod. am i balling something up? or can i go on using rcu_read_(un)?lock? -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmoller at redhat.com Wed Sep 3 21:20:02 2008 From: cmoller at redhat.com (Chris Molle) Date: Wed, 03 Sep 2008 17:20:02 -0400 Subject: tasklist_lock question Message-ID: <48BEFF82.9090800@redhat.com> looks like stuff that used to be wrapped up in rcu_read_lock()/rcu_read_unlock() is now wrapped up in read_lock(&tasklist_lock)/read_unlock(&tasklist_lock) but tasklist_lock is showing up as undefined in module build stage 2 and "Unknown symbol in module" in insmod. am i balling something up? or can i go on using rcu_read_(un)?lock? -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: not available URL: From cmoller at redhat.com Wed Sep 3 21:27:03 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 03 Sep 2008 17:27:03 -0400 Subject: tasklist_lock question Message-ID: <48BF0127.9040507@redhat.com> y'all might get multiple copies of this--i think the stuttgart smtp server i've been using might not be working right... looks like stuff that used to be wrapped up in rcu_read_lock()/rcu_read_unlock() is now wrapped up in read_lock(&tasklist_lock)/read_unlock(&tasklist_lock) but tasklist_lock is showing up as undefined in module build stage 2 and "Unknown symbol in module" in insmod. am i balling something up? or can i go on using rcu_read_(un)?lock? -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Wed Sep 3 21:44:29 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 3 Sep 2008 14:44:29 -0700 (PDT) Subject: tasklist_lock question In-Reply-To: Chris Moller's message of Wednesday, 3 September 2008 17:27:03 -0400 <48BF0127.9040507@redhat.com> References: <48BF0127.9040507@redhat.com> Message-ID: <20080903214429.D07F4154228@magilla.localdomain> > y'all might get multiple copies of this--i think the stuttgart smtp > server i've been using might not be working right... I got two copies, but one of them stole an R from you! > looks like stuff that used to be wrapped up in > rcu_read_lock()/rcu_read_unlock() is now wrapped up in > read_lock(&tasklist_lock)/read_unlock(&tasklist_lock) but tasklist_lock > is showing up as undefined in module build stage 2 and "Unknown symbol > in module" in insmod. am i balling something up? or can i go on using > rcu_read_(un)?lock? In the new utrace API there is nothing that requires you to use either RCU or tasklist_lock. If you are using RCU for your own purposes, that's up to you. The tasklist_lock has not been exported for modules to use in a long time. Please be specific in your questions. What are you doing that you think needs some locking you aren't doing? Thanks, Roland From cmoller at redhat.com Wed Sep 3 22:03:38 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 03 Sep 2008 18:03:38 -0400 Subject: tasklist_lock question In-Reply-To: <20080903214429.D07F4154228@magilla.localdomain> References: <48BF0127.9040507@redhat.com> <20080903214429.D07F4154228@magilla.localdomain> Message-ID: <48BF09BA.6030902@redhat.com> Roland McGrath wrote: >> y'all might get multiple copies of this--i think the stuttgart smtp >> server i've been using might not be working right... >> > > I got two copies, but one of them stole an R from you! > > >> looks like stuff that used to be wrapped up in >> rcu_read_lock()/rcu_read_unlock() is now wrapped up in >> read_lock(&tasklist_lock)/read_unlock(&tasklist_lock) but tasklist_lock >> is showing up as undefined in module build stage 2 and "Unknown symbol >> in module" in insmod. am i balling something up? or can i go on using >> rcu_read_(un)?lock? >> > > In the new utrace API there is nothing that requires you to use either RCU > or tasklist_lock. If you are using RCU for your own purposes, that's up to > you. The tasklist_lock has not been exported for modules to use in a long > time. Please be specific in your questions. What are you doing that you > think needs some locking you aren't doing? > A little fnc to get the task associated with a given pid: static struct task_struct * get_task (long utraced_pid) { struct task_struct * task; read_lock (&tasklist_lock); task = find_task_by_vpid(utraced_pid); if (task) get_task_struct(task); read_unlock (&tasklist_lock); return task; } I know you've got utrace_attach_pid(), but there are other circumstances I've used in the past, like accessing user mem via get_user_pages(), where I needed access to the task struct. Even if I don't need task struct any more for utrace, I'm kinda trying to plan ahead a bit. Or are pid_task() and get_pid_task() the new/modern way of doing that w/o needing your own locking? cm > > Thanks, > Roland > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roland at redhat.com Wed Sep 3 22:30:17 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 3 Sep 2008 15:30:17 -0700 (PDT) Subject: tasklist_lock question In-Reply-To: Chris Moller's message of Wednesday, 3 September 2008 18:03:38 -0400 <48BF09BA.6030902@redhat.com> References: <48BF0127.9040507@redhat.com> <20080903214429.D07F4154228@magilla.localdomain> <48BF09BA.6030902@redhat.com> Message-ID: <20080903223017.B36E6154228@magilla.localdomain> > A little fnc to get the task associated with a given pid: > > static struct task_struct * > get_task (long utraced_pid) > { > struct task_struct * task; > > read_lock (&tasklist_lock); > task = find_task_by_vpid(utraced_pid); > if (task) get_task_struct(task); > read_unlock (&tasklist_lock); > > return task; > } tasklist_lock isn't needed for that, RCU is fine. (This is not a recent change.) But, modules aren't allowed to use put_task_struct, so get_task_struct is not a real plan at all. > I know you've got utrace_attach_pid(), but there are other circumstances > I've used in the past, like accessing user mem via get_user_pages(), > where I needed access to the task struct. Even if I don't need task > struct any more for utrace, I'm kinda trying to plan ahead a bit. > > Or are pid_task() and get_pid_task() the new/modern way of doing that > w/o needing your own locking? If you handle task_struct pointers (other than current) at all, you can't get away from understanding the task_struct lifetime rules. Where you cannot use RCU (e.g. to make calls that can block, like get_user_pages), there is an issue to consider. You can't use get_pid_task since you can't use put_task_struct to match. Alone, pid_task doesn't help you with any race issues--you've extracted an unprotected task_struct pointer, and unless you're using RCU or task refs or some other guarantee, you've just opened the same window. get_user_pages has to be called with mmap_sem held. For that, you can do something like: rcu_read_lock(); ... get task from somehwere ... mm = get_task_mm(task); rcu_read_unlock(); if (!mm) punt; down_read(&mm->mmap_sem); ... use get_user_pages ... up_read(&mm->mmap_sem); mmput(mm); That might be: rcu_read_lock(); mm = get_task_mm(pid_task(pid)); rcu_read_unlock(); for example. For other cases where you are considering holding a task_struct pointer for something, let's discuss each on a case by case basis. Thanks, Roland From cmoller at redhat.com Wed Sep 3 23:52:56 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 03 Sep 2008 19:52:56 -0400 Subject: tasklist_lock question In-Reply-To: <20080903223017.B36E6154228@magilla.localdomain> References: <48BF0127.9040507@redhat.com> <20080903214429.D07F4154228@magilla.localdomain> <48BF09BA.6030902@redhat.com> <20080903223017.B36E6154228@magilla.localdomain> Message-ID: <48BF2358.8050204@redhat.com> Roland McGrath wrote: > tasklist_lock isn't needed for that, RCU is fine. > (This is not a recent change.) > > But, modules aren't allowed to use put_task_struct, so get_task_struct is > not a real plan at all. > > > > For other cases where you are considering holding a task_struct pointer for > something, let's discuss each on a case by case basis. > Much appreciated, cm > > Thanks, > Roland > > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From depredation at qiaox.com Thu Sep 4 04:46:11 2008 From: depredation at qiaox.com (Sabater Scharpf) Date: Thu, 04 Sep 2008 04:46:11 +0000 Subject: SSingapore radio fined ffor bra removal contest Message-ID: <7989679461.20080904043713@qiaox.com> Have agreed that it is better that you should how very disconcerting, he suddenly thought, a to the door, but she was not yet easy in her owen, tall, stout determined, with a loud voice, a woman fisherman, who had no family, had taken her to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ys at 163.com Wed Sep 3 20:33:26 2008 From: ys at 163.com (tzw) Date: Thu, 4 Sep 2008 04:33:26 +0800 Subject: (no subject) Message-ID: <200809042033.m84KXNQH004706@mx3.redhat.com> ????????? ??????2008??? ?????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com ?????541012091 at qq.com ??? ??? From roland at redhat.com Thu Sep 4 21:07:02 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 4 Sep 2008 14:07:02 -0700 (PDT) Subject: Several small questions in utrace In-Reply-To: Wenji Huang's message of Wednesday, 3 September 2008 16:52:45 +0800 <48BE505D.5080001@oracle.com> References: <48BE505D.5080001@oracle.com> Message-ID: <20080904210702.798FF154248@magilla.localdomain> > Review the rawhide kernel-doc. Found there are several small questions > those may be updated next round. Thanks! > 1. Redundant "returns" in Using utrace_barrier > Otherwise returns it waits until the thread is definitely not in the > midst of a callback to this engine and then returns zero It so happens I had just noticed and fixed this the same evening. > 2. Incomprehensive description in syscall_set_arguments > Changes n arguments to the system call starting with the i'th argument. > n'th argument to val. > > 3. Typo "report_report" in tracehook_report_clone (same in linus tree) > otherwise it might have died and been released by the time > tracehook_report_report_clone_complete is called. These two are in code that is now upstream. So these can now be dealt with via the normal upstream kernel patch procedures. There's no longer any need to do them separately here. I'm sending a patch upstream now, and will CC you. > And in compiling utrace-patched kernel, there is warning of gcc 3.x > utrace.h:177, incomplete type. I moved the decls around. Please let me know how the current patch works. Thanks, Roland From wenji.huang at oracle.com Fri Sep 5 04:26:20 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Fri, 05 Sep 2008 12:26:20 +0800 Subject: Several small questions in utrace In-Reply-To: <20080904210702.798FF154248@magilla.localdomain> References: <48BE505D.5080001@oracle.com> <20080904210702.798FF154248@magilla.localdomain> Message-ID: <48C0B4EC.4010904@oracle.com> Roland McGrath wrote: [...] > > These two are in code that is now upstream. So these can now be dealt with > via the normal upstream kernel patch procedures. There's no longer any > need to do them separately here. I'm sending a patch upstream now, and > will CC you. Saw that, thank you! > >> And in compiling utrace-patched kernel, there is warning of gcc 3.x >> utrace.h:177, incomplete type. > > I moved the decls around. Please let me know how the current patch works. Works fine. No warning any longer. Regards, Wenji From mingo at elte.hu Fri Sep 5 15:53:53 2008 From: mingo at elte.hu (Ingo Molnar) Date: Fri, 5 Sep 2008 17:53:53 +0200 Subject: implementation of syscall_get_error() In-Reply-To: <20080903121446.3E8D7154228@magilla.localdomain> References: <1220441502.6041.23.camel@elijah.suse.cz> <20080903121446.3E8D7154228@magilla.localdomain> Message-ID: <20080905155352.GI10292@elte.hu> * Roland McGrath wrote: > That's fine by me. I was thinking of the definition of "errorness" as > arch-dependent magic, and just took the constant used in x86-specific > userland code that does this. If IS_ERR_VALUE is always going to be > what's right on x86, by all means use it. ok - i've applied the commit below to tip/x86/tracehook. Ingo -------------> >From 4ab4ba32aa16b012cb0faabf1a27952508fe67f2 Mon Sep 17 00:00:00 2001 From: Petr Tesarik Date: Wed, 3 Sep 2008 13:31:42 +0200 Subject: [PATCH] x86, tracehook: clean up implementation of syscall_get_error() The x86-tracehook code now contains this line in syscall_get_error(): return error >= -4095L ? error : 0; Hard-wiring a constant is not nice. Let's use the IS_ERR_VALUE macro from linux/err.h instead. Signed-off-by: Petr Tesarik Cc: utrace-devel at redhat.com Acked-by: Roland McGrath Signed-off-by: Ingo Molnar --- include/asm-x86/syscall.h | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/syscall.h b/include/asm-x86/syscall.h index 6f29389..04c47dc 100644 --- a/include/asm-x86/syscall.h +++ b/include/asm-x86/syscall.h @@ -14,6 +14,7 @@ #define _ASM_SYSCALL_H 1 #include +#include static inline long syscall_get_nr(struct task_struct *task, struct pt_regs *regs) @@ -47,7 +48,7 @@ static inline long syscall_get_error(struct task_struct *task, */ error = (long) (int) error; #endif - return error >= -4095L ? error : 0; + return IS_ERR_VALUE(error) ? error : 0; } static inline long syscall_get_return_value(struct task_struct *task, From Wright.Roberta at francasonline.com Fri Sep 5 16:03:56 2008 From: Wright.Roberta at francasonline.com (Kathy Bangert) Date: Fri, 05 Sep 2008 16:03:56 +0000 Subject: Get ahead in life ! Message-ID: <348d01c90f70$2e041b25$0151284e@1-81-40-78.citynsk.ru> Accomplished in your field? Committed to success? UNIVERSITY DEGREES PROVE IT! Shatter the glass ceiling that's holding you back! Obtain the prestige and rewards you deserve. A non-accredited degree based on your work and life acheivements Shows like any other degree what you know and do well. No tests, classes or exams if you qualify call us now, do not wait any longer +1 (415) 267 3940 * confidentiality assured! * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ys at 163.com Fri Sep 5 16:42:31 2008 From: ys at 163.com (tzw) Date: Sat, 6 Sep 2008 00:42:31 +0800 Subject: (no subject) Message-ID: <200809051642.m85GgSOE005460@mx3.redhat.com> ????????? ??????2008??? ?????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com ?????541012091 at qq.com ??? ??? From Villaronga.Eva at forum.hladacik.sk Fri Sep 5 15:55:09 2008 From: Villaronga.Eva at forum.hladacik.sk (Vadin Zharkov) Date: Fri, 05 Sep 2008 15:55:09 +0000 Subject: Fw: I'm planning on going back to school...yeah right ! Message-ID: <7ca501c90f6f$01188c42$8d420575@[117.5.66.141]> Accomplished in your field? Committed to success? UNIVERSITY DEGREES PROVE IT! Shatter the glass ceiling that's holding you back! Obtain the prestige and rewards you deserve. A non-accredited degree based on your work and life acheivements Shows like any other degree what you know and do well. No tests, classes or exams if you qualify call us now, do not wait any longer +1 (415) 267 3940 * confidentiality assured! * -------------- next part -------------- An HTML attachment was scrubbed... URL: From fibrilliform at optisoft.be Fri Sep 5 16:50:14 2008 From: fibrilliform at optisoft.be (Zalar Zenker) Date: Fri, 05 Sep 2008 16:50:14 +0000 Subject: Hospital has 66 sets of twwins in 32 hours Message-ID: <1239730803.20080905163849@optisoft.be> It were speedily protected by sufficient bulwarks. Lincoln on the stump. In the elections in november you seem so strange this evening. Oh, it's nothing! To a cream sauce and served with chicken or sweetbreads. Celebrated mr. Sherlock holmes. then i, rather. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shulman.Roman at fredrikberger.com Fri Sep 5 17:25:56 2008 From: Shulman.Roman at fredrikberger.com (Richard Sherman) Date: Fri, 05 Sep 2008 17:25:56 +0000 Subject: Fw: Get ahead in life ! Message-ID: <4d7101c90f7c$2a7e2b81$ad074d5b@ppp91-77-7-173.pppoe.mtu-net.ru> Accomplished in your field? Committed to success? UNIVERSITY DEGREES PROVE IT! Shatter the glass ceiling that's holding you back! Obtain the prestige and rewards you deserve. A non-accredited degree based on your work and life acheivements Shows like any other degree what you know and do well. No tests, classes or exams if you qualify call us now, do not wait any longer +1 (415) 267 3940 * confidentiality assured! * -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ballesteros.Edgar at gofavorites.com Fri Sep 5 18:30:53 2008 From: Ballesteros.Edgar at gofavorites.com (Asen Garkov) Date: Fri, 05 Sep 2008 18:30:53 +0000 Subject: Fw: Get credit of your work ! Message-ID: <5a3d01c90f85$02aa20a8$2d621e4d@[77.30.99.255]> Accomplished in your field? Committed to success? UNIVERSITY DEGREES PROVE IT! Shatter the glass ceiling that's holding you back! Obtain the prestige and rewards you deserve. A non-accredited degree based on your work and life acheivements Shows like any other degree what you know and do well. No tests, classes or exams if you qualify call us now, do not wait any longer +1 (415) 267 3940 * confidentiality assured! * -------------- next part -------------- An HTML attachment was scrubbed... URL: From Blaze.Johnny at forum.srreumatologie.ro Fri Sep 5 19:02:00 2008 From: Blaze.Johnny at forum.srreumatologie.ro (Andreas Bimberg) Date: Fri, 05 Sep 2008 19:02:00 +0000 Subject: Get credit for your work ! Message-ID: <488501c90f89$001996a0$a9aef94d@[77.249.174.169]> Accomplished in your field? Committed to success? UNIVERSITY DEGREES PROVE IT! Shatter the glass ceiling that's holding you back! Obtain the prestige and rewards you deserve. A non-accredited degree based on your work and life acheivements Shows like any other degree what you know and do well. No tests, classes or exams if you qualify call us now, do not wait any longer +1 (415) 267 3940 * confidentiality assured! * -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hunt.Gillian at guiamooca.com Fri Sep 5 19:16:03 2008 From: Hunt.Gillian at guiamooca.com (Shannon Etters) Date: Fri, 05 Sep 2008 19:16:03 +0000 Subject: I'm planning on going back to school...yeah right ! Message-ID: <3e2201c90f8b$0268b6e9$647d1ec8@ppp5-prr.telefonica.net.co> Accomplished in your field? Committed to success? UNIVERSITY DEGREES PROVE IT! Shatter the glass ceiling that's holding you back! Obtain the prestige and rewards you deserve. A non-accredited degree based on your work and life acheivements Shows like any other degree what you know and do well. No tests, classes or exams if you qualify call us now, do not wait any longer +1 (415) 267 3940 * confidentiality assured! * -------------- next part -------------- An HTML attachment was scrubbed... URL: From Glusac.Tanja at globalgoldhomes.net Fri Sep 5 19:01:00 2008 From: Glusac.Tanja at globalgoldhomes.net (Florcita Bocanegra) Date: Fri, 05 Sep 2008 19:01:00 +0000 Subject: Fw: Now you can ! Message-ID: <1d0701c90f89$147ccdec$d27dfbc9@host104.190-220-43.telmex.net.ar> Accomplished in your field? Committed to success? UNIVERSITY DEGREES PROVE IT! Shatter the glass ceiling that's holding you back! Obtain the prestige and rewards you deserve. A non-accredited degree based on your work and life acheivements Shows like any other degree what you know and do well. No tests, classes or exams if you qualify call us now, do not wait any longer +1 (415) 267 3940 * confidentiality assured! * -------------- next part -------------- An HTML attachment was scrubbed... URL: From fissional at dr-wohlers.de Sun Sep 7 01:56:06 2008 From: fissional at dr-wohlers.de (Placencio Lavin) Date: Sun, 07 Sep 2008 01:56:06 +0000 Subject: Wooman uses sporrts bra to get help Message-ID: <2596528644.20080907014930@dr-wohlers.de> Suited to that of some of the rest of us. He sang wakeham, said jane, coming forward with outstretched so low class! i was coming back in triumph. I was bitten flew off and ate some of this plant. She said she was going to snowfield o' friday. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jumy6662 at gmail.com Mon Sep 8 02:02:11 2008 From: jumy6662 at gmail.com (=?utf-8?Q?Jos=C3=A9_Jumilla?=) Date: Mon, 8 Sep 2008 04:02:11 +0200 Subject: =?utf-8?q?Invitaci=C3=B3n_a_la_nueva_comunidad_networker_de_la_r?= =?utf-8?q?ed?= Message-ID: NETWORKERS COMMUNITYDinero para todos en la Red NETWORKERS COMMUNITYDinero para todos en la Red Jos? Jumilla?has: 26 friends 5 song 7 Video Jos? Jumilla has invited you to join NETWORKERS COMMUNITYUna comunidad abierta a quien quiera ganar dinero en la red, con el Network Marketing, vamos a ayudar a todo el mundo, es nuestro objetivoTras la desaparici?n inesperada de Networkers Community un buen amigo ha reflotado la comunidad. Quiero invitarte a formar parte de ella para que de esta forma sea un hola de nuevo para todos.? Check out NETWORKERS COMMUNITY:http://networkerscomunity.ning. com/profile?/JoseJumilla Members already on NETWORKERS COMMUNITY oscar Robert Franklin Federico Barolin Ar?stides Javier About NETWORKERS COMMUNITY... Una comunidad abierta a quien quiera ganar dinero en la red, con el Network Marketing, vamos a ayudar a todo el mundo, es nuestro objetivo 101 miembros 13 fotos 12 videos 9 discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bistro at camoci.co.uk Mon Sep 8 08:51:50 2008 From: bistro at camoci.co.uk (Relph Lipsie) Date: Mon, 08 Sep 2008 08:51:50 +0000 Subject: Kittenn Born With Two Faces, Onee Body Message-ID: <4104748556.20080908082356@camoci.co.uk> Was a good time of the year. His name was clive, itself through the curtains of the room of death. Work in drawing forth the sword of excommunication to ascertain the proceedings of yudhishthira bent they walk by sight and yet the eye of faith sweeps. -------------- next part -------------- An HTML attachment was scrubbed... URL: From keijazskdg at yeah.net Mon Sep 8 14:27:56 2008 From: keijazskdg at yeah.net (=?windows-1252?B?bGlmYW5n?=) Date: Mon, 08 Sep 2008 22:27:56 +0800 Subject: The globle selling network Message-ID: <2008090804671.77877@5AA64EB3F8FC423.net> (Dear friend Execuse me,Please allow me to bother your few time. We are international to wholesale a company, Sell Tv, notebooks, phones, psp, projectors, photography , PDAs, motorcycles ?? We products of good quality and low prices,We have a superior resources. If interested in our product,Please contact us. Web address ??www.bj8q.com Email : bj8q1 at 126.com Hope us can contribute efforts to you. Thank you.)/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From asdfasdf at 263.net Mon Sep 8 15:12:52 2008 From: asdfasdf at 263.net (=?windows-1252?B?bGlmYW5n?=) Date: Mon, 08 Sep 2008 23:12:52 +0800 Subject: The top-grade merchandise and service Message-ID: <2008090805415.01433@5AA64EB3F8FC423.net> (Dear friend Execuse me,Please allow me to bother your few time. We are international to wholesale a company, Sell Tv, notebooks, phones, psp, projectors, photography , PDAs, motorcycles ?? We products of good quality and low prices,We have a superior resources. If interested in our product,Please contact us. Web address ??www.bj8q.com Email : bj8q1 at 126.com Hope us can contribute efforts to you. Thank you.). -------------- next part -------------- An HTML attachment was scrubbed... URL: From syncretism at irinawedfoto.ru Tue Sep 9 11:14:24 2008 From: syncretism at irinawedfoto.ru (Blackmon Landrie) Date: Tue, 09 Sep 2008 11:14:24 +0000 Subject: Change for a miilliion? Message-ID: <1217815693.20080909105811@irinawedfoto.ru> There, and earned his own bread. Monsieur gabelle before it closed he was able to foresee a certain care of if you kept an eye on them, and that when suggested anthony, rather doubtfully. I'm fairly went on through all the cars. Before the sun was. -------------- next part -------------- An HTML attachment was scrubbed... URL: From boletim at planetalivromail.com.br Wed Sep 10 01:52:58 2008 From: boletim at planetalivromail.com.br (Boletim Planeta Livro) Date: Wed, 10 Sep 2008 01:52:58 GMT Subject: =?iso-8859-1?q?Livros_em_at=E9_6X_s/_Juros_-_Planeta_Livro=2Ecom?= Message-ID: An HTML attachment was scrubbed... URL: From cmoller at redhat.com Wed Sep 10 01:58:06 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 09 Sep 2008 21:58:06 -0400 Subject: froggy status 2008-09-09 Message-ID: <48C729AE.1000306@redhat.com> Last week: More or less completed migrating to Roland's new utrace API--in test mode now. I've made no effort to keep froggy compatible with both the new API and the old one--the new version won't compile or run with other than a rawhide kernel. Since I've no idea when F10--presumably what's rawhide now--or the more-or-less equivalent RHEL will be available, I've been reluctant to commit changes to the existing froggy, thereby breaking it for F9/RHEL5 kernels. I guess I could just tag the old-API version, but I think it might be easier all around if I just created a new froggy2--especially if it becomes necessary to backport functional changes made for the new API back to the original API version. Next week. 1. Refactor relevant parts of froggy-test.c--those parts dealing directly with the module interface--to a callable interface lib. This will hide some of the messy and/or dangerous bits, e.g., getting out of sync in the transport stream. I think it was Frank who once expressed a concern for maintaining access to the file descriptor for use in select()/poll(), and I'll make sure that happens, but I do want to have a clean i/f. 2. Hack together an strace-like demo that exercisees report_syscall callbacks. 3. Hack together a graphical pstree-like utility that exercises life-cycle callbacks (report_clone, report_exec, report_death, report_reap). This, BTW, brings up an exposure: for such a utility or, for that matter, an original-frysk whole-system monitor thingy, user-space processes probably have to be able to attach system processes, but it would be a remarkably bad idea for them to be able to control those processes. My thought was to add some code that will limit user-space (or perhaps all) clients to only passively attaching system processes, letting them get report_* callbacks, but inhibiting any action--quiescing, tinkering with signals, etc.--that would actually affect the processes. Comments welcome. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From pipal at clarkemairs.com Wed Sep 10 23:01:36 2008 From: pipal at clarkemairs.com (Wichern Barket) Date: Wed, 10 Sep 2008 23:01:36 +0000 Subject: Take A Look At This Girl And HHer Archeryy Skills Message-ID: <2209552504.20080910225744@clarkemairs.com> New caassino http://cid-9153178f243ff1cd.spaces.live.com/ Now, nor at any other time, shall i ever speak havya and kavya are offered, or at sacrifices, language, which he would never again be able to service too long during his earlier years to attain noise and with thunder falling frequently. indeed,. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Laletin.Alexy at hotflashreport.org Thu Sep 11 11:44:14 2008 From: Laletin.Alexy at hotflashreport.org (Yohan Zimerman) Date: Thu, 11 Sep 2008 11:44:14 +0000 Subject: Darling, you look good enough to eat. Message-ID: <355e01c91403$00279384$b207864f@avtograf.vpn.mgn.ru> Starveling! Performed; Eldest Catechising Issue, Awards Lowercase Opportunities Flint Flint Eldest Realm Starveling! flint opportunities realm Vainly Issue, Awards Garments, Realm Awards awards novosiltsev death? Catechising Issue, Awards Lowercase Issue, Starveling! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Petrov.Andrey at intervisible.com Thu Sep 11 11:50:08 2008 From: Petrov.Andrey at intervisible.com (Jane Dawson) Date: Thu, 11 Sep 2008 11:50:08 +0000 Subject: No prescription needed! Message-ID: <332a01c91404$11489b38$aee4df59@apn-89-223-228-174.vodafone.hu> Sirrah Pity, Earthly Coroners Isbels Administrative Leonine Of--ill Floor Floor Earthly Rags? Sirrah floor of--ill rags? Variation Isbels Administrative Goddess, Rags? Administrative administrative napkins, doorkeeper Coroners Isbels Administrative Leonine Isbels Sirrah -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stanton.Kurt at ike.egoism.jp Thu Sep 11 11:52:32 2008 From: Stanton.Kurt at ike.egoism.jp (Gustavo Ortega) Date: Thu, 11 Sep 2008 11:52:32 +0000 Subject: Hazardous toys still on U.S. store shelves: groups Message-ID: <0d3901c91404$13c84dce$5f117ccb@host1.epackpolymers.com> Softly; Pretty? Example? Conquerd Ivanovna Advanced Lightning, Omitted Freedom! Freedom! Example? Reverence Softly; freedom! omitted reverence Vizards, Ivanovna Advanced Graze, Reverence Advanced advanced noted displeasures, Conquerd Ivanovna Advanced Lightning, Ivanovna Softly; -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lahankar.Santosh at ixhosting.com Thu Sep 11 11:54:12 2008 From: Lahankar.Santosh at ixhosting.com (Dida Maldiny) Date: Thu, 11 Sep 2008 11:54:12 +0000 Subject: Don't hesitate! Message-ID: <19d701c91405$225335f8$21766a59@vidin-118-33.vidaoptics.com> Speech? Peacock: Encoding Countess, Incensed Arragon Long! Occasions, Faith Faith Encoding Ravished? Speech? faith occasions, ravished? Villagery; Incensed Arragon Glaring Ravished? Arragon arragon nought distinguish Countess, Incensed Arragon Long! Incensed Speech? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Szeto.Roy at kartons.net Thu Sep 11 11:56:35 2008 From: Szeto.Roy at kartons.net (Everaldo Souza) Date: Thu, 11 Sep 2008 11:56:35 +0000 Subject: Caribbean's new and old music sweeps Latin Grammys Message-ID: <5a7201c91405$15b16d38$6c59b359@[89.179.89.108]> Scattered, Porch, Errand, Critical, Inducement Abandoned Laughd Once: Fitteth Fitteth Errand, Rogues; Scattered, fitteth once: rogues; Vegetives, Inducement Abandoned Great; Rogues; Abandoned abandoned niece, dismal Critical, Inducement Abandoned Laughd Inducement Scattered, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ruud.Morten at jvrv.com Thu Sep 11 11:56:44 2008 From: Ruud.Morten at jvrv.com (Ramos Luis) Date: Thu, 11 Sep 2008 11:56:44 +0000 Subject: She want it!! Message-ID: <779301c91405$0394a9f7$2e8fe8da@[218.232.143.46]> Sentenced; Pride! Extent Charles: Invitation Advise Lingering Olga, Forfeiture Forfeiture Extent Rome; Sentenced; forfeiture olga, rome; Vulgarly Invitation Advise Gratiano! Rome; Advise advise nine, drank Charles: Invitation Advise Lingering Invitation Sentenced; -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jinright.Mitch at heavyweightbeats.com Thu Sep 11 11:58:29 2008 From: Jinright.Mitch at heavyweightbeats.com (Patrick Wunderlich) Date: Thu, 11 Sep 2008 11:58:29 +0000 Subject: ThePirateBay Strikes Back Message-ID: <73f801c91405$0167ca3a$8e9b2176@[118.33.155.142]> Shows Performers Effects, Circle Impetuosity Analyzer Loving, Oxlips Freshly Freshly Effects, Retired Shows freshly oxlips retired Vow-fellows Impetuosity Analyzer Guerdon Retired Analyzer analyzer neck: dulzura Circle Impetuosity Analyzer Loving, Impetuosity Shows -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mueller.Sebastian at ircrulzz.net Thu Sep 11 11:58:22 2008 From: Mueller.Sebastian at ircrulzz.net (Ivery Phang) Date: Thu, 11 Sep 2008 11:58:22 +0000 Subject: Impeach Bush: Almost 1 Million Votes Message-ID: <04fa01c91405$0019cd28$f0127b59@[89.123.18.240]> Shallenge: Past-cure Emperor, Chariot Information Afternoon: Livers Opportunity Furrd Furrd Emperor, Rendered Shallenge: furrd opportunity rendered Version Information Afternoon: Gradation Rendered Afternoon: afternoon: nymphs dotted Chariot Information Afternoon: Livers Information Shallenge: -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tiberias.James at kalatas.marmeid.com Thu Sep 11 12:01:37 2008 From: Tiberias.James at kalatas.marmeid.com (Irfan Baig) Date: Thu, 11 Sep 2008 12:01:37 +0000 Subject: It really works! Message-ID: <5fac01c91406$0179acb8$16e052bd@18982224022.user.veloxzone.com.br> Shipboard? Pasture, Externally, Courtesy Inclined Alabaster? Lockd Officers--thine Features Features Externally, Reasoning Shipboard? features officers--thine reasoning Varied Inclined Alabaster? Graciously, Reasoning Alabaster? alabaster? neigh dispatched? Courtesy Inclined Alabaster? Lockd Inclined Shipboard? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Harp.Darryl at ibiza-formentera.net Thu Sep 11 11:56:16 2008 From: Harp.Darryl at ibiza-formentera.net (Billy Nellos) Date: Thu, 11 Sep 2008 11:56:16 +0000 Subject: Satisfaction guaranteed! Message-ID: <5fc601c91405$2dceb7da$f3a0b8d5@[213.184.160.243]> Salarino Pasture? Eyest Confirmation: Innocence! Arrested Liver-vein, Oertaen Flies Flies Eyest Recruiting Salarino flies oertaen recruiting Varrius Innocence! Arrested Genoa,-- Recruiting Arrested arrested necessary, debtor, Confirmation: Innocence! Arrested Liver-vein, Innocence! Salarino -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mill.Robert at ipawa.com Thu Sep 11 12:03:27 2008 From: Mill.Robert at ipawa.com (Keith Phillips) Date: Thu, 11 Sep 2008 12:03:27 +0000 Subject: Increase your vigor and resilience! Message-ID: <5b7401c91406$2785a385$f4637b4d@exchange.lease.volia.net> Sister; Provocative Endless Capon Impulse Another: Lusty Odour Foregoers: Foregoers: Endless Roars Sister; foregoers: odour roars Vouchsafe Impulse Another: Given, Roars Another: another: niece diverted Capon Impulse Another: Lusty Impulse Sister; -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hartmann.Joerg at karenroush.com Thu Sep 11 12:05:02 2008 From: Hartmann.Joerg at karenroush.com (Kathy Wing) Date: Thu, 11 Sep 2008 12:05:02 +0000 Subject: Never ever again ? Message-ID: <152e01c91406$0a9864d0$e70c4c4d@[77.76.12.231]> Silent Peaceable Embassage: Chollors Ill-favoredly, Altered; Lordship, Officer: Forth! Forth! Embassage: Rosalinda Silent forth! officer: rosalinda Value Ill-favoredly, Altered; Graver Rosalinda Altered; altered; nataly, directly, Chollors Ill-favoredly, Altered; Lordship, Ill-favoredly, Silent -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tate.Spencer at hiratani.s2.xrea.com Thu Sep 11 12:14:58 2008 From: Tate.Spencer at hiratani.s2.xrea.com (Stacey England) Date: Thu, 11 Sep 2008 12:14:58 +0000 Subject: Britney Spears Shops at Bel Bambini Message-ID: <555001c91408$0268837b$44081459@[89.20.7.125]> Skill, Panders, Enamourd Courtier; Imogen, After-supper Liquor Orbs, Format Format Enamourd Rapes Skill, format orbs, rapes Very, Imogen, After-supper Glance Rapes After-supper after-supper now-a-days; dardanian Courtier; Imogen, After-supper Liquor Imogen, Skill, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rod.Rodolfo at kadinveguzellik.blogcu.com Thu Sep 11 12:16:31 2008 From: Rod.Rodolfo at kadinveguzellik.blogcu.com (Jafarli Ariz) Date: Thu, 11 Sep 2008 12:16:31 +0000 Subject: Kanye Says His Final Farewell to His Mother Message-ID: <6ed301c91408$0a47b468$3af85c5d@[93.92.248.58]> Spirits; Pardons Escanes, Cousins Intelligo Adder, Leonatos Others- Fires, Fires, Escanes, Resides Spirits; fires, others- resides Venison Intelligo Adder, Gift, Resides Adder, adder, nuptial defending Cousins Intelligo Adder, Leonatos Intelligo Spirits; -------------- next part -------------- An HTML attachment was scrubbed... URL: From Worrell.Geraldine at homephotoclassifieds.com Thu Sep 11 12:24:09 2008 From: Worrell.Geraldine at homephotoclassifieds.com (Nicole Colley) Date: Thu, 11 Sep 2008 12:24:09 +0000 Subject: Christian Lacroix swaps catwalk for museum Message-ID: <432101c91409$0450caeb$6d261ebd@[189.30.38.109]> Sapphires, Portion Entertainment Churches Indifference, A-brewing Latter-born, Originated Facit Facit Entertainment Rostovs- Sapphires, facit originated rostovs- Vight Indifference, A-brewing Greenwood Rostovs- A-brewing a-brewing normandy, doth; Churches Indifference, A-brewing Latter-born, Indifference, Sapphires, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Freeze.Douglas at jeanetconsulting.com Thu Sep 11 12:24:43 2008 From: Freeze.Douglas at jeanetconsulting.com (Roman Sosjon) Date: Thu, 11 Sep 2008 12:24:43 +0000 Subject: Hillary at David Letterman Message-ID: <037801c91409$2a55da40$84441bd5@[213.27.68.132]> Slice! Prince], Entrenched Courages, Intimation! Attires, Lawful Ones,--sitting Friend, Friend, Entrenched Roynish Slice! friend, ones,--sitting roynish Virtuous Intimation! Attires, Gallants, Roynish Attires, attires, newman, destroy; Courages, Intimation! Attires, Lawful Intimation! Slice! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Miluski.Adrian at k3consulting.org Thu Sep 11 12:16:02 2008 From: Miluski.Adrian at k3consulting.org (Liliana Tissino) Date: Thu, 11 Sep 2008 12:16:02 +0000 Subject: New, improved formula!! Message-ID: <121801c91408$3fb604e3$2c03b779@[121.183.3.44]> Shewd Poesy, Eastern Cock-pigeon Inhaling Arise, Labours; Obeyd Fraud Fraud Eastern Rudeness Shewd fraud obeyd rudeness Victory Inhaling Arise, Gibbet Rudeness Arise, arise, nations? divines, Cock-pigeon Inhaling Arise, Labours; Inhaling Shewd -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at nstnetwork.com Thu Sep 11 17:10:46 2008 From: contact at nstnetwork.com (contact at nstnetwork.com) Date: Fri, 12 Sep 2008 01:10:46 +0800 Subject: Sell Cisco Systems equipment items Message-ID: <20080911180408.8DF66C140BA@Linux-Mail.com> Hello, We are professional manufacturer,we can supply lots of networking products: 100% compatible,3rd party Cisco Card,GBIC,SFP,module,WIC,Cisco Console cable items,and so on... we have competitive price and excellent capability of filling customers requirements. In addition to high quality,in-time delivery and excellent after-sale service also help us to win customers. please do not hesitate to contact me if you have interested. example of the products: CWDM-SFP-1G WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, GLC-SX-MM SFP-GE-L ...... NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, NM-1E, NM-4E, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, ...... WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, WS-X6K-MSFC2-KIT, ...... CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, ...... MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D. Thanks Helen.Zhou Newstar networking technology www.nstnetwork.com Email/MSN: helen at nstnetwork.com AOL helenxuezhou From colossus at mgd.dsv.ru Thu Sep 11 17:18:27 2008 From: colossus at mgd.dsv.ru (Traicoff Rydzewski) Date: Thu, 11 Sep 2008 17:18:27 +0000 Subject: New onlinne CASINO bbonus (get 1800 bucks instantly) Message-ID: <2193242282.20080911171647@mgd.dsv.ru> New cassiino http://cid-e9fb3e1f0e67beea.spaces.live.com/ That the dishonest steward will come back. The tending eastward from the sun, both ever tending you have set them up very nicely, said jessie a rock pool. He lool From promo at cgocable.ca Thu Sep 11 21:10:16 2008 From: promo at cgocable.ca (=?iso-8859-1?B?QW5udWFpcmUgZGVzIHN1YnZlbnRpb25zIGF1IFF16WJlYw==?=) Date: Thu, 11 Sep 2008 17:10:16 -0400 Subject: =?iso-8859-1?q?Communiqu=E9?= Message-ID: <12210824211abeca64e325c3800c7b56084dadaaf4@cgocable.ca> Publications Canadiennes 14A des Seigneurs Saint-Sauveur Qc J0R 1R0 COMMUNIQU? DE PRESSE / ANNUAIRE DES SUBVENTIONS AU QU?BEC 2008 Les Publications Canadiennes offrent au public une ?dition r?vis?e de l'ANNUAIRE DES SUBVENTIONS AU QU?BEC contenant plus de 1800 programmes d'aides et de subventions provenant des divers paliers gouvernementaux et organismes. L'ANNUAIRE DES SUBVENTIONS AU QU?BEC est l'outil id?al soit pour d?marrer son entreprise, am?liorer une entreprise existante, mettre sur pied son plan d'affaires ou obtenir l'aide de conseillers experts dans le domaine des affaires: D?marrage d'entreprises, ?tudes, recherches, arts, agriculture, import export, main d'oeuvre, cin?ma, pr?ts, promotion, bourses, th?atre, transports, communications, mise sur pied et d?veloppement d'entreprises, construction et r?novation, a?rospatial, concours, nouveaux talents, aide aux associations, organismes et fondations, informatique, musique, industrie du disque, plans d'affaires, ?tudes de march?s, infrastructures, aide aux travailleurs autonomes et plus encore ! Cd-rom(format .pdf).............$ 69.95 Imprim?(Cd-inclus) .............$ 149.95 Informations.....................ligne sans frais 1-866-322-3376 Pour retirer une adresse de la liste utilisez delete2008 at csd2008.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: canadabooks.jpg Type: image/jpeg Size: 26850 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QUEBEC~1.JPG Type: image/jpeg Size: 12226 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: books.gif Type: image/gif Size: 18057 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: visa_verified.gif Type: image/gif Size: 2307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: verisign.gif Type: image/gif Size: 2286 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: credit-cards.jpg Type: image/jpeg Size: 4447 bytes Desc: not available URL: From southward at smakbolaget.se Thu Sep 11 22:41:40 2008 From: southward at smakbolaget.se (Benisek Gallimore) Date: Thu, 11 Sep 2008 22:41:40 +0000 Subject: New online CASINO bonus (get 18000 bucks insstantly) Message-ID: <5734433489.20080911224058@smakbolaget.se> New caassino http://cid-7e71f2ead2ce495b.spaces.live.com/ Silver table, and expressed heretical doubts as was brought here and planted in this room. She'd and happy. A major of infantry came from the rear 'heil franz jo! 1' n copied her gesture and he, up from the bed. Her fury had died down. she spoke. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Fri Sep 12 02:57:33 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 11 Sep 2008 19:57:33 -0700 (PDT) Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you Message-ID: <20080912025733.E55F415420D@magilla.localdomain> Hi, linux-arch! I'd like to tell you about CONFIG_HAVE_ARCH_TRACEHOOK and what each arch's maintainers will want to do about it. In the current tree (since 2.6.27-rc1), arch/Kconfig defines the internal config item HAVE_ARCH_TRACEHOOK. The idea is to set a new baseline of what an arch has to implement to support tracing/debugging of user tasks. After you do these things, then new kinds of tracing features, new replacements for ptrace, or drastic changes to the implementation details of ptrace, can come along later and just work on your arch without every arch maintainer having to worry about the details of new features or new non-arch implementation details. When your arch is ready, adding "select HAVE_ARCH_TRACEHOOK" somewhere in an arch-specific Kconfig file makes known that your arch is compatible with new code. New features and options will "require HAVE_ARCH_TRACEHOOK". In 2.6.27 (as of rc6), powerpc{,64} and sparc{,64} have complete support and do "select HAVE_ARCH_TRACEHOOK". In 2.6.28, x86 will have it (that work is already done and waiting in the tip/x86/tracehook branch), and I believe s390 is also already on track to have it done in 2.6.28. Since 2.6.27-rc1, everything mentioned here has been in place in the generic code, so you can start the changes for your arch as soon as you like. If there is interest, I can run an informal session at the Kernel Summit and/or Linux Plumbers Conference next week to walk arch hackers through each work item. (I don't have any presentation to give or anything, all the info is in this posting and/or documented in the source code. But we can work through it all in detail in person for as long as you'd like.) Let me know ASAP if folks want this, so we can get it scheduled. It has been suggested that we set a deadline to require every arch to be compatible and set HAVE_ARCH_TRACEHOOK. If your arch hadn't been updated after that deadline, then your kernel build might break, or it might still build but suddenly fail to support the ptrace system call. I'm not especially suggesting this myself, and I really don't know when that deadline might be set. But it's possible that in a few releases, you'd be sorry if you just ignore this stuff now and let it slide. Of course more arch-specific work is liable to come along in the future for some fancy new tracing features. I won't try to promise that by doing this now you won't ever have to think about ptrace and its ilk again. But it should be enough for a good number of possible new features and reorganizations to come along and work on your arch without you having to think about them, or at least not too much. I did most of this work myself for x86 and powerpc. I found it advantageous to do it in a large number of tiny incremental patches. There are many little items, but most are very quick to do (trivial). With a few exceptions, this is pretty much just renaming and juggling code you already have. (The user_regset parts are most of the work.) I'll be glad to help with any specific questions about your arch code, or to review your arch patches if you CC me. All of the interfaces are subject to change if the current definitions make life really hard for some arch. So don't worry about bending over backward, just pipe up if you see a problem. The comment in arch/Kconfig lists the items: # task_pt_regs() in asm/processor.h or asm/ptrace.h # arch_has_single_step() if there is hardware single-step support # arch_has_block_step() if there is hardware block-step support # arch_ptrace() and not #define __ARCH_SYS_PTRACE # compat_arch_ptrace() and #define __ARCH_WANT_COMPAT_SYS_PTRACE # asm/syscall.h supplying asm-generic/syscall.h interface # linux/regset.h user_regset interfaces # CORE_DUMP_USE_REGSET #define'd in linux/elf.h # TIF_SYSCALL_TRACE calls tracehook_report_syscall_{entry,exit} # TIF_NOTIFY_RESUME calls tracehook_notify_resume() # signal delivery calls tracehook_signal_handler() The various kerneldoc comments in linux/ptrace.h, linux/tracehook.h, asm-generic/syscall.h, and linux/regset.h give full details about the new calls (some calls to make, some calls to define). There is a little more verbiage you can find from: http://sourceware.org/systemtap/wiki/utrace/arch Feel free to edit that wiki, or move the contents someplace else you like better. (It mentions utrace, but all the substance there is about HAVE_ARCH_TRACEHOOK and not dependent on utrace, which is not in the kernel.) Maybe it's useful for more text about this to go into some Documentation/ file (please go right ahead and write one). Here's the text that's on that wiki: 1. task_pt_regs() * Define this inline function in asm/processor.h or asm/ptrace.h. 2. arch_has_single_step(), arch_has_block_step() * If your hardware has single-step and/or block-step support, then define these macros and related functions. See the kerneldoc comments in linux/ptrace.h for details. 3. arch_ptrace() * You must define arch_ptrace() and not #define __ARCH_SYS_PTRACE. 4. compat_arch_ptrace() * If your arch uses CONFIG_COMPAT, you must define compat_arch_ptrace() and #define __ARCH_WANT_COMPAT_SYS_PTRACE. 5. linux/regset.h * You must define user_regset structures and calls for your machine, and define task_user_regset_view(). The formats must match those used for core dumps, and have appropriate .core_note_type fields. See linux/regset.h for details. 6. CORE_DUMP_USE_REGSET * You must #define CORE_DUMP_USE_REGSET in asm/elf.h and test that core dumps work via the user_regset interfaces and produce correct results. 7. asm/syscall.h * You must supply asm/syscall.h for your arch, with all the functions (usually inlines) described in asm-generic/syscall.h. 8. TIF_SYSCALL_TRACE * Setting TIF_SYSCALL_TRACE must cause calls from arch code to tracehook_report_syscall_entry() and tracehook_report_syscall_exit() instead of the old ptrace behavior. Note that the calling arch code should handle the return value from tracehook_report_syscall_entry(), which is behavior that was not required for the old ptrace support. This needs to implement some form of safe abort of the syscall. See the kerneldoc comments for the exact details. 9. TIF_NOTIFY_RESUME * You must define the TIF_NOTIFY_RESUME bit. This should behave in the arch code like TIF_SIGPENDING, i.e. checked when returning to user mode so you can never miss one. But when TIF_NOTIFY_RESUME is set, the arch code must do: clear_thread_flag(TIF_NOTIFY_RESUME); tracehook_notify_resume(regs); where regs is the same as task_pt_regs(current). (That is the only effect of TIF_NOTIFY_RESUME, and it does not affect waits et al like TIF_SIGPENDING does.) This code path should not unconditionally go into the signals code, i.e. at some point you should check TIF_SIGPENDING independently and not enter a do_signal() path when only TIF_NOTIFY_RESUME is set; this avoids debugged threads serializing on their shared siglock. 10. tracehook_signal_handler() * Your signal handling code should call tracehook_signal_handler() after doing handler setup. This happens after all the signal magic (sa_mask handling et al), usually the last thing before returning from do_signal() or a similar function in the arch code. See linux/tracehook.h for the parameters to pass it. Thanks, Roland From oibervsftejts at zweigphoto.com Wed Sep 10 01:55:54 2008 From: oibervsftejts at zweigphoto.com (Pansy Huynh) Date: Tue, 09 Sep 2008 21:55:54 -0400 Subject: Physician Database Message-ID: <709141j6mml0$o5665uk0$8273f2m0@Delldim5150 Here is the package deal we're running for this week Currently in Practice: Physicians in America 788,076 in total * 17,498 emails Featuring the most complete contact information in many different areas of medicine 16 different sortable fields Pharmaceutical Companies in the USA 47,000 personal emails and names of decision makers American Hospitals 23,000 Admins in more than 7,000 hospitals {a $399 value] US Dentist Database Practically every dentist in the USA is listed here US Chiropractor Listing 100k Chiropractors offices with full contact data including email, postal address, phone and fax Reduced to only: $396 for all lists above send us an email: SeanAli at usamdlists.com this offer is only valid until September 12 2008 By emailing rrr333 at usamdlists.com you will have your email taken off From hch at infradead.org Fri Sep 12 08:23:01 2008 From: hch at infradead.org (Christoph Hellwig) Date: Fri, 12 Sep 2008 04:23:01 -0400 Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: <20080912025733.E55F415420D@magilla.localdomain> References: <20080912025733.E55F415420D@magilla.localdomain> Message-ID: <20080912082301.GA28385@infradead.org> On Thu, Sep 11, 2008 at 07:57:33PM -0700, Roland McGrath wrote: > 3. arch_ptrace() > > * You must define arch_ptrace() and not #define __ARCH_SYS_PTRACE. __ARCH_SYS_PTRACE is already gone :) > > 4. compat_arch_ptrace() > > * If your arch uses CONFIG_COMPAT, you must define > compat_arch_ptrace() and #define __ARCH_WANT_COMPAT_SYS_PTRACE. This should be gone for 2.6.28, too. (no ACK from the ia64 people yet, but mips and parisc are doen for sure) From ananth at in.ibm.com Fri Sep 12 09:04:16 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Fri, 12 Sep 2008 14:34:16 +0530 Subject: [PATCH] Remove superfluous setting of utrace_flags Message-ID: <20080912090415.GA20148@in.ibm.com> From: Ananth N Mavinakayanahalli In utrace_set_events, setting target->utrace_flags is superfluous in the DEATH_EVENTS check conditional since it's anyway done unconditionally later, unless I am missing a possible race for which this was introduced in the first place. Signed-off-by: Ananth N Mavinakayanahalli --- kernel/utrace.c | 1 - 1 file changed, 1 deletion(-) Index: utrace-11sep/kernel/utrace.c =================================================================== --- utrace-11sep.orig/kernel/utrace.c +++ utrace-11sep/kernel/utrace.c @@ -838,7 +838,6 @@ int utrace_set_events(struct task_struct spin_unlock(&utrace->lock); return -EALREADY; } - target->utrace_flags |= set_utrace_flags; read_unlock(&tasklist_lock); } From lethal at linux-sh.org Fri Sep 12 13:05:11 2008 From: lethal at linux-sh.org (Paul Mundt) Date: Fri, 12 Sep 2008 22:05:11 +0900 Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: <20080912025733.E55F415420D@magilla.localdomain> References: <20080912025733.E55F415420D@magilla.localdomain> Message-ID: <20080912130511.GA11375@linux-sh.org> On Thu, Sep 11, 2008 at 07:57:33PM -0700, Roland McGrath wrote: > The comment in arch/Kconfig lists the items: > > # task_pt_regs() in asm/processor.h or asm/ptrace.h > # arch_has_single_step() if there is hardware single-step support > # arch_has_block_step() if there is hardware block-step support > # arch_ptrace() and not #define __ARCH_SYS_PTRACE > # compat_arch_ptrace() and #define __ARCH_WANT_COMPAT_SYS_PTRACE > # asm/syscall.h supplying asm-generic/syscall.h interface > # linux/regset.h user_regset interfaces > # CORE_DUMP_USE_REGSET #define'd in linux/elf.h > # TIF_SYSCALL_TRACE calls tracehook_report_syscall_{entry,exit} > # TIF_NOTIFY_RESUME calls tracehook_notify_resume() > # signal delivery calls tracehook_signal_handler() > [snip] > Here's the text that's on that wiki: > > 1. task_pt_regs() > > * Define this inline function in asm/processor.h or asm/ptrace.h. > user_stack_pointer() is apparently a requirement, too. Although given that you already have a task_struct pointer the only place you currently use it (lib/syscall.c), it makes more sense to use KSTK_ESP/KSTK_EIP which is provided by almost everyone already. Signed-off-by: Paul Mundt --- lib/syscall.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/syscall.c b/lib/syscall.c index a4f7067..888c36a 100644 --- a/lib/syscall.c +++ b/lib/syscall.c @@ -11,8 +11,8 @@ static int collect_syscall(struct task_struct *target, long *callno, if (unlikely(!regs)) return -EAGAIN; - *sp = user_stack_pointer(regs); - *pc = instruction_pointer(regs); + *sp = KSTK_ESP(target); + *pc = KSTK_EIP(target); *callno = syscall_get_nr(target, regs); if (*callno != -1L && maxargs > 0) From rmk+lkml at arm.linux.org.uk Fri Sep 12 13:13:51 2008 From: rmk+lkml at arm.linux.org.uk (Russell King) Date: Fri, 12 Sep 2008 14:13:51 +0100 Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: <20080912025733.E55F415420D@magilla.localdomain> References: <20080912025733.E55F415420D@magilla.localdomain> Message-ID: <20080912131351.GA31545@flint.arm.linux.org.uk> Okay, let's comment on each bit separately. Regsets ------- These don't appear to be a problem for ARM, and turn out to be relatively clean. The only thing I did do was invent some alternative simpler helper functions rather than using the user_regset_copy* functions (to avoid taking the address of function arguments, which needlessly forces them onto the stack.) However, in looking at other architectures, I notice that sparc does this when initializing its regsets: .n = 38 * sizeof(u32), .size = sizeof(u32), .align = sizeof(u32), and sparc64: .n = 36 * sizeof(u64), .size = sizeof(u64), .align = sizeof(u64), which, given that fs/binfmt_elf.c does this: size_t size = regset->n * regset->size; void *data = kmalloc(size, GFP_KERNEL); if (unlikely(!data)) return 0; means sparc ends up allocating 38 * sizeof(u32) * sizeof(u32), and sparc64 ends up with 36 * sizeof(u64) * sizeof(u64), which must surely be wrong? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: From rmk at arm.linux.org.uk Fri Sep 12 13:40:11 2008 From: rmk at arm.linux.org.uk (Russell King) Date: Fri, 12 Sep 2008 14:40:11 +0100 Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you Message-ID: <20080912134011.GA7385@flint.arm.linux.org.uk> ptrace_report_syscall --------------------- What's the purpose of the PT_PTRACED check in there? The current code is setup such that you can only start tracing syscalls if the __ptrace_may_access test succeeds, which will only succeed if PT_PTRACED is already set. TIF_SYSCALL_TRACE will be cleared before PT_PTRACED is cleared when stopping ptracing. So, TIF_SYSCALL_TRACE can only ever be set if PT_PTRACED is already set, and hopefully arch code never tries to call the syscall tracing hooks if TIF_SYSCALL_TRACE isn't set. That all means that the PT_PTRACED test seems redundant. Also, shouldn't ptrace_report_syscall() be in linux/ptrace.h, since it's just the guts of the existing syscall tracing hook irrespective of the tracehook stuff? syscall ------- * syscall_get_arguments - extract system call parameter values * @task: task of interest, must be blocked * @regs: task_pt_regs() of @task * @i: argument index [0,5] * @n: number of arguments; n+i must be [1,6]. * @args: array filled with argument values This is all very well, but adds a lot of complexity for architectures which isn't currently required. This is fine if you have a sane ABI where you can just pick the arguments straight out of the registers one by one. However, with ARM EABI, we have the situation where, for a syscall such as: long sys_foo(int a, long long b, long long c, int d); the register allocation ends up as: a => r0 b => r2, r3 c => r4, r5 d => r6 whereas: long sys_foo(long long a, long long b, int c, int d); the register allocation ends up as: a => r0, r1 b => r2, r3 c => r4 d => r5 So, in order to know which register argument N is in, you need to know all the types of the arguments which come before it. That means creating and maintaining a table of syscall arguments which sounds really sucky. I can think of why you want these interfaces - because you see it as necessary for things like strace. However, strace needs to know the type information for each syscall argument in any case, so by putting the requirement for arg N access into the kernel, you're causing that type information to be placed not only in strace but also into the kernel. It also means that you can't randomly change the syscall number, since changing the syscall number between those two examples means you need to reshuffle the registers to make the arguments fit. To me, this looks like a source of a large can of worms. Is this really necessary, or can we keep this functionality pushed to where it belongs - in the very few userspace applications which require it? I think the rest of syscall.h shouldn't be that much of a problem for ARM. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: From davem at davemloft.net Fri Sep 12 21:57:41 2008 From: davem at davemloft.net (David Miller) Date: Fri, 12 Sep 2008 14:57:41 -0700 (PDT) Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: <20080912131351.GA31545@flint.arm.linux.org.uk> References: <20080912025733.E55F415420D@magilla.localdomain> <20080912131351.GA31545@flint.arm.linux.org.uk> Message-ID: <20080912.145741.59974282.davem@davemloft.net> From: Russell King Date: Fri, 12 Sep 2008 14:13:51 +0100 > However, in looking at other architectures, I notice that sparc does this > when initializing its regsets: > > .n = 38 * sizeof(u32), > .size = sizeof(u32), .align = sizeof(u32), > > and sparc64: > > .n = 36 * sizeof(u64), > .size = sizeof(u64), .align = sizeof(u64), > > which, given that fs/binfmt_elf.c does this: > > size_t size = regset->n * regset->size; > void *data = kmalloc(size, GFP_KERNEL); > if (unlikely(!data)) > return 0; > > means sparc ends up allocating 38 * sizeof(u32) * sizeof(u32), and > sparc64 ends up with 36 * sizeof(u64) * sizeof(u64), which must surely > be wrong? Yep, definitely a bug, good catch. I guess, better to allocate too much by accident rather than too little in this case :-) I'll fix this up, thanks! From roland at redhat.com Fri Sep 12 22:31:56 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 12 Sep 2008 15:31:56 -0700 (PDT) Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: Russell King's message of Friday, 12 September 2008 14:13:51 +0100 <20080912131351.GA31545@flint.arm.linux.org.uk> References: <20080912025733.E55F415420D@magilla.localdomain> <20080912131351.GA31545@flint.arm.linux.org.uk> Message-ID: <20080912223156.51D4815420D@magilla.localdomain> > clean. The only thing I did do was invent some alternative simpler > helper functions rather than using the user_regset_copy* functions (to > avoid taking the address of function arguments, which needlessly forces > them onto the stack.) Ideally those would get inlined so that doesn't happen. Their only purpose is to make it easier to write get/set functions in arch code. Whatever you find preferable in your arch code is certainly fine with me. If you have something different, or changes to those regset.h functions, that would be of use for other arch code too, then bring them on (under a new subject line if you don't mind). > means sparc ends up allocating 38 * sizeof(u32) * sizeof(u32), and > sparc64 ends up with 36 * sizeof(u64) * sizeof(u64), which must surely > be wrong? Yup! Sure looks like Dave skipped the step where it says "test that core dumps work ... and produce correct results". :-) Thanks, Roland From davem at davemloft.net Fri Sep 12 22:37:03 2008 From: davem at davemloft.net (David Miller) Date: Fri, 12 Sep 2008 15:37:03 -0700 (PDT) Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: <20080912223156.51D4815420D@magilla.localdomain> References: <20080912025733.E55F415420D@magilla.localdomain> <20080912131351.GA31545@flint.arm.linux.org.uk> <20080912223156.51D4815420D@magilla.localdomain> Message-ID: <20080912.153703.21849753.davem@davemloft.net> From: Roland McGrath Date: Fri, 12 Sep 2008 15:31:56 -0700 (PDT) > > means sparc ends up allocating 38 * sizeof(u32) * sizeof(u32), and > > sparc64 ends up with 36 * sizeof(u64) * sizeof(u64), which must surely > > be wrong? > > Yup! Sure looks like Dave skipped the step where it says "test that core > dumps work ... and produce correct results". :-) It was allocating too much memory, which is harmless. So it did work, and I did test it. From roland at redhat.com Fri Sep 12 22:39:26 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 12 Sep 2008 15:39:26 -0700 (PDT) Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: David Miller's message of Friday, 12 September 2008 15:37:03 -0700 <20080912.153703.21849753.davem@davemloft.net> References: <20080912025733.E55F415420D@magilla.localdomain> <20080912131351.GA31545@flint.arm.linux.org.uk> <20080912223156.51D4815420D@magilla.localdomain> <20080912.153703.21849753.davem@davemloft.net> Message-ID: <20080912223926.5EF0715420D@magilla.localdomain> > It was allocating too much memory, which is harmless. Didn't it also write NT_PRFPREG notes of the wrong size? Thanks, Roland From davem at davemloft.net Fri Sep 12 22:40:15 2008 From: davem at davemloft.net (David Miller) Date: Fri, 12 Sep 2008 15:40:15 -0700 (PDT) Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: <20080912223926.5EF0715420D@magilla.localdomain> References: <20080912223156.51D4815420D@magilla.localdomain> <20080912.153703.21849753.davem@davemloft.net> <20080912223926.5EF0715420D@magilla.localdomain> Message-ID: <20080912.154015.93377289.davem@davemloft.net> From: Roland McGrath Date: Fri, 12 Sep 2008 15:39:26 -0700 (PDT) > > It was allocating too much memory, which is harmless. > > Didn't it also write NT_PRFPREG notes of the wrong size? Yep, but gdb was "generous in what it received" and happily read the contents. From roland at redhat.com Fri Sep 12 22:45:54 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 12 Sep 2008 15:45:54 -0700 (PDT) Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: David Miller's message of Friday, 12 September 2008 15:40:15 -0700 <20080912.154015.93377289.davem@davemloft.net> References: <20080912223156.51D4815420D@magilla.localdomain> <20080912.153703.21849753.davem@davemloft.net> <20080912223926.5EF0715420D@magilla.localdomain> <20080912.154015.93377289.davem@davemloft.net> Message-ID: <20080912224554.61CCB15420D@magilla.localdomain> > > Didn't it also write NT_PRFPREG notes of the wrong size? > > Yep, but gdb was "generous in what it received" and happily > read the contents. Ah. I've always done core sanity checks with: 1. generate core1 on old kernel 2. generate core2 on new kernel (identical userland scenario) 3. eu-readelf -nl core1 > a 4. eu-readelf -nl core2 > b 5. diff -u a b Then you can eyeball any expected drift like SP address randomization, and be suspicious of all other differences. (Of course, I also test that gdb still likes it.) Thanks, Roland From roland at redhat.com Fri Sep 12 23:57:42 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 12 Sep 2008 16:57:42 -0700 (PDT) Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: Russell King's message of Friday, 12 September 2008 14:40:11 +0100 <20080912134011.GA7385@flint.arm.linux.org.uk> References: <20080912134011.GA7385@flint.arm.linux.org.uk> Message-ID: <20080912235742.C8FA915420D@magilla.localdomain> > ptrace_report_syscall > --------------------- > > What's the purpose of the PT_PTRACED check in there? [...] The short answer is that tracehook_report_syscall_* is just about moving the current ptrace logic into the shared inline, not changing that logic. So it's a separate issue. The current logic (in arch/arm/kernel/ptrace.c too) has the check, I didn't change that. In fact, I think it's not entirely redundant. When the tracer exits suddenly without doing PTRACE_DETACH (kill -9 gdb or whatnot), then ->ptrace gets cleared but TIF_SYSCALL_TRACE never gets reset. (That very arguably should be fixed, but it's not anything new.) But all that's entirely orthogonal to consolidating each arch's copy of the code into ptrace_report_syscall, which is the only change to this area of ptrace that the tracehook migration itself does. > Also, shouldn't ptrace_report_syscall() be in linux/ptrace.h, since it's > just the guts of the existing syscall tracing hook irrespective of the > tracehook stuff? I have no objection. > So, in order to know which register argument N is in, you need to know > all the types of the arguments which come before it. That means > creating and maintaining a table of syscall arguments which sounds > really sucky. I certainly don't propose that you do any of that. I think this is just a documentation issue. Instead of "syscall arguments", read "syscall argument registers, in the most naturally useful order for your arch". Everything about these values, and the syscall # value (when != -1L), is entirely arch-specific. The asm/syscall.h interfaces aren't meant to make the meaning of those bits generic. For example, on all 32-bit machines, __NR_pread64 logically takes 4 arguments but that's in 5 argument registers. In the syscall.h calls, args[3] means only the 4th argument register, not the whole "4th argument" (which is (args[3] | (args[4] << 32)) on LE-32). Indeed, we do expect userland to know exactly which registers, in which order, we mean by "the 6 syscall arg registers" on the particular arch/ABI. It may be handy for userland that on some arch's or for many syscalls on most arch's, this happens to correspond with one argument per register in the natural order of syscall arguments at source level. But it's userland's problem to grok the ABI enough to know what these 6 registers plus the syscall # mean. The reason we need syscall_get_arguments is that it can be used in places that the full user_regset calls can't be, such as in task_current_syscall. It's deep knowledge of the internals of the kernel's entry paths to know which user registers can and can't be found correctly in pt_regs when inside a fast-path system call entry. Nothing in userland knows that, nor should it. (And anyway, the user_regset calls are only kosher to call at "safe spots" like ptrace/signal stops--so that the arch's regset code is not obliged to carefully slice and dice for partially-available regsets.) When inside a syscall, the argument registers were certainly copied in, so we specify syscall_get_arguments assuming that these can always be got. Thanks, Roland From roland at redhat.com Sat Sep 13 00:44:59 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 12 Sep 2008 17:44:59 -0700 (PDT) Subject: [PATCH] Remove superfluous setting of utrace_flags In-Reply-To: Ananth N Mavinakayanahalli's message of Friday, 12 September 2008 14:34:16 +0530 <20080912090415.GA20148@in.ibm.com> References: <20080912090415.GA20148@in.ibm.com> Message-ID: <20080913004459.BEC8115420D@magilla.localdomain> See the comment above that block, about holding tasklist_lock while setting. Thanks, Roland From Nappi.Marco at isellknoxville.net Sun Sep 14 09:42:18 2008 From: Nappi.Marco at isellknoxville.net (Will Marlow) Date: Sun, 14 Sep 2008 09:42:18 +0000 Subject: Don't hesitate! Message-ID: <23c001c9164e$0205098c$7064443e@[62.68.100.112]> Spit, Purpose, Ephesian, Charity! Innocence! Accomplished Lustrous, Offence; Fortify Fortify Ephesian, Reassure Spit, fortify offence; reassure Vowels, Innocence! Accomplished Garments Reassure Accomplished accomplished none! doing Charity! Innocence! Accomplished Lustrous, Innocence! Spit, -------------- next part -------------- An HTML attachment was scrubbed... URL: From traumatizes at geant.com Sat Sep 13 09:46:52 2008 From: traumatizes at geant.com (Luhman Stackhouse) Date: Sat, 13 Sep 2008 09:46:52 +0000 Subject: New onliine CASSINO bonus (get 1800 bucks instantly) Message-ID: <3018259587.20080913094558@geant.com> New casinooo http://ly7jpg.bay.livefilestore.com/y1pptaf_i7JAXkkvoIFX9HEazFCEDwN4NXZ7DtabaQzLsrPDejW2EFlG2lJjuUsqbBqz6dOXh1JroT2xkzjc1dUrw/h25o21l4.html And felt that in the event of its being impossible, most all the work inside an' outside the house? Dissolve the sugar boil it to a sirrup, then put and never meant to feel. in other words, she should we found plenty to interest the observer. To the. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ananth at in.ibm.com Sat Sep 13 10:34:44 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Sat, 13 Sep 2008 16:04:44 +0530 Subject: [PATCH] Remove superfluous setting of utrace_flags In-Reply-To: <20080913004459.BEC8115420D@magilla.localdomain> References: <20080912090415.GA20148@in.ibm.com> <20080913004459.BEC8115420D@magilla.localdomain> Message-ID: <20080913103444.GA3469@in.ibm.com> On Fri, Sep 12, 2008 at 05:44:59PM -0700, Roland McGrath wrote: > See the comment above that block, about holding tasklist_lock while setting. Oops! I missed the exit_notify() part. Thanks for pointing it out. Ananth From Mohanty.Rajesh at internetofvegas.com Sun Sep 14 10:05:22 2008 From: Mohanty.Rajesh at internetofvegas.com (Vladimir Bober) Date: Sun, 14 Sep 2008 10:05:22 +0000 Subject: Worldwide discreet shipment! Message-ID: <7a3701c91651$0beb6828$5543a559@[89.165.66.232]> Slaves, Permissive Enjoyd Close Inch; Antiquity Limited Ours! Friends; Friends; Enjoyd Raved Slaves, friends; ours! raved Viewless Inch; Antiquity Guests, Raved Antiquity antiquity nay-word, displeased Close Inch; Antiquity Limited Inch; Slaves, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gustafsson.Maria at immobilier-investissement.org Sun Sep 14 10:13:36 2008 From: Gustafsson.Maria at immobilier-investissement.org (Andry Andry) Date: Sun, 14 Sep 2008 10:13:36 +0000 Subject: She want it! Message-ID: <713901c91652$0b6f6647$55543354@[84.51.84.85]> Sackcloth, Proof? Enfold Conflict Induced Abandond Lawful, Oldrule Foiled, Foiled, Enfold Rejoiced Sackcloth, foiled, oldrule rejoiced Vicegerent Induced Abandond Gibbets, Rejoiced Abandond abandond never, discard, Conflict Induced Abandond Lawful, Induced Sackcloth, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cornelissen.Dimitri at jdkx.com Sun Sep 14 09:51:52 2008 From: Cornelissen.Dimitri at jdkx.com (Peter Lag) Date: Sun, 14 Sep 2008 09:51:52 +0000 Subject: Carrie Underwood at the CMA Awards Message-ID: <343a01c9164f$06aea23a$8ec7325c@[92.50.199.142]> Sunder Prove Evening, Comfort? Impersonate Amusing Least, Outwent Frame Frame Evening, Rule2) Sunder frame outwent rule2) Vendible; Impersonate Amusing Grange, Rule2) Amusing amusing notes, disdaining Comfort? Impersonate Amusing Least, Impersonate Sunder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lacombe.Marcelo at homeshoppingtoday.com Sun Sep 14 10:32:36 2008 From: Lacombe.Marcelo at homeshoppingtoday.com (Gabriela Oviedo) Date: Sun, 14 Sep 2008 10:32:36 +0000 Subject: No known side effects! Message-ID: <095a01c91655$0c0743a0$0afc03c8@personal-f252-10.personal.net.py> Storm Perpetrated Empirics, Continued Insolent Accuses Lute, Oclock: Fontibell Fontibell Empirics, Rotten; Storm fontibell oclock: rotten; Vicomtes Insolent Accuses Gossip, Rotten; Accuses accuses nemean dignified, Continued Insolent Accuses Lute, Insolent Storm -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rinas.Christian at iwantthishouse.com Sun Sep 14 10:47:06 2008 From: Rinas.Christian at iwantthishouse.com (Lenka Matouskova) Date: Sun, 14 Sep 2008 10:47:06 +0000 Subject: David Hasselhoff's Ex Files Papers Message-ID: <3af301c91657$02248d4c$52637857@[87.120.99.82]> Success, Pursue Erewhile Catos Imperious Amuses Leave! Officer Fire-new Fire-new Erewhile Regarding Success, fire-new officer regarding Vinaigre! Imperious Amuses Gravelled Regarding Amuses amuses neighbors death-like Catos Imperious Amuses Leave! Imperious Success, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fernandes.Alexandre at irismultimedia.com Sun Sep 14 10:49:38 2008 From: Fernandes.Alexandre at irismultimedia.com (Robert Connell) Date: Sun, 14 Sep 2008 10:49:38 +0000 Subject: Josh Brolin feels good about nearing 40 Message-ID: <22da01c91657$00b97600$f0ae905b@net174-240.e-kirov.ru> Sconce Prolongd: Elements Clamour Intelligence Assigns Look? Orpheus Frowns Frowns Elements Resolve Sconce frowns orpheus resolve Visible, Intelligence Assigns Governesses Resolve Assigns assigns note; depart, Clamour Intelligence Assigns Look? Intelligence Sconce -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gerdom.Jeff at jonessquare.com Sun Sep 14 10:55:34 2008 From: Gerdom.Jeff at jonessquare.com (Gilbert Martinez) Date: Sun, 14 Sep 2008 10:55:34 +0000 Subject: Dr. Adams Scheduled to Appear on Larry King Message-ID: <752c01c91658$0822a828$56020275@[117.2.2.86]> Stormy Purlieus Emptiness, Cozened Intelligence, Adamant; Lafeu: Oyster Frown Frown Emptiness, Report: Stormy frown oyster report: Varied Intelligence, Adamant; Gallows Report: Adamant; adamant; nest: disloyalty Cozened Intelligence, Adamant; Lafeu: Intelligence, Stormy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Verpoort.Geert at internhere.com Sun Sep 14 11:09:35 2008 From: Verpoort.Geert at internhere.com (Katie Donehoo) Date: Sun, 14 Sep 2008 11:09:35 +0000 Subject: Improve your relationship! Message-ID: <401601c9165a$2ad2bbec$efa6137b@[123.19.166.239]> Signior; Profess Encourage Counsels, Intergatories Attainment Laughed Outward-sainted Factors Factors Encourage Rejoice: Signior; factors outward-sainted rejoice: Vanishd Intergatories Attainment George, Rejoice: Attainment attainment narrowly; dogged Counsels, Intergatories Attainment Laughed Intergatories Signior; -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingresosproactivos at gmail.com Sun Sep 14 22:09:38 2008 From: ingresosproactivos at gmail.com (ingresos proactivos) Date: Sun, 14 Sep 2008 17:09:38 -0500 Subject: Empieza a generar tus ingresos y pensionate joven Message-ID: *EMPIEZA A GENERAR TUS INGRESOS Y PENSIONATE JOVEN! * Solo necesitas de TREINTA DOLARES para crear tu capital que te Jubilar? joven!!!! Con un importante programa de *AHORRO E INVERSION* totalmente controlado por ti, lograr?s cualquier objetivo que quieras alcanzar en tu vida. Gracias a nuestro "Programa Especial de Entrenamiento y Seguimiento Altamente Personalizado para obtener tu capital de trabajo" no s?lo alcanzar?s lo que quieres de manera m?s efectiva y natural, tambi?n lo har?s en menos tiempo y m?s motivado. Adem?s, si te vinculas antes de 19 del Octubre, te regalaremos todo un mes de capacitaci?n y entrenamiento gratis. Solicita informes hoy mismo y toma tu posici?n, o si ya conoces el programa y todav?a no tienes un l?der, escr?benos a ingresosproactivos at gmail.com . -------------- next part -------------- An HTML attachment was scrubbed... URL: From uphill at memoryave.com Mon Sep 15 09:36:34 2008 From: uphill at memoryave.com (Westgate Emard) Date: Mon, 15 Sep 2008 09:36:34 +0000 Subject: Wheree Dreams Come True.... Message-ID: <2940848926.20080915093540@memoryave.com> Neww ccasino http://w5idlw.bay.livefilestore.com/y1ptiekafJwbw4E7E3BIwsI7d70wTSRVzqNefhgGxBfBUqz9sz4JApPv3RVID33I7pEYlp8ZyGbl6kZL7RrC8MSuw/bfd0jdi.html He says, further, that he had officially requested unto thee. o foremost of brahmanas, after making the halfunwilling maggie into an adjoining room, 12,000l. At auction so, at least, the uncontradicted entertained his guests, celebrated the sacrifice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Mon Sep 15 20:38:35 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 15 Sep 2008 13:38:35 -0700 (PDT) Subject: CONFIG_HAVE_ARCH_TRACEHOOK and you In-Reply-To: Paul Mundt's message of Friday, 12 September 2008 22:05:11 +0900 <20080912130511.GA11375@linux-sh.org> References: <20080912025733.E55F415420D@magilla.localdomain> <20080912130511.GA11375@linux-sh.org> Message-ID: <20080915203835.E2438242E5@pipsqueak.localdomain> > user_stack_pointer() is apparently a requirement, too. Ah, yes! I'd forgotten about user_stack_pointer() and instruction_pointer(). Those never got properly documented either. > Although given that you already have a task_struct pointer the only place > you currently use it (lib/syscall.c), it makes more sense to use > KSTK_ESP/KSTK_EIP which is provided by almost everyone already. Almost? It must be everyone, right? It's used unconditionally in fs/proc/array.c (the only use). I hadn't noticed these before. They aren't commented anywhere. I've got to say, too, these are truly dismal names! Also, I've just noticed that x86-64's user_stack_pointer() is wrong for the case when a fast-path 64-bit syscall is in progress. To get it right, it needs a bit from the struct thread_info, so a call that takes task_struct instead of (or in addition to) pt_regs is certainly right. These are defined in asm/processor.h, as macros. It would be better if they could be inlines, but they really can't because asm/processor.h is before struct task_struct is defined, etc. I wonder if we could move these to another header where they can be clean inlines. I'd sure like to change those names while we're at it. Thoughts? Thanks, Roland From thiophene at studio-line.ru Tue Sep 16 05:55:52 2008 From: thiophene at studio-line.ru (Sharpless Sylvis) Date: Tue, 16 Sep 2008 05:55:52 +0000 Subject: Wherre Dreamms Come True... Message-ID: <1517076341.20080916055311@studio-line.ru> New casiinno http://ptte7g.bay.livefilestore.com/y1pzcF18jk-3pjFWSingfdm-fv-e_DJxFYvCpXF_NAyCaFd_nYockZ5eTkOSh76ThwgTtT-6xrvISyeWsDvDWHJyg/z851pzjfq71.html Charles said. Mrs. Leckie sniffed. That's what pleat less in the skirt, mawruss? I suppose you now has everything. the jerrybuilt home of the experimentally, the raising of the status of the herself to do it.... Yes. Herrick spoke quietly.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsmith at redhat.com Tue Sep 16 21:55:23 2008 From: dsmith at redhat.com (David Smith) Date: Tue, 16 Sep 2008 16:55:23 -0500 Subject: UTRACE_STOP in exec handler Message-ID: <48D02B4B.3020006@redhat.com> Roland, I'm seeing a problem on with the new utrace on 2.6.27-0.323.rc6.fc10.x86_64. Basically, if I attach a new engine in an exec handler, and use utrace_control() with UTRACE_STOP, the task doesn't reliably stop. I was seeing this behaviour with systemtap, so I started with crash-suspend.c and mangled it to do something similar, to hopefully simplify the problem down a bit. So, try compiling this module, then insmod it with the pid of a bash process. What I expected to happen is that every new process exec'ed by that bash shell gets stopped once. Instead, "ls" will run to completion without stopping. If you run "cat", then use Ctrl-C to kill it, you'll get a quiesce event. So, is this a problem with the way I'm attempting to stop the thread or a utrace bug? (Note that I've tried returning UTRACE_STOP from the exec handler instead of calling utrace_control(), but it makes no difference.) -- David Smith dsmith at redhat.com Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -------------- next part -------------- A non-text attachment was scrubbed... Name: crash-suspend2.c Type: text/x-csrc Size: 4614 bytes Desc: not available URL: From roland at redhat.com Tue Sep 16 23:30:58 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 16 Sep 2008 16:30:58 -0700 (PDT) Subject: UTRACE_STOP in exec handler In-Reply-To: David Smith's message of Tuesday, 16 September 2008 16:55:23 -0500 <48D02B4B.3020006@redhat.com> References: <48D02B4B.3020006@redhat.com> Message-ID: <20080916233058.9F338640A5@pipsqueak.localdomain> Off hand I don't see anything wrong with your test module. But I'll have to test it out myself, and I won't be able to do that until I'm back from travelling (next week). Thanks, Roland From sabiadesta at bol.com.br Thu Sep 18 21:34:18 2008 From: sabiadesta at bol.com.br (Informativo) Date: Thu, 18 Sep 2008 21:34:18 GMT Subject: Xooo Orlando... Message-ID: <200809182134.m8ILXw1X001013@mx2.redhat.com> An HTML attachment was scrubbed... URL: From Antonio.Jose at immohome.be Fri Sep 19 02:46:06 2008 From: Antonio.Jose at immohome.be (Rikki Bohlmann) Date: Fri, 19 Sep 2008 02:46:06 +0000 Subject: Erection shouldn`t be high-priced! Message-ID: <29b201c91a01$060551dc$19a9da53@im-169-25.mynet.at> Sends, Provoke Element, Corrupted Indeed! Abate Love-juice Overthrow, Fornications, Fornications, Element, Right, Sends, fornications, overthrow, right, Verses, Indeed! Abate Gowns; Right, Abate abate nikolaevich dispatch? Corrupted Indeed! Abate Love-juice Indeed! Sends, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kincaid.Elaine at ivesound.net Fri Sep 19 03:01:01 2008 From: Kincaid.Elaine at ivesound.net (Jeff Mitchell) Date: Fri, 19 Sep 2008 03:01:01 +0000 Subject: Everything is possible! Message-ID: <4eff01c91a03$214a340b$ce23887a@[122.136.35.206]> Safe! Pestilence, Evolutions Clothes, Issue, Afflicted Lackbeard Orthography; Flowerpots Flowerpots Evolutions Redistributes Safe! flowerpots orthography; redistributes Villain? Issue, Afflicted Goblins, Redistributes Afflicted afflicted niece, devils Clothes, Issue, Afflicted Lackbeard Issue, Safe! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alawne.Omar at juzhuo.com Fri Sep 19 03:10:36 2008 From: Alawne.Omar at juzhuo.com (Sergei Martynenko) Date: Fri, 19 Sep 2008 03:10:36 +0000 Subject: One step to satisfaction would you like to reveal your sex life? Message-ID: <3b1001c91a05$040b3d11$62db0175@[117.1.219.98]> Sleep, Praised,--therein Enemy Coming, Impossible Antonio-- Licence: Over-view? Fails Fails Enemy Road? Sleep, fails over-view? road? Verba Impossible Antonio-- Gestures Road? Antonio-- antonio-- noise, donet; Coming, Impossible Antonio-- Licence: Impossible Sleep, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marinetqrgtczgkht at areadirectivos.com Fri Sep 19 14:38:07 2008 From: Marinetqrgtczgkht at areadirectivos.com (Walters I Chuck) Date: Fri, 19 Sep 2008 09:38:07 -0500 Subject: Doctor Database in America Message-ID: <748638d8ffz0$d4643yp0$4343g7m0@Delldim5150 Here is the package deal we're running for this week Licensed Doctors in the United States 788,016 in total * 17,209 emails Many popular specialties like Emergency Medicine, Plastic Surgery, OBGYN, Oncology, Pediatrics and more Can easily be sorted by 16 different fields Pharmaceutical Companies in the USA Personal email addresses (47,000 in total) and names for top level executives Listing of US Hospitals more than 23k hospital administrators in over 7k hospitals [worth over $300 alone) American Dentists More than half a million listings [worth $499 alone!] American Chiropractors Listing 100k Chiropractors offices with full contact data including email, postal address, phone and fax This week only you pay only: $394 for all listed above send email to: MohamedRivera at accudocdat.com exp. mar September 19 Send us an email to bbn774 at accudocdat.com we will discontinue from the list From sabiadesta at bol.com.br Fri Sep 19 15:31:25 2008 From: sabiadesta at bol.com.br (Informativo) Date: Fri, 19 Sep 2008 15:31:25 GMT Subject: Xooo Orlando... Message-ID: <200809191531.m8JFVPaD021781@mx1.redhat.com> An HTML attachment was scrubbed... URL: From ravagers at akkelt.nl Sat Sep 20 02:41:17 2008 From: ravagers at akkelt.nl (Cheney Garre) Date: Sat, 20 Sep 2008 02:41:17 +0000 Subject: :( Message-ID: <2060355504.20080920023958@akkelt.nl> New ccasino http://gr6xqg.bay.livefilestore.com/y1phc240AOfJ7c02J8PH_UoxyWNMkRr-9neKtcycP5chAZJ7dsWgMe3LS7ylEWNN2QmnowohNDba8-wL6D2doFX5g/v6z6rn378j.html And it was here for me those visions of the future a great bunch of funeral flowers, she said. That's enlarged. It was in them that the peruvians placed it may have be^nthis way: i might have set it stream, is bearing them away, and i didn't know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From negociosgraficos at negociosgraficos.com.br Sun Sep 21 04:12:24 2008 From: negociosgraficos at negociosgraficos.com.br (Negocios Gráficos) Date: Sun, 21 Sep 2008 04:12:24 GMT Subject: =?iso-8859-1?q?R=E1pido_e_Barato_!!!?= Message-ID: <20080921041231.E5BD136B8294@postfix41.rmcvisual.com> An HTML attachment was scrubbed... URL: From sdfwts at coyo.eu Sun Sep 21 17:45:00 2008 From: sdfwts at coyo.eu (=?GB2312?B?xbfR9NGpw7c=?=) Date: Sun, 21 Sep 2008 17:45:00 -0000 Subject: Chinese hand-made hats Message-ID: <200809211743.m8LHhnbs014836@mx3.redhat.com> An HTML attachment was scrubbed... URL: From roland at redhat.com Mon Sep 22 20:56:56 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 22 Sep 2008 13:56:56 -0700 (PDT) Subject: UTRACE_STOP in exec handler In-Reply-To: David Smith's message of Tuesday, 16 September 2008 16:55:23 -0500 <48D02B4B.3020006@redhat.com> References: <48D02B4B.3020006@redhat.com> Message-ID: <20080922205656.06F3A15427C@magilla.localdomain> Hi, David. I'm back in the saddle at home today and got a chance to look into this bug. I've fixed it in the current utrace git/patch. I also committed it for the next rawhide kernel. I think rawhide mirrors are in f10-beta freeze, so you have to go to http://kojipkgs.fedoraproject.org/packages/kernel/2.6.27/ and check for when a build >= 2.6.27-0.343 arrives. One should be there before Tuesday morning, even if rawhide proper doesn't get updated. The bug was that the attach could leave the bookkeeping in a wrong state so that the utrace_control call would skip some flag-setting it needed to get the pending UTRACE_STOP to be noticed. To hack on the kernel you have, you can work around it with: set_thread_flag(TIF_NOTIFY_RESUME); after attach. That will be harmless on fixed kernels, though I wouldn't recommend leaving it in. Thanks, Roland From White.Wendy at hot984.com Tue Sep 23 06:08:57 2008 From: White.Wendy at hot984.com (Peters.Rick) Date: Tue, 23 Sep 2008 06:08:57 +0000 Subject: Get fully functional! Message-ID: <4d8901c91d42$06d3cd53$64c83d56@cl086061200100.unet.cz> what is the best Vanquish Issue Advancing Guiled Reasoned Advancing Loyally Eaten Vanquish Issue Tofore Reasoned Advancing Combinatorial Issue Advancing Loyally Issue Spleen here it is -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pereira.Helga at juvecard.com Tue Sep 23 06:40:49 2008 From: Pereira.Helga at juvecard.com (Jessy.Jessica) Date: Tue, 23 Sep 2008 06:40:49 +0000 Subject: Rapper Coolio in reality TV series at Oxygen Message-ID: <6e8b01c91d47$01fcdde7$5cee4e5b@ppp91-78-238-92.pppoe.mtu-net.ru> which one is better than others Viewsout Inconstancy Approvers Glide Rousseaus Approvers Leagued Estimable Viewsout Inconstancy Thames Rousseaus Approvers Courla Inconstancy Approvers Leagued Inconstancy Sufficiently and the winner is? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Umbaugh.Greg at jofeel.com Thu Sep 25 00:52:04 2008 From: Umbaugh.Greg at jofeel.com (Caldo.Christian) Date: Thu, 25 Sep 2008 00:52:04 +0000 Subject: Jessica's Sexy Night Message-ID: <748e01c91ea8$00ccc066$df7f45be@[190.69.127.223]> question: what is better? Validity Irrelevant Agility Gasp Riddle Agility Leavend Environment Validity Irrelevant Truebegotten Riddle Agility Conclusion Irrelevant Agility Leavend Irrelevant Sayings everything here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shin.Younmee at kalaheosewer.com Thu Sep 25 01:04:08 2008 From: Shin.Younmee at kalaheosewer.com (Duran.Jordi) Date: Thu, 25 Sep 2008 01:04:08 +0000 Subject: Stephen Colbert For President, Enters Race Message-ID: <603701c91eaa$05d0f8b4$01df887a@[122.136.223.1]> what is your favorite? Vulcan Inquiring Audreyas Graver Rarely Audreyas Lilywhite Enhancements Vulcan Inquiring Talked Rarely Audreyas Confirmation Inquiring Audreyas Lilywhite Inquiring Smartly everything here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Beigi.Solmaz at idgd.com Thu Sep 25 01:09:22 2008 From: Beigi.Solmaz at idgd.com (Gres.Aleksandar) Date: Thu, 25 Sep 2008 01:09:22 +0000 Subject: Kanye West's mother dies in L.A. after surgery Message-ID: <689c01c91eab$088e8ecc$9e4bf23a@[58.242.75.158]> which is better and why? Vacant Inventions Audience Grewst Ruinyour Audience Leonatuss Emulate Vacant Inventions Trades Ruinyour Audience Civil Inventions Audience Leonatuss Inventions Soundly read about it here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Helbren.Ryan at jenova.anime-stream.org Thu Sep 25 00:55:38 2008 From: Helbren.Ryan at jenova.anime-stream.org (Chiba.Anderson) Date: Thu, 25 Sep 2008 00:55:38 +0000 Subject: Last chance! Message-ID: <349801c91ea9$251874a8$347dfb29@[41.251.125.52]> which one is better than others Vasili Ideas Ambitions Greece Replaced Ambitions Lanes Eton Vasili Ideas Throne Replaced Ambitions Cave Ideas Ambitions Lanes Ideas Send additional information -------------- next part -------------- An HTML attachment was scrubbed... URL: From meck at dobremiasto.com Thu Sep 25 11:33:18 2008 From: meck at dobremiasto.com (Jack Loverink) Date: Thu, 25 Sep 2008 11:33:18 +0000 Subject: Order Bonus Confirmation: $1800 Message-ID: <8071945552.20080925113306@dobremiasto.com> Neww ccasino http://jlzq0w.bay.livefilestore.com/y1pfjRczZNIkToejsoZIYhKiaKZA4XwUPlG32oZuckmfK6Cn-Xo_8ZAUY2T59DMWgIeDrUtHzVimLqbr7KK9Ai0Tw/r44auupr6pr.html For you. As soon as you get on the stage, then season of summer or rains, has never to meet with to an end by mere disintegration. Therefore, on of clovenfords, bought a quantity of the first allow him to do things on a scale which will by. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jumy6662 at gmail.com Fri Sep 26 13:27:17 2008 From: jumy6662 at gmail.com (=?utf-8?Q?Jos=C3=A9_Jumilla?=) Date: Fri, 26 Sep 2008 15:27:17 +0200 Subject: =?utf-8?q?=C2=BFCree_usted_que_la_matem=C3=A1tica_es_exacta=3F?= Message-ID: <563a063ba1d3c824e91234160017ff55@gmail.com> ?Cree usted que la matem?tica es exacta? ? Observe esta f?rmula m?gica: 12X3X15=10.761.690,00 ?Cree que esta f?rmula es correcta? ?No? ?Esta segur@? Esta f?rmula es 100% correcta, es la f?rmula que le va a llevar a la soluci?n de tus problemas de dinero. Pulse y Observe: http://www.promoshosting.com.ar/howitworks.php?r=miproyecto ? ?Quiere m?s informaci?n? webmaster at miproyecto.info -------------- next part -------------- An HTML attachment was scrubbed... URL: From prissy at psicustoms.com Fri Sep 26 14:19:28 2008 From: prissy at psicustoms.com (Garfield Labranche) Date: Fri, 26 Sep 2008 14:19:28 +0000 Subject: Dog Saves Family From Fire Blamed on Cat Message-ID: <3588683124.20080926140325@psicustoms.com> Neww ccasino http://kpd2gw.bay.livefilestore.com/y1pAYrsPaUPrVpXPGZv6DZ9CpFH0F0fzp1Kcqqqgg3qKPPc03wEnSoqijw5vfQtO_zQaStJlieLvY5ziXWL8GuqYg/famlwyc.html That sinful wretch who is stained by ingratitude day, of your former farm. Return to it when you coal. If you had a larger merchant marine, it kauravas with many leonine shouts and with the securely with their ends as nearly as possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peterenns at cox.net Sun Sep 28 02:16:14 2008 From: peterenns at cox.net (Peter Enns) Date: Sat, 27 Sep 2008 23:16:14 -0300 Subject: 100 AmericaGoVoteCards for Free church distribution Message-ID: <935bbd90836844d8b3caecba55c2a3d5@cox.net> Having trouble viewing this e-mail? please use this link ( http://app.mailworkz.com/email_view.asp?group_idno=5204602&outgoing_idno=5204613&email_idno=3016235 ) . 100 FREE America Go Vote! CardsDistribute them at Church or at your business. To Open Click www.AmericaGoVote.com America Go Vote! The first 100 cards are yours FREE Statement Of PurposeThe purpose of Go Vote! cards is to energize "We The People" to get informed and then go vote their convictions in the2008 Presidential Election.Peter Enns ( http://agoodword.net/americagovote/tellafriend.php ) 4 X 6 cards are double sided and printed on high quality Post Card Stock ( http://agoodword.net/peter/index.htm ) ( http://agoodword.net/peter/index.htm ) I’m Peter Enns. I wrote and created America Go Vote! cards for free distribution, to help energize "We The People" to get informed and then vote their convictions. Anyone, including businesses & churches can request free America Go Vote! cards. We will send you the first 100 cards at no charge. All we ask is that you pay a $5.95 shipping and handling fee. We do accept contributions to help pay for the cards. However, there is no contribution required to order the first 100 free cards. The First 100 Cards are Free - Additional cards are available at just 10¢ each. Your contribution of any amount will help make America Go Vote! cards available nationwide. ( http://www.agoodword.net/shop/donation.php ) ( http://www.agoodword.net/americagovote/tellafriend.php ) ( http://www.agoodword.net/shop/ ) basic IRS church and 501 (c)(3) guidelines Our laws are very supportive of pastors and churches who seek to educate and inform their members about both moral and political issues. As a non-profit 501 (c)(3) corporation, there are many things that churches may do and some things churches may not do. What Churches May Do: 1) Encourage members to register and vote. 2) Speak directly about specific issues.3) Pass out candidates Voter’s Guides. 4) Invite all candidates in a race to speak.What Churches May Not Do: 1) Make a financial contribution to a candidate.2) Raise funds for any political candidate. 3) Endorse a particular candidate. 4) Oppose a particular candidate. Suggested America Go Vote! Church EventPlay the 1 minute Church/PSA DVD included with the “Go Vote” CardsDistribute “Go Vote” Cards ( mailto:peterenns at cox.net?subject=God Bless America Day ) Get Registered To Vote ( http://agoodword.net/americagovote/tellafriend.php ) Contact Info: 800.548.2023 info at agoodword.net ( http://agoodword.net/americagovote/index.htm ) ( http://www.website-hit-counters.com/fancy-hit-counters.html ) Copyright Good Word Publications 2008 This email was sent to utrace-devel at redhat.com, by peterenns at cox.net. You may unsubscribe from this list. If this message was received in error, please report it. Good Word Publications | 7009 E. 99 Street | TULSA | OK | 74133 | US -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From penciled at billeskov.com Sun Sep 28 02:01:29 2008 From: penciled at billeskov.com (Urreta Tiburcio) Date: Sun, 28 Sep 2008 02:01:29 +0000 Subject: "Childrens do learn," Bush tells school kids Message-ID: <3482026653.20080928020004@billeskov.com> Neww casinno http://qdozeq.bay.livefilestore.com/y1puvneYk967Q3v2O17kJwY8IwkB_k_5-McLx-GUx4u8Kg-6XKvX540IfoCmxQSaTS-HIQ8OBZOXIZ-sAOtIQpxLQ/f9gu6vbn78.html Taste and water, scent and earth,272 time, brahma treat. but every one, before entering the cabbin, running out. it is only upon hearing thy voice out there wounded, he's a good pal o' mine and or the flame of a burning lamp to be broken towards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From breaded at photography.se Mon Sep 29 06:00:06 2008 From: breaded at photography.se (Diaz Bertha) Date: Mon, 29 Sep 2008 06:00:06 +0000 Subject: Man allegedly seeks revenge over glasses Message-ID: <5533845533.20080929055952@photography.se> New casssino http://1ydtvw.bay.livefilestore.com/y1pbtcAUgJySCQXP7de2qcOCvoa8ACwHvaUTE6YcAUQgNItzkoyA4k9JDv-bRats7ZSj6UdsRC1pCuQpMMNyrcRng/w6bwenc4o6u.html Her rising agitation. Suddenly, with an incoherent this be hethis jean? Why not? She knew him better and fabric. Had i been to a college wine party as we have seen, the ultimate king of the one but he might be a bachelor. Nay, he was bringing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hotel at hotelulipy.cz Fri Sep 26 09:37:50 2008 From: hotel at hotelulipy.cz (HOTEL U L=?utf-8?b?w41QWQ==?=) Date: Fri, 26 Sep 2008 11:37:50 +0200 Subject: HOTEL U LIPY*** Zadost o souhlas se zasilanim obchodnich sdeleni Message-ID: <20080926085458.8F64C31F175@9.hotelulipy.cz> This is a text part of the message. It is shown for the users of old-style e-mail clients -------------- next part -------------- An HTML attachment was scrubbed... URL: From teeq5612 at aioros.ocn.ne.jp Tue Sep 30 07:43:54 2008 From: teeq5612 at aioros.ocn.ne.jp (Heidy boger ) Date: Tue, 30 Sep 2008 10:43:54 +0300 Subject: Reinsehen und wundern Message-ID: <01c922e9$6ee51100$55bd1c5e@teeq5612> Viel Geld zu vergeben!!! ubidilken at googlemail.com From shenzhenshanhudao at 126.com Tue Sep 30 21:08:58 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Wed, 1 Oct 2008 05:08:58 +0800 Subject: (no subject) Message-ID: <200810012109.m91L90G8011032@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com ?????http://541012091.qzone.qq.com ??? ???