[PATCH] Embed struct utrace in task_struct - V2

[Ananth N Mavinakayanahalli]

On Mon, Mar 02, 2009 at 04:07:54AM -0800, Roland McGrath wrote:
> Hi, Ananth.  Sorry everything has slid so long (again).
> (I have far too many hats and the past month not so many brains!)

I understand. Thanks for the work, Roland.

> Here is my immediate agenda for utrace hacking:
> 
> * I have incorporated the "embed struct utrace" changes.
> 
>   I did various small bits of reorganization and cosmetic cleanup
>   first to make the actual data structure change a smaller patch.
>   Since things had changed around, I didn't actually use your patch.
>   I just did it over myself, but I think it's nearly the same.

The changes look simple and straightforward.

>   After this change, we now need some fresh testing of things like Frank's
>   ftrace widget and stap's utrace-using modes.  (Nothing should have
>   changed from the utrace API perspective.)

There is at least one change from the earlier behaviour -- rather than
utrace_attach_task() retrying by itself on a !parent attach, -EAGAIN is
returned to the user. That may need changes to the utrace client side.

>   I've created the new branch "utrace-indirect" with a revert of the
>   change.  I think this is really the better way to organize the data
>   structures, as I've mentioned before.  After we get an initial utrace
>   merged in upstream, I intend to revive this branch and turn it into an
>   incremental patch to (re-)improve the data structures later on.  That's
>   for later; for the time being, the branch will just sit idle.
> 
> * I've renamed "struct utrace_attached_engine" to "struct utrace_engine".
>   This was a cosmetic suggestion in an earlier LKML review, and I could not
>   really find any good reason to keep the longer name.  We all seem to say
>   "a utrace engine" in conversation when talking about this object.
> 
>   I added the UTRACE_API_VERSION macro to ease existing utrace-using code
>   adapting to old/new names.
> 
> * I'll shortly scour the old review comments for more cosmetic things we
>   might change.
> 
> * I would like to have a final "in-team" top-to-bottom review of the main
>   utrace patch before sending to LKML.  i.e. maybe by you, Frank, me, and Oleg.
>   Each pair of eyeballs should:  
>   * make sure all barriers and other kinds of magic have adequate comments
>     explaining why they are there and why they are correct
>   * cite anything else that sticks out and maybe needs more comments
>   * make sure all comments are accurate and understandable

I have just started staring at the new code and will pitch in with my
comments.
   
> * I want to resolve the UTRACE_STOP issues Renzo Davoli raised.
>   (We don't have to get these API things perfect before posting upstream.
>   I'm sure that once utrace is accepted on queue for merging, that later
>   tweaks to its details will not meet particular resistance.)  But if there
>   are problems and changes we can identify and work out now, we might as
>   well get that done before posting upstream.
> 
> * When we on the team think the utrace patch is ready to post, we need to
>   do a coordinated post of Frank's ftrace widget.  That is the first thing
>   ready for upstream submission that uses utrace, and kernel people tell me
>   they don't want to see utrace without also merging something that uses
>   it.  I don't really want to get involved with that widget's code myself
>   (got my hands full in the utrace layer), so others on the team should
>   back Frank up on the review, testing, and fixing of the ftrace widget.

I've just started with implementing a non-disruptive application core
dump. Its probably too early to commit, but it could also be a potential
in-kernel user of utrace. I've just started with quiescing all threads
but need to plug-in the core generating infrastructure for it. I am looking at
the possibility of tweaking do_coredump() to reuse it for this while the
workhorse can just be the binfmt->core_dump() itself. Its still in the
early prototype stage -- I'll post that when there is something more
concrete. Ideas/suggestions welcome!

Ananth