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>