Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Sep 2019 21:36:15 +0000
From:      bugzilla-noreply@freebsd.org
To:        testing@freebsd.org
Subject:   [Bug 211924] lib/libc/sys/mmap_test:mmap_truncate_signal fails with SIGSEGV instead of SIGBUS
Message-ID:  <bug-211924-32464-vRxi8Py097@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-211924-32464@https.bugs.freebsd.org/bugzilla/>
References:  <bug-211924-32464@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211924

Jilles Tjoelker <jilles@FreeBSD.org> changed:

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

--- Comment #5 from Jilles Tjoelker <jilles@FreeBSD.org> ---
I think FreeBSD is wrong here. Reading the mmap page of SUSv4tc2 XSH 3 Syst=
em
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 s=
ize
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 wro=
ng.
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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211924-32464-vRxi8Py097>