On 08/19, Roland McGrath wrote: > > > On 08/16, Roland McGrath wrote: > > > > > Now that you merged c93fecc925ea7567168f0c94414b9021de2708c5 > > "get_utrace_lock() must not succeed if utrace->reap == T", this becomes > > a bit off-topic. However, I thought about relaxing the "dead" check in > > get_utrace_lock(), instead of utrace->reap we could check > > "utrace->reap && !utrace->death". In fact, initially I was going to > > do this, but then decided to make the simpler patch for now. > > 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). 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. > But I think that the > API definition of "once release_task() has been called (i.e. entered, > maybe not returned yet), any utrace call will get -ESRCH", is a clear > and comprehensible constraint. We should not open any holes in that. 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. Oleg.
