Date: Sun, 19 Jul 2009 23:07:27 -0800 From: Mel Flynn <mel.flynn+fbsd.hackers@mailing.thruhere.net> To: John Baldwin <jhb@freebsd.org> Cc: ahze@freebsd.org, Alan Cox <alc@freebsd.org>, freebsd-hackers@freebsd.org, ports@freebsd.org, Alexander Best <alexbestms@math.uni-muenster.de>, Nate Eldredge <neldredge@math.ucsd.edu>, Tijl Coosemans <tijl@ulyssis.org> Subject: Re: mmap/munmap with zero length Message-ID: <55daf4085f8ce3b4e383e36ba502bdec@sbmail.office-on-the.net> In-Reply-To: <d3ab62ffe922ca48ca81955ae44e71fb@sbmail.office-on-the.net> References: <permail-200907050732251e86ffa8000022a8-a_best01@message-id.uni-muenster.de> <200907131428.08923.jhb@freebsd.org> <200907132133.52217.tijl@ulyssis.org> <200907131639.10346.jhb@freebsd.org> <d3ab62ffe922ca48ca81955ae44e71fb@sbmail.office-on-the.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Sun, 19 Jul 2009 22:13:48 -0800, Mel Flynn
<mel.flynn+fbsd.hackers@mailing.thruhere.net> wrote:
> On Mon, 13 Jul 2009 16:39:09 -0400, John Baldwin <jhb@freebsd.org> wrote:
>> On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote:
>>> On Monday 13 July 2009 20:28:08 John Baldwin wrote:
>>> > On Sunday 05 July 2009 3:32:25 am Alexander Best wrote:
>>> >> so mmap differs from the POSIX recommendation right. the malloc.conf
>>> >> option seems more like a workaround/hack. imo it's confusing to have
>>> >> mmap und munmap deal differently with len=0. being able to
>>> >> succesfully alocate memory which cannot be removed doesn't seem
>>> >> logical to me.
>>> >
>>> > This should fix it:
>>> >
>>> > --- //depot/user/jhb/acpipci/vm/vm_mmap.c
>>> > +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c
>>> > @@ -229,7 +229,7 @@
>>> >
>>> > fp = NULL;
>>> > /* make sure mapping fits into numeric range etc */
>>> > - if ((ssize_t) uap->len < 0 ||
>>> > + if ((ssize_t) uap->len <= 0 ||
>>> > ((flags & MAP_ANON) && uap->fd != -1))
>>> > return (EINVAL);
>>>
>>> Why not "uap->len == 0"? Sizes of 2GiB and more (32bit) shouldn't cause
>>> an error.
>>
>> I don't actually disagree and know of locally modified versions of
> FreeBSD
>> that remove this check for precisely that reason.
>
> If this has hit the tree recently, I think it broke ccache.
>
> Since I've also done make delete-old-libs and was about to rebuild all my
> ports on my laptop, I'll investigate, as I'm not looking forward to doing
> this twice for all dependants of libtool :(.
>
> Failed to mmap
> /var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934
>
> kdump:
> 27934 ccache CALL open(0x28201280,O_RDONLY,<unused>0x1)
> 27934 ccache NAMI
> "/var/db/ccache/mel/tmp.cpp_stderr.smoochies.rachie.is-a-geek.net.27934"
> 27934 ccache RET open 4
> 27934 ccache CALL fstat(0x4,0xbfbfe7fc)
> 27934 ccache STRU struct stat {dev=105, ino=895320, mode=-rw-r--r-- ,
> nlink=1, uid=1003, gid=0, rdev=0, atime=1248069251, stime=1248069251,
> ctime=1248069251, birthtime=1248069251, size=0, blksize=4096, blocks=0,
> flags=0x0 }
> 27934 ccache RET fstat 0
> 27934 ccache CALL mmap(0,0,PROT_READ,MAP_PRIVATE,0x4,0,0)
> 27934 ccache RET mmap -1 errno 22 Invalid argument
Confirmed, attached patch fixes ccache. Probably should be patched in
patch-md4.
--
Mel
[-- Attachment #2 --]
--- hash.c.orig 2009-07-19 22:46:18.000000000 -0800
+++ hash.c 2009-07-19 22:46:13.000000000 -0800
@@ -67,12 +67,16 @@
close(fd);
fatal(__FUNCTION__);
}
- buf = mmap(NULL, stats.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
- if (buf == MAP_FAILED) {
- cc_log("Failed to mmap %s\n", fname);
- close(fd);
- fatal(__FUNCTION__);
- }
+ if( stats.st_size == 0 )
+ buf = NULL;
+ else {
+ buf = mmap(NULL, stats.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if (buf == MAP_FAILED) {
+ cc_log("Failed to mmap %s\n", fname);
+ close(fd);
+ fatal(__FUNCTION__);
+ }
+ }
hash_buffer(buf, stats.st_size);
close(fd);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55daf4085f8ce3b4e383e36ba502bdec>