Re: updated uprobes patches

[Roland McGrath <roland@redhat.com>]

> 1. __put_task_struct() wasn't exported, so uprobes couldn't call
> put_task_struct().

You should not need this.  The intent is that utrace facilities give you
all the synchronization you need.  At cold attach time, things are
admittedly a little sketchy, but rcu_read_lock may be all you need.

In report_clone the child can't go anywhere until your callback returns.
Let me know if you don't think this is clear in the documentation.

I don't want to dwell too much on the life-cycle tracking details.  In the
long run I expect all of that to be handled by another component so the
full complexity of the picture won't be your problem.  In the immediate
term, it's not hard to get it going well enough for experimentation.  Not
every corner has to be covered to make something to develop with.

> 2. access_process_vm() wasn't exported, so uprobes couldn't call that.

get_user_pages is.  It is more efficient to use a single read-copy-write
done with get_user_pages et al than separate access_process_vm calls anyway.
I may come up with some convenience functions related to this eventually.
But the code is short, doing it directly is just a few minutes' work.

> 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.)

I'm not going to worry about build trivia for the moment, just the code.
That sort of issue can always be worked out one way or another.

> 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 think we are approaching the discussion from rather different points of view.

I mentioned immediate ease of development because I thought it would be
motivational for you, not because it is my own primary motivation behind my
arguments.  The basis of my view is that utrace exists to enable the
implementation of things just like uprobes without further modifications to
the core kernel.  When that is difficult, it points to needs for
improvements in the utrace API, or for components to build on top of it.
My real motivation is the general growth of the infrastructure and ecology
of such components.  Frankly, I am not very interested in implementation
details of uprobes per se, which I consider a prototype in its basic
structure.  This is why I began the separate thread of discussion on a few
detailed subtopics of "breakpoint assistance".  My own interest is in the
robust fleshing out of the "interesting" components of that work, like
truly robust instruction decoding.

> 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.)

Yes, that is what I meant to imply as the natural "unoptimized" plan.



Thanks,
Roland