This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MMAP issue on cygwin


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;
}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]