[lkml]   [2002]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] pid_max hang again...
> 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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.070 / U:3.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site