Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (un)registration and exception handling.

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Peter Zijlstra
Date: Wednesday, September 1, 2010 - 2:43 pm

On Wed, 2010-08-25 at 19:12 +0530, Srikar Dronamraju wrote:


I wouldn't worry about that, focus on inode attached probes and you get
fork for free.



Seems like a weird place for this hunk, does this want to live
elsewhere?


A nicer way is to provide flush_uprobes() unconditionally.


I find the _process postfix a bit weird in this context, how about
something like:

  struct mm_uprobes *mm_uprobes;

instead?


Make that: 

	struct uprobe_task_state uprobe_state;

And provide an empty struct for !CONFIG_UPROBE, see below.



Would fail for pid namespaces I guess...


Like previously said, I would much rather see an inode/offset based
interface and do the pid/fork/pgroup/cgroup etc.. stuff as filters on
top of that.


Seems like a weird comment for kernel code..


struct mm_uprobes {


Its customary to write it like:

	spinlock_t	 list_lock; /* protects uprobe_list, nr_uprobes */
	struct list_head uprobe_list;
	int		 nr_uprobes;


Why void * and not simply:

	struct uprobes_xol_area xol_area;

That struct is small enough and you only get one per mm and saves you an
allocation/pointer-chase.


you really got a way with names, uprobe_point would be so much better.


So this thing is a link between the process and the probe, I'm not quite
sure what you need the refcount for, it seems to me you can only have on
of these per process/probe combination.

If you had used inode/offset based probes they would have been unique in
the system and you could have had an {inode,offset} indexed global tree
(or possibly a tree per inode, but that would mean adding to the inode
structure, which I think is best avoided).

That would also reduce the mm state to purely the xol area, no need to
manage this process to probe map.


I would be thinking you can obtain the active probe point from the
address the task is stuck at and the state seems fairly redundant. Which
leaves you with the arch state, which afaict is exactly as large as the
pointer currently in the task struct.


All that can be replaced by unconditional functions, simply stub them
out for !CONFIG_UPROBE.


Wandering hunks, these seem to want to get folded back to wherever the
original text comes from..


uproc is per mm, why a global mutex?



Don't bother with that...


The grand thing about not having any of this process state is that you
dont need to clean it up either..


You can replace this with:

 addr = instruction_pointer(task_pt_regs(current)) -
ip_advancement_by_brkpt_insn;

and then proceed from there like described below to obtain the struct
uprobe.

You can infer the SS/HIT state by checking if the user-addr is in the
XOL area or not.


Its an address, not a struct uprobe_probept * so call it addr if
anything.


Right, so all this should die..

Obtain the address, lookup the vma, get the file, compute the offset
inside that file -> {inode,offset}

Do the lookup in the global tree to obtain the uprobe, and possibly
execute the probe handler right here in interrupt context, if it fails
with -EFAULT, continue with the below:


How can we ever get here if the architecture doesn't support uprobes?



--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches, Srikar Dronamraju, (Wed Aug 25, 6:41 am)
[PATCHv11 2.6.36-rc2-tip 1/15] 1: mm: Move replace_page() ..., Srikar Dronamraju, (Wed Aug 25, 6:41 am)
[PATCHv11 2.6.36-rc2-tip 2/15] 2: uprobes: Breakpoint ins ..., Srikar Dronamraju, (Wed Aug 25, 6:41 am)
[PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot allocatio ..., Srikar Dronamraju, (Wed Aug 25, 6:41 am)
[PATCHv11 2.6.36-rc2-tip 4/15] 4: uprobes: x86 specific f ..., Srikar Dronamraju, (Wed Aug 25, 6:42 am)
[PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (un)re ..., Srikar Dronamraju, (Wed Aug 25, 6:42 am)
[PATCHv11 2.6.36-rc2-tip 6/15] 6: uprobes: X86 support fo ..., Srikar Dronamraju, (Wed Aug 25, 6:42 am)
[PATCHv11 2.6.36-rc2-tip 7/15] 7: uprobes: Uprobes Docume ..., Srikar Dronamraju, (Wed Aug 25, 6:42 am)
[PATCHv11 2.6.36-rc2-tip 8/15] 8: tracing: Extract out co ..., Srikar Dronamraju, (Wed Aug 25, 6:42 am)
[PATCHv11 2.6.36-rc2-tip 9/15] 9: tracing: uprobes trace_ ..., Srikar Dronamraju, (Wed Aug 25, 6:43 am)
[PATCHv11 2.6.36-rc2-tip 10/15] 10: tracing: config option ..., Srikar Dronamraju, (Wed Aug 25, 6:43 am)
[PATCHv11 2.6.36-rc2-tip 11/15] 11: perf: list symbols in ..., Srikar Dronamraju, (Wed Aug 25, 6:43 am)
[PATCHv11 2.6.36-rc2-tip 12/15] 12: perf: show possible pr ..., Srikar Dronamraju, (Wed Aug 25, 6:43 am)
[PATCHv11 2.6.36-rc2-tip 13/15] 13: perf: Loop thro each o ..., Srikar Dronamraju, (Wed Aug 25, 6:43 am)
[PATCHv11 2.6.36-rc2-tip 14/15] 14: perf: perf interface f ..., Srikar Dronamraju, (Wed Aug 25, 6:44 am)
[PATCHv11 2.6.36-rc2-tip 15/15] 15: perf: Show Potential p ..., Srikar Dronamraju, (Wed Aug 25, 6:44 am)
Re: [PATCHv11 2.6.36-rc2-tip 11/15] 11: perf: list symbols ..., Arnaldo Carvalho de Melo, (Wed Aug 25, 4:21 pm)
Re: [PATCHv11 2.6.36-rc2-tip 11/15] 11: perf: list symbols ..., Srikar Dronamraju, (Wed Aug 25, 9:32 pm)
Re: [PATCHv11 2.6.36-rc2-tip 10/15] 10: tracing: config op ..., Masami Hiramatsu, (Wed Aug 25, 11:02 pm)
Re: [PATCHv11 2.6.36-rc2-tip 10/15] 10: tracing: config op ..., Srikar Dronamraju, (Fri Aug 27, 2:31 am)
Re: [PATCHv11 2.6.36-rc2-tip 10/15] 10: tracing: config op ..., Srikar Dronamraju, (Fri Aug 27, 5:17 am)
[PATCHv11a 2.6.36-rc2-tip 10/15] 10: tracing: config optio ..., Srikar Dronamraju, (Fri Aug 27, 7:10 am)
[PATCHv11a 2.6.36-rc2-tip 12/15] 12: perf: show possible p ..., Srikar Dronamraju, (Fri Aug 27, 7:21 am)
[tip:perf/core] perf symbols: List symbols in a dso in asc ..., tip-bot for Srikar D ..., (Mon Aug 30, 1:35 am)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Peter Zijlstra, (Wed Sep 1, 2:43 pm)
Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot alloc ..., Srikar Dronamraju, (Thu Sep 2, 10:47 am)
Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot alloc ..., Srikar Dronamraju, (Fri Sep 3, 9:40 am)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Srikar Dronamraju, (Fri Sep 3, 9:42 am)
Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot alloc ..., Srikar Dronamraju, (Fri Sep 3, 10:26 am)
Re: [PATCHv11 2.6.36-rc2-tip 4/15] 4: uprobes: x86 specif ..., Srikar Dronamraju, (Fri Sep 3, 10:48 am)
Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot alloc ..., Srikar Dronamraju, (Sun Sep 5, 10:38 pm)
Re: [PATCHv11 2.6.36-rc2-tip 4/15] 4: uprobes: x86 specif ..., Srikar Dronamraju, (Mon Sep 6, 6:44 am)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Srikar Dronamraju, (Mon Sep 6, 10:46 am)
Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot alloc ..., Srikar Dronamraju, (Mon Sep 6, 10:59 am)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Mathieu Desnoyers, (Mon Sep 6, 11:25 am)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Christoph Hellwig, (Mon Sep 6, 1:40 pm)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Christoph Hellwig, (Mon Sep 6, 2:12 pm)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Srikar Dronamraju, (Mon Sep 6, 11:48 pm)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Srikar Dronamraju, (Tue Sep 7, 4:51 am)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Srikar Dronamraju, (Tue Sep 7, 5:02 am)
Re: [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (u ..., Mathieu Desnoyers, (Tue Sep 7, 9:47 am)
Re: [PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches, Christoph Hellwig, (Fri Oct 29, 2:23 am)
Re: [PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches, Srikar Dronamraju, (Fri Oct 29, 3:48 am)
Re: [PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches, Christoph Hellwig, (Thu Nov 4, 11:45 am)