[PATCH 3/4] utrace_set_events: fix UTRACE_EVENT(REAP) case

[Roland McGrath]

> > When utrace->reap is set, it means release_task() has been called.  The
> > API caller has no way to know reaping hasn't already begun--except if
> > its report_death callback has not returned yet.
> 
> No! the task can be already reaped even before ->report_death() was
> called. The task_struct itself can't go away, but that is all (perhaps
> you meant this).

Yeah, that's kind of what I meant.  More precisely, I just had in mind
the report_reap callback as the utrace user's idea of "reaped".

> And this is the problem for ugdb. Damn, I knew this, that is why
> ugdb_process_exit() doesn't try to read ->group_exit_code. Still I
> managed to forget that this has other implications.

Yeah, I hadn't thought about those implications for what a report_death
callback might want to access.  For group_exit_code at least, it should be
resolved by the 2.6.35 change in the lifetime of signal_struct.

> I am not sure. I had another reason in mind to check reap && !death in
> get_utrace_lock(), synchronization with ->report_death() callback.
> 
> But OK. Let's forget about more utrace changes for now.

Agreed.


Thanks,
Roland