Message-ID: <3D79C195.90004@colorfullife.com>
Date: Sat, 07 Sep 2002 11:06:29 +0200
From: Manfred Spraul <manfred@colorfullife.com>
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
MIME-Version: 1.0
To: "Hanumanthu. H" <hanumanthu.hanok@wipro.com>
CC: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pid_max hang again...
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1251
Lines: 29

> 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/