From owner-freebsd-stable  Mon Jun 14  0: 7:34 1999
Delivered-To: freebsd-stable@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 81AC814EBD; Mon, 14 Jun 1999 00:07:31 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id AAA06800;
	Mon, 14 Jun 1999 00:07:29 -0700 (PDT)
	(envelope-from dillon)
Date: Mon, 14 Jun 1999 00:07:29 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199906140707.AAA06800@apollo.backplane.com>
To: "David E. Cross" <crossd@cs.rpi.edu>
Cc: The Hermit Hacker <scrappy@hub.org>, freebsd-current@FreeBSD.ORG,
	freebsd-stable@FreeBSD.ORG, crossd@cs.rpi.edu
Subject: Re: MMAP() in STABLE/CURRENT ... 
References:  <199906140122.VAA02659@cs.rpi.edu>
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:Here's the code:
:
:#include <stdio.h>
:#include <stdlib.h>
:#include <unistd.h>
:#include <fcntl.h>
:#include <sys/types.h>
:#include <sys/mman.h>
:
:#define DBSIZE 733055625
:
:int main(void)
:{
:	int fd;
:	unsigned char *dbp;
:
:	fd=open(argv[1], O_CREAT | O_RDWR | O_TRUNC, 0600);
:	lseek(fd, DBSIZE -1, SEEK_SET);
:	write(fd, &fd, 1);
:	dbp=mmap(NULL, DBSIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
:	close (fd);
:	memset(dbp, 0, DBSIZE);
:	munmap(dbp, DBSIZE);
:	return 0;
:}
:}

    Someone asked me at USENIX what would happen if the filesystem filled
    up due to someone mmap'ing a file shared and then filled in its holes 
    by modifying the mmaping.

    In your tests, are you intentionally filling up the filesystem?  You
    appear to be writing a rather large file - 733MB.  

    I'm just trying to narrow down where the bug is... the system isn't
    supposed to panic or deadlock even if you do fill up the filesystem.

    Your test program may also be hitting another known bug:  If you dirty
    the pages underlying a mapped file the system does not currently limit
    the number of pages that can be dirtied.  It is possible to eat up all
    available memory and cause a deadlock to occur when the system is unable
    to write the pages out to the file due to blocking on the access to the
    file's indirect blocks.  Actually, I think this is the more likely 
    scenario.  This bug is already on my list.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



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