Messages in this thread | | | Subject | Re: [PATCH] Fix signal race during process exit | From | Rusty Russell <> | Date | Wed, 02 Jun 2004 16:49:48 +1000 |
| |
On Wed, 2004-06-02 at 15:57, Andrew Morton wrote: > void update_process_times(int user_tick) > { > struct task_struct *p = current; > int cpu = smp_processor_id(), system = user_tick ^ 1; > versus: > > void __exit_sighand(struct task_struct *tsk) > { > struct sighand_struct * sighand = tsk->sighand;
No. tsk == current for __exit_sighand. You know, getting current is SO expensive, and so we should PASS IT to functions explicitly!
One of my pet gripes: this code is badly obfuscated by this. Is it just me?
> And there's a little window at the end of exit_notify() where the exitting > task (which is still "current" on its CPU) can take a timer interrupt while > in a state TASK_ZOMBIE. The CPU which is running wait4() will run > release_task() for the exitting task and the above race can occur.
Hmm, while we're at it, the task seems to release itself while running here: exit_notify() -> release_task() -> put_task_struct() -> __put_task_struct() -> BOOM?
Surely not, what am I missing?
> Right now, I see no alternative to adding locking which pins task->sighand > while the timer handler is running. Taking tasklist_lock on each timer > tick will hurt - maybe a new per-process lock is needed?
Hmm, a per-cpu cache of exited tasks: one task for each CPU. We hold a reference to the task struct until the next exit on the same CPU happens? We could also reuse that cache for fork()...
Rusty. -- Anyone who quotes me in their signature is an idiot -- Rusty Russell
- 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/
| |