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>]

The following reply was made to PR kern/48910; it has been noted by GNATS.

From: Garrett Cooper <yaneurabeya%gmail.com@localhost>
To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>
Cc: kern-bug-people%netbsd.org@localhost, 
        "gnats-admin%netbsd.org@localhost" <gnats-admin%netbsd.org@localhost>, 
"netbsd-bugs%netbsd.org@localhost" <netbsd-bugs%netbsd.org@localhost>
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 14:33:31 -0700

 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