From owner-freebsd-bugs  Sat Sep 14 12:30:02 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA03122
          for bugs-outgoing; Sat, 14 Sep 1996 12:30:02 -0700 (PDT)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA03116;
          Sat, 14 Sep 1996 12:30:01 -0700 (PDT)
Resent-Date: Sat, 14 Sep 1996 12:30:01 -0700 (PDT)
Resent-Message-Id: <199609141930.MAA03116@freefall.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, dillon@backplane.com
Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA03013
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 14 Sep 1996 12:26:17 -0700 (PDT)
Received: (dillon@localhost) by apollo.backplane.com (8.7.5/8.6.5) id MAA25882; Sat, 14 Sep 1996 12:26:11 -0700 (PDT)
Message-Id: <199609141926.MAA25882@apollo.backplane.com>
Date: Sat, 14 Sep 1996 12:26:11 -0700 (PDT)
From: dillon@backplane.com
Reply-To: dillon@backplane.com
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.2
Subject: kern/1610: mmap() of unassociated memory + mlock() can == kernel panic
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         1610
>Category:       kern
>Synopsis:       mmap() of unassociated memory + mlock() can == kernel panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 14 12:30:00 PDT 1996
>Last-Modified:
>Originator:     Matthew Dillon
>Organization:
self
>Release:        FreeBSD 2.1-STABLE i386
>Environment:

	Pentium class machine, 64 MBytes of ram, Adaptec PCI SCSI

>Description:

	If I use mmap() to map a large (16 or 32 MBytes) amount of
	unassociated memory, then use mlock() to lock it, touching
	the memory will result in a kernel panic... something about
	a page directory missing (sorry, don't have the exact error).

	However, if I touch the memory BEFORE locking it, I can then
	lock the memory and use it normally.

	I believe the problem may be due to mmap() mapping the pages
	as zero-fill.  When you allocate more then one segment's worth
	of memory, the page table sharing is probably generating
	a condition that the system cannot handle when the memory
	is touched for the first time AFTER being locked.

>How-To-Repeat:

	mmap a large shared read-write area, unassociated with any file,
	that is larger then or equal to 16 MBytes on an unloaded
	machine.

	do not touch the allocated memory yet.

	lock the entire memory (make sure your resource limits are set
	such that it allows you to lock the entire area).

	write to a random page or pages in the memory area.  The kernel
	will panic with a missing page directory fault or something
	similiar.

>Fix:
	
	

>Audit-Trail:
>Unformatted: