[prev in list] [next in list] [prev in thread] [next in thread] 

List:       utrace-devel
Subject:    Re: ptrace cleanup tasks
From:       Roland McGrath <roland () redhat ! com>
Date:       2009-04-20 7:01:53
Message-ID: 20090420070153.9766FFC3C6 () magilla ! sf ! frob ! com
[Download RAW message or body]

> > Then the short-circuit test is simply if (!tsk->ptrace_info).
> 
> But, from the correctness pov, this doesn't differ from checking
> !list_empty(->ptraced) ? I mean, the condition can be changed under us
> in both cases, and we seem to have the same corner cases.

I guess it just seems simpler to me.  The only false indication we can get
is seeing !tsk->ptrace_info when the tsk is in ptrace_attach() or its child
is in ptrace_traceme().  Worrying about which directions of false races
with list_*() calls can be is far more hazy to me.

I think -ECHILD is just fine in that race.  The wait call happened "before"
the ptrace attach.  Am I overlooking a race scenario that matters?  (If
there is one, perhaps it might be handily adequately by doing an extra
wake_up_parent when allocating ->ptrace_info.)

> But of course I agree, this is better. I didn't try to pay much attention
> to these changes just because I thought (perhaps wrongly) we can ignore
> them in this discussion.

I had indeed expected the details to be orthogonal.  I only mentioned it
because it came to mind as a trick for the short-circuit optimization.

> Perhaps I should try to make some draft patches, just to see how it can
> look. But of course the discussion is still in progress ;)
> 
> Or I should start with "ptrace child" cleanup first... (will reply to your
> email about the child cleanups later).

My only goal in suggesting ordering of steps or which steps can be done in
parallel is to optimize the rate of overall progress.  I'd figured that
many of the data structure cleanup steps would be simple and mostly
orthogonal to the deep stuff.  It's easy to bang out a lot of that sort of
change and spend time fiddling around with how best to slice and order the
incremental patches to make them good reading, without much real thought.
For me, it works best to interleave that quasi-automatic stuff that doesn't
really tax the mind but can keep the fingers busy a long time, with the
stuff that is dense with much deep cogitation for small amounts of eventual
code and only really progresses at all when the mind has good focus.
Sometimes I also find it gets the juices going to actually hack around and
compile some code and commit some draft patches locally, so as to unstick
the gears for starting to grind out something concrete to get all that deep
cogitation to gel.  Take whatever approach optimizes the overall rate of
progress for you.  (But the more you parallelize the hacking and/or order
easy stuff first, the quicker we can cover the style and trivia review.)


Thanks,
Roland


[prev in list] [next in list] [prev in thread] [next in thread]