[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/48910: msync(2) should return ENOMEM on unmapped pages per POSIX; test criteria in t_msync incorrect
On Mon, Jun 16, 2014 at 10:10 PM, David Holland
> 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
> 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 (
[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
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 :)!
Main Index |
Thread Index |