From owner-freebsd-current@FreeBSD.ORG  Wed Jun 13 15:32:12 2012
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id CFF5B106564A;
	Wed, 13 Jun 2012 15:32:12 +0000 (UTC)
	(envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242])
	by mx1.freebsd.org (Postfix) with ESMTP id AF8B08FC12;
	Wed, 13 Jun 2012 15:32:12 +0000 (UTC)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id q5DFW4l0021256;
	Wed, 13 Jun 2012 08:32:07 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <201206131532.q5DFW4l0021256@gw.catspoiler.org>
Date: Wed, 13 Jun 2012 08:32:03 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: attilio@FreeBSD.org
In-Reply-To: <CAJ-FndBjbh-KkLrSMgq9Fof=6af8LK6nrXtC+e4jeDEVDBEWUw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Cc: freebsd-current@FreeBSD.org, onwahe@gmail.com, kaduk@mit.edu
Subject: Re: panic td->td_lock == NULL in scheduler(), csup'd 2011-02-19
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2012 15:32:12 -0000

On 13 Jun, Attilio Rao wrote:
> 2012/6/13, Svatopluk Kraus <onwahe@gmail.com>:
>> Hi,
>>
>>  it looks similar to
>> http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023829.html
> 
> Yes, that is likely the problem.
> However, I would really love to workaround the pid allocation race in
> another way than PRS_NEW because this imposes an extra-constraint,
> undocumented, on iterations of processes in the system.
> If you want to work on a patch for that, you are welcome to do so.

A long time ago I had a patch that moved pid allocation and insertion
into allproc to a later point in fork1() where the child had been fully
initialized.  It had two minor disadvantages.  The first is that
allproc_lock needed to be acquired and released twice.  The second is
that nprocs and the number of processes in allproc temporarily become
inconsistent while the fork is in progress.

Eventually the patch conflicts got too bad and I dropped the patch from
my local tree.