> So the choice seems to be either:
>
> - make the exit path hold the task lock over the whole exit path, not
> just over mm exit.
>
> - take the "tasklist_lock" over more of "task_sig()" (not just the
> collect_sigign_sigcatch() thing, but the "&p->signal->shared_pending"
> rendering too.
>
> The latter is a two-liner. The former is the "right thing" for multiple
> reasons.
>
> The reason I'd _like_ to see the task lock held over _all_ of the fields
> in the exit() path is:
>
> - right now we actually take it and drop it multiple times in exit. See
> __exit_files(), __exit_fs(), __exit_mm(). Which all take it just to
> serialize setting ot "mm/files/fs" to NULL.
>
> - task_lock is a nice local lock, no global scalability impact.
Don't we have to take tasklist_lock anyway for when task_state reads
p->real_parent->pid and p->parent->pid? Or should we have to grab
the task_lock for those too? If so, it sounds like it could get into
rather horrible ordering dependencies to me.
If we move exit under task_lock ... then tasklist_lock doesn't help us
any more there either (presumably we're trying to stop them exiting
whilst we look at them) ... I've coded up the stupid approach for now,
and will check that works first. Should have results very soon.
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:15 EST