On 04/20, Roland McGrath wrote: > > > > 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.)
Agreed. > > 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, Yes, you are right. Let's start with ptrace child cleanup. If we don't clear ->ptrace_child until __put_task_struct() as you suggested, then these changes are easy except they need a lot of grepping. Actually, I was going to send you the first patches today, but I have a couple of questions, see another email. In fact these questions are almost off-topic, but still I'd like to understand the code I am going to change. Oleg.
