From owner-freebsd-current@freebsd.org  Thu Dec 17 19:48:18 2015
Return-Path: <owner-freebsd-current@freebsd.org>
Delivered-To: freebsd-current@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1800DA4BE51
 for <freebsd-current@mailman.ysv.freebsd.org>;
 Thu, 17 Dec 2015 19:48:18 +0000 (UTC)
 (envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id EDECE1CA5
 for <freebsd-current@freebsd.org>; Thu, 17 Dec 2015 19:48:17 +0000 (UTC)
 (envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
 by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id tBHJm80b094518;
 Thu, 17 Dec 2015 11:48:12 -0800 (PST)
 (envelope-from truckman@FreeBSD.org)
Message-Id: <201512171948.tBHJm80b094518@gw.catspoiler.org>
Date: Thu, 17 Dec 2015 11:48:08 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: fork_findpid() - Fatal trap 12: page fault while in kernel
 mode
To: kostikbel@gmail.com
cc: freebsd-current@freebsd.org
In-Reply-To: <20151217120343.GA3625@kib.kiev.ua>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/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: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 19:48:18 -0000

On 17 Dec, Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 11:08:02AM -0800, Don Lewis wrote:
>> I used to have a patch the deferred linking the new process into
>> proctree/allproc until it was fully formed.  The motivation was to get
>> rid of all of the PRS_NEW stuff scattered around the source.
>> Unfortunately the patch bit-rotted and I'm pretty sure that I lost it.
> 
> I had similar tought for a second as one of the possibilities to fix the
> issue, but rejected it outright due to the way the pid allocator works.
> The loop which faulted is the allocator, it depends on the new pid being
> linked early to detect the duplicated alloc.
> 
> What you wrote could be done, but this restructuring requires the separate
> pid allocator, and probably it must repeat all quirks and subtle behaviour
> of the current algorithm.  But I do not object, PRS_NEW is a trouble
> on its own.

I don't think it requires any changes to the allocater.  It should only
be necessary to delay the call to fork_findpid() until we are ready to
link the new proc into allproc.  Basically, drop the locks at the
beginning of do_fork(), then grab them again somewhere near the end
(probably where we are currently mark the process as PRS_NORMAL) and
move the call to fork_findpid(), the p2->p_pid assignment, and the list
manipulation code to a location after that.

It's probably not quite that simple though ...