Messages in this thread | | | Subject | Re: [RFC] [PATCH 4/7] Uprobes Implementation | From | Peter Zijlstra <> | Date | Fri, 15 Jan 2010 12:18:04 +0100 |
| |
On Fri, 2010-01-15 at 12:12 +0100, Peter Zijlstra wrote: > On Fri, 2010-01-15 at 16:35 +0530, Maneesh Soni wrote: > > On Fri, Jan 15, 2010 at 11:33:27AM +0100, Peter Zijlstra wrote: > > > On Fri, 2010-01-15 at 15:56 +0530, Srikar Dronamraju wrote: > > > > Hi Peter, > > > > > > > > Or there could be two threads that could be racing to > > > > insert/delete a breakpoint. These synchronization issues are all handled > > > > by the Uprobes layer. > > > > > > Shouldn't be hard to put that in the ubp layer, right? > > > > > > > Uprobes layer would need to be notified of process life-time events > > > > like fork/clone/exec/exit. > > > > > > No so much the process lifetimes as the vma life times are interesting, > > > placing a hook in the vm code to track that isn't too hard, > > > > > > > I think similar hooks were given thumbs down in the previous incarnation > > of uprobes (which was implemented without utrace). > > > > http://lkml.indiana.edu/hypermail/linux/kernel/0603.2/1254.html > > I wasn't at all proposing to mess with a_ops, nor do you really need to, > I was more thinking of adding a callback like perf_event_mmap() and a > corresponding unmap(), that way you can track mapping life-times and > add/remove probes accordingly. > > Adding the probe uses the fact that (most) executable mappings are > MAP_PRIVATE and CoWs a private copy of the page with the modified ins, > right?
Does it clean up the CoW'ed page on removing the probe? Does that account for userspace having made other changes in between installing and removing the probe (for PROT_WRITE mappings obviously)?
| |