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-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Paul B Mahol]

On 7/4/09, Alexander Best <alexbestms@...> 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
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Nate Eldredge-3]

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
neldredge@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[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:
> ...
> [EINVAL]
>    The len argument is 0."


> --

> Nate Eldredge
> neldredge@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Dag-Erling Smørgrav]

"Paul B. Mahol" <onemda@...> 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 - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Bob Bishop]

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
rb@...




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

[Dag-Erling Smørgrav]

Bob Bishop <rb@...> writes:
> Dag-Erling Smørgrav <des@...> writes:
> > Allocating or mapping a zero-length region is not necessarily a bug.
> POSIX says it is, IIRC.

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

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[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
> rb@...



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

[jhb-3]

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
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[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.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[jhb-3]

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
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alan Cox-5]

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

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

[Mel Flynn-6]

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

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

[Mel Flynn-6]

On Sun, 19 Jul 2009 22:13:48 -0800, Mel Flynn
<mel.flynn+fbsd.hackers@...> wrote:

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

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