Date: Thu, 2 May 1996 15:58:24 -0400 (EDT) From: "Marc G. Fournier" <scrappy@ki.net> To: Peter Wemm <peter@freefall.freebsd.org> Cc: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/kern kern_fork.c Message-ID: <Pine.NEB.3.93.960502155813.22809C-100000@freebsd.ki.net> In-Reply-To: <199605021138.EAA18666@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
so maybe it wasn't *all* hardware? :) On Thu, 2 May 1996, Peter Wemm wrote: > peter 96/05/02 04:38:06 > > Modified: sys/kern kern_fork.c > Log: > Fix a nasty bug that causes random crashes and lockups particularly on > very busy servers (eg: news, web). This is an interaction between > embryonic processes that have not yet finished forking, and happen to > cause the kernel VM space to grow, hitting the uninitialised variable. > > It was possible for this to strike at any time, depending on the size of > your kernel and load patterns. One machine had paniced occasionally > when cron launches a job since before the 2.1 release. > > If you had "options DIAGNOSTIC", you may have seen references to bogus > addresses like 0xdeadc142 and the like. > > This is a minimal change to fix the problem, it will probably be done > better by reordering p_vmspace to be in the startzero section, but it > becomes harder to validate then. > > It's been vulnerable since pmap.c rev 1.40 (Jan 9, 1995), so it's been a > cause of problems since well before 2.0.5. This was when the merged > VM/buffer cache and the dynamic growing kernel VM space were first > committed. This probably fixes a few of PR's. > > Revision Changes Path > 1.21 +6 -1 src/sys/kern/kern_fork.c > Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.93.960502155813.22809C-100000>