Re: kern/48910: msync(2) should return ENOMEM on unmapped pages per POSIX; test criteria in t_msync incorrect

[Garrett Cooper <yaneurabeya%gmail.com@localhost>]

On Mon, Jun 16, 2014 at 10:10 PM, David Holland
<dholland-bugs%netbsd.org@localhost> wrote:
> The following reply was made to PR kern/48910; it has been noted by GNATS.
>
> From: David Holland <dholland-bugs%netbsd.org@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc:
> Subject: Re: kern/48910: msync(2) should return ENOMEM on unmapped pages per
>  POSIX; test criteria in t_msync incorrect
> Date: Tue, 17 Jun 2014 05:07:12 +0000
>
>  On Sun, Jun 15, 2014 at 02:20:00PM +0000, Martin Husemann wrote:
>   >  We could go over the other callers of uvm_map_clean() instead and change
>   >  the return value in there as well - what do others think?
>
>  I think repurposing ENOMEM for this is a POSIX_MISTAKE; not only does
>  it have a well-established differeng meaning, but I don't see any
>  reason trying to sync nonexistent memory shouldn't produce EFAULT or
>  even SIGSEGV.
>
>  ...so while I suppose we should be compliant, I don't think it's a
>  good idea to go around changing it elsewhere.

The manpages for some of the calls (e.g. *madvise(2), etc) don't state
what the behavior should be though for cases where POSIX uses ENOMEM
to denote exceptional "out of bounds" address conditions. David
brought up a good point: should it be EFAULT or ENOMEM, and if EFAULT,
shouldn't this variance be documented in the manpage as not strictly
adhering to the POSIX standard?

I did some tracking based on what Martin provided and I believe
(please correct me if I'm wrong :/!!)...

- mlock follows POSIX by returning ENOMEM.
- mprotect might not be POSIX compliant with respect to the memory
boundary requirement, like msync (
http://pubs.opengroup.org/onlinepubs/009696799/functions/mprotect.html
):

[ENOMEM]Addresses in the range [addr,addr+len) are invalid for the
address space of a process, or specify one or more pages which are not
mapped.

Looking around that file and then studying the NetBSD/POSIX manpages a
bit, mmap seems suspicious because it relies on the range_check static
function for checking the range of the pages and range_check returns
EFBIG for mmap which isn't documented in mmap(2) for NetBSD (and it's
not in POSIX either). I'm not 100% clued into NetBSD kernel internals
(only FreeBSD) so I need some help here -- does EFBIG get punted back
to userland as EFAULT?

Thank you in advance for the help :)!
-Garrett