> As Manfred pointed out, pid allocation and inserting it into task
> list should be atomic. But going by the range of pids available
> in 2.5.33 (Linux made it 30-bits), it is unlikely that same pid
> will be given to two processes, since last_pid is protected by
> single lock.
Right now there is quite a lot of code between get_pid and the insertion
into the task list: copy mm, files, etc.
And just before the endless loop in get_pid(), there is only one pid
left --> probability of getting the same pid again is high. If you fix
the hang, you should fix the atomicity, too.
> If last_pid is within PID_MAX and max_pid_cross is set, this
> pid might have been given to another process. So, goto the
> corresponding hashlist and check for its existence. If no task
> with given pid found, then get_pid is free to return pid as the
> available pid.
Doesn't work: find_task_by_pid() only checks task->pid. But the result
of get_pid mustn't be in use as a session or tgid value either
-- Manfred- 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 : Sat Sep 07 2002 - 22:00:31 EST