fork_findpid() - Fatal trap 12: page fault while in kernel mode

[Don Lewis]

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