[Bug 211924] lib/libc/sys/mmap_test:mmap_truncate_signal fails with SIGSEGV instead of SIGBUS

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211924

Jilles Tjoelker <jilles at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jilles at FreeBSD.org

--- Comment #5 from Jilles Tjoelker <jilles at FreeBSD.org> ---
I think FreeBSD is wrong here. Reading the mmap page of SUSv4tc2 XSH 3 System
Interfaces:

] The system shall always zero-fill any partial page at the end of an
] object.  Further, the system shall never write out any modified portions
] of the last page of an object which are beyond its end. References
] within the address range starting at pa and continuing for len bytes to
] whole pages following the end of an object shall result in delivery of a
] SIGBUS signal.

As far as I understand, SEGV_MAPERR is for the case where no mapping exists for
the address, and SEGV_ACCERR is for the case where the access conflicts with
the prot parameter passed to mmap() (PROT_READ/PROT_WRITE/PROT_EXEC). The size
of the mapping is equal to the len parameter passed to mmap(), whether the
underlying object is that long or not.

So this does not mean that the change mentioned in 118304 is completely wrong.
There is only a problem for pages of the mapped region beyond the end of the
object.

By the way, the testcase is not POSIX-compliant either, since the
aforementioned mmap page also says:

] If the size of the mapped file changes after the call to mmap() as a
] result of some other operation on the mapped file, the effect of
] references to portions of the mapped region that correspond to added or
] removed portions of the file is unspecified.

-- 
You are receiving this mail because:
You are the assignee for the bug.