Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Dec 2015 11:48:08 -0800 (PST)
From:      Don Lewis <truckman@FreeBSD.org>
To:        kostikbel@gmail.com
Cc:        freebsd-current@freebsd.org
Subject:   Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode
Message-ID:  <201512171948.tBHJm80b094518@gw.catspoiler.org>
In-Reply-To: <20151217120343.GA3625@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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 ...





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201512171948.tBHJm80b094518>