mmap/munmap with zero length

[Alexander Best]

i'm wondering why mmap and munmap behave differently when it comes to a length
argument of zero. allocating memory with mmap for a zero length file returns a
valid pointer to the mapped region.

munmap however isn't able to remove a mapping with no length.

wouldn't it be better to either forbid this in mmap or to allow it in munmap?

cheers.
alex
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Paul B. Mahol]

On 7/4/09, Alexander Best <alexb...@math.uni-muenster.de> wrote:
> i'm wondering why mmap and munmap behave differently when it comes to a
> length
> argument of zero. allocating memory with mmap for a zero length file returns
> a
> valid pointer to the mapped region.

there is V flag for malloc.conf

>
> munmap however isn't able to remove a mapping with no length.
>
> wouldn't it be better to either forbid this in mmap or to allow it in
> munmap?

It wouldn't improve badly written program.

--
Paul

[Nate Eldredge]

On Sun, 5 Jul 2009, Alexander Best wrote:

> i'm wondering why mmap and munmap behave differently when it comes to a length
> argument of zero. allocating memory with mmap for a zero length file returns a
> valid pointer to the mapped region.
>
> munmap however isn't able to remove a mapping with no length.
>
> wouldn't it be better to either forbid this in mmap or to allow it in munmap?

POSIX has an opinion:

http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html

"If len is zero, mmap() shall fail and no mapping shall be established."

http://www.opengroup.org/onlinepubs/9699919799/functions/munmap.html

"The munmap() function shall fail if:
..
[EINVAL]
The len argument is 0."

--

Nate Eldredge
neld...@math.ucsd.edu

[Alexander Best]

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.

alex

Nate Eldredge schrieb am 2009-07-05:
> On Sun, 5 Jul 2009, Alexander Best wrote:

> >i'm wondering why mmap and munmap behave differently when it comes
> >to a length
> >argument of zero. allocating memory with mmap for a zero length
> >file returns a
> >valid pointer to the mapped region.

> >munmap however isn't able to remove a mapping with no length.

> >wouldn't it be better to either forbid this in mmap or to allow it
> >in munmap?

> POSIX has an opinion:

> http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html

> "If len is zero, mmap() shall fail and no mapping shall be
> established."

> http://www.opengroup.org/onlinepubs/9699919799/functions/munmap.html

> "The munmap() function shall fail if:

> ...

[Dag-Erling Smørgrav]

"Paul B. Mahol" <one...@gmail.com> writes:
> there is V flag for malloc.conf

Irrelevant.

> It wouldn't improve badly written program.

Allocating or mapping a zero-length region is not necessarily a bug.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dag-Erling Smørgrav]

Bob Bishop <r...@gid.co.uk> writes:

> Dag-Erling Smørgrav <d...@des.no> writes:
> > Allocating or mapping a zero-length region is not necessarily a bug.

> POSIX says it is, IIRC.

For mmap(), yes; for malloc(), no.

[Alexander Best]

so. doesn't that mean that actually freebsd's mmap implementation needs to be
changed in order to return an error if one tries to allocate space with len=0?

alex

Bob Bishop schrieb am 2009-07-06:
> Hi,

> On 6 Jul 2009, at 13:14, Dag-Erling Sm�rgrav wrote:

> >Allocating or mapping a zero-length region is not necessarily a bug.

> POSIX says it is, IIRC.

> --
> Bob Bishop
> r...@gid.co.uk

[John Baldwin]

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

--
John Baldwin

[Tijl Coosemans]

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.

[John Baldwin]

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.

--
John Baldwin

[Alan Cox]

John Baldwin 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.
>
>

I have no objections to "uap->len == 0" (without the cast).

Alan

[Mel Flynn]

On Mon, 13 Jul 2009 16:39:09 -0400, John Baldwin <j...@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

Sent from webmail, so excuse any formatting issues.
--
Mel