This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: MMAP issue on cygwin
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Neil Booth <neil at daikokuya dot demon dot co dot uk>, gcc at gcc dot gnu dot org
- Date: Tue, 1 Jan 2002 12:18:43 -0800
- Subject: Re: MMAP issue on cygwin
- References: <20011219074114.A4605@daikokuya.demon.co.uk> <87bsgjbqk6.fsf@deneb.enyo.de> <20020101191113.GB9846@codesourcery.com> <87vgelkgzm.fsf@deneb.enyo.de>
On Tue, Jan 01, 2002 at 08:29:01PM +0100, Florian Weimer wrote:
> >
> > The system always zero-fills any partial page at the end of an
> > object. Further, the system never writes out any modified
> > portions of the last page of an object that are beyond its
> > end. References within the address range starting at pa and
> > continuing for len bytes to whole pages following the end of
> > an object result in delivery of a SIGBUS signal.
>
> AFAIK, on GNU/Linux on x86, SIGSEGV is delivered (if a signal is
> delivered at all).
I get SIGBUS with a 2.2.20 kernel (test program attached). But this
is basically irrelevant; cpplib doesn't depend on that part of the
behavior, only the zero-filling.
> Anyway, what can you gain, in terms of implementation maintainability
> and efficiency, if you rely on a certain behavior of mmap() in these
> border cases?
Not having to continually test the current buffer pointer against the
file size in the fast path of the lexer. It simplifies the code quite
a bit. I haven't benchmarked it but I would expect a small but
measurable performance improvement.
> (Just an example of what can go wrong: IIRC, the INN optimization for
> the active file breaks if the file size is a multiple of the page size
> (and the above semantics are implemented.)
When the file size is a multiple of the page size, we don't use mmap.
I think the proper resolution to this issue is to chuck out the
elaborate tests in aclocal.m4 that try to pin down whether or not mmap
works. Instead, check whether the function exists at all, and then
blacklist systems known not to work. I believe that'd be just cygwin.
> > If you think about it, it is a security hole to do anything else.
>
> I agree, but at least one file system author told me that he is not
> willing to zero partial pages because of performance concerns, but I
> suppose the problem is fixed now.
They're wrong. Security is more important than performance in a
general-purpose operating system.
zw
#include <stddef.h>
#include <sys/types.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int
main(void)
{
int fd;
char *map;
size_t pagesize = getpagesize();
fd = open("/tmp/test.file", O_RDWR|O_CREAT, 0666);
unlink("/tmp/test.file");
ftruncate(fd, pagesize);
map = mmap(0, pagesize*2, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
map[0] = 'a';
map[pagesize - 1] = 'b';
map[pagesize] = 'c';
return 0;
}