>> 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.
Hmmmm ... I guess we could keep real_parent->pid and parent->pid inside
the child's task_struct ... I can't see those change unless we're changing
real_parent / parent task pointers anyway. Not sure how much that idea
will make people vomit, but it would seem to make it easier to get rid
of the global locking, and it's probably nicer than trying to order the
aquistion of other people's task locks ...
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