From owner-freebsd-current  Sun Feb 28  4:53:18 1999
Delivered-To: freebsd-current@freebsd.org
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9])
	by hub.freebsd.org (Postfix) with ESMTP id 81AC014ED2
	for <current@FreeBSD.ORG>; Sun, 28 Feb 1999 04:53:15 -0800 (PST)
	(envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id XAA24877;
	Sun, 28 Feb 1999 23:52:57 +1100
Date: Sun, 28 Feb 1999 23:52:57 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199902281252.XAA24877@godzilla.zeta.org.au>
To: current@FreeBSD.ORG, pangolin@home.com
Subject: Re: lockmgr panic with mmap()
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>The attached program sometimes causes a lockmgr panic. I do not think is always
>did. I am running 4.0-CURRENT form Feb 19.
>
>The trace is:
>        panic lockmgr: locking against self
>        lockmgr
>        mv_map_growstack
>        grow_stack
>        trap_pfault
>        trap
>        calltrap
>        subyte
>        syscall
>        ...
>        
>A command on a running image such as this usually does it, though I do not know what
>conditions are neccessary:
>
>        fincore /usr/local/netscape-4.5/communicator-4.5.bin

Here is a simpler example.

---
#include <sys/param.h>
#include <sys/mman.h>

#include <err.h>
#include <stdlib.h>

#define	SIZE		(32 * 1024 * 1024)

int
main(void)
{
	void *p;
	char vec[SIZE / PAGE_SIZE];

	p = malloc(SIZE);
	if (mincore(p, SIZE, vec) != 0)
		err(1, "mincore");
	return (0);
}
---

mincore() locks the vmspace map, and initialises vec[] a byte at a time
using subyte().  When vec[] is sufficiently large, it is not all in core
initially and a page fault occurs in subyte().  The new stack growing
code locks the vmspace map early and panics.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message