Re: updated uprobes patches

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Sat, 2007-05-26 at 18:44 -0700, Roland McGrath wrote:
> I didn't catch up on the threads from Ernie's review until after Jim posted
> this new version.  I have not reviewed the current code in great detail.
> Had I been active in the discussion a couple of weeks ago, I would have
> expressed by strong opposition to keeping the mm_struct change.

There are two issues here: (a) allowing uprobes to be a module; and (b)
removing the uprobes field from mm_struct.  See below.

> I think
> it's essential that the code be turned into an independent module requiring
> no changes in the base kernel (unless they are changes to the formal utrace
> interfaces).  From skimming the code, the mm_struct field seems to be the
> only thing preventing it now.

The last time I checked, there were 3 things standing in the way of
implementing uprobes as a module:

1. __put_task_struct() wasn't exported, so uprobes couldn't call
put_task_struct().
2. access_process_vm() wasn't exported, so uprobes couldn't call that.
3. I couldn't figure out how to build a module consisting of
kernel/uprobes.o and arch/i386/kernel/uprobes.o.  (So I put 'em both in
the same directory for my experiment.)

#1 and #2 are still a problem in Linus's kernel, but (thanks to Rusty's
lguest module) not in recent -mm kernels.  I still haven't figured out
#3, but will ask around.

> This would also be a boon to developers
> immediately, since they could hack on the modules using e.g. their standard
> Fedora kernels already installed.

Er, do Fedora kernels export access_process_vm() and
__put_task_struct()?  (I'm currently running a kernel.org kernel.)  If
not, is it still worthwhile to modularize uprobes?

> I believe the value of being a clean
> module outweighs, in the short term for development, any performance
> concerns arising about overeager deallocation, insufficient sharing, etc.

Current practice is to deallocate the uprobe_process graph when the
count of registered probes hits zero.  If the uprobe_process graph
becomes the only place to remember where the SSOL vma lives, I think the
path of least resistance is to discard (munmap) the SSOL vma along with
the uprobe_process.  (Haven't tried that yet.)

> I'd say work with a modular version right away, sacrificing in the first
> cut whatever you have to sacrifice to make it work as a separate module.
> Then we'll get to further refinements like improving the sharing and reuse,
> along with plenty more refinements in other areas that are just as pressing.
> 
> 
> Thanks,
> Roland

Jim