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