[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kernel/975: mmap does not detect file changes.



The following reply was made to PR kernel/975; it has been noted by GNATS.

From: Artur Grabowski <art@stacken.kth.se>
To: anders@arnholm.nu
Cc: gnats@openbsd.org, tech@openbsd.org
Subject: Re: kernel/975: mmap does not detect file changes.
Date: 16 Nov 1999 07:31:44 +0100

 anders@arnholm.nu writes:
 
 > >Number:         975
 > >Category:       kernel
 > >Synopsis:       mmap does not detect file changes.
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    bugs
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   unknown
 > >Arrival-Date:   Mon Nov 15 15:10:01 MST 1999
 > >Last-Modified:
 > >Originator:     Anders Arnholm
 > >Organization:
 > Arnholm.nu
 > >Release:        OpenBSD 2.6
 > >Environment:
 > 	
 > 	System      : OpenBSD 2.6
 > 	Architecture: OpenBSD.i386
 > 	Machine     : i386
 > >Description:
 > 	The test program from cyrus imapd clamies that OpenBSD has no working
 > 	mmap function. I have studies the problem a little and minimized the
 > 	test program that finds teh error. The error seems to have to do with
 > 	that after haing changed a file, mmaped to the process, following
 > 	reads to the file handle does not find out that the file has been
 > 	changed even if the the has been changed on disk.
 > 
 > 	The error olny ocures if a page has been read from the first mmap and
 > 	that mmap is still active when the second mmap occurs. (I have a small
 > 	test program that does this).
 
 Yes, this is known, it's an antique problem. I have looked a bit on the
 unified buffer cache code written by Chuck Silvers for NetBSD that solves
 this. As soon as I have some time left I'll give it another shot and maybe
 help him to finish the code if it's not ready for prime-time.
 
 This is a big project, so anyone with experience from the kernel and some
 time should contact me if they want to help (besides correct mmap semantics,
 this should give us a nice performance boost), because there is a lot of
 small and big stuff that needs to be done here.
 
 //art