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