Austin Group Bug Tracker
2014-08-07 15:37:16 UTC
A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=852
======================================================================
Reported By: mdempsky
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 852
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Matthew Dempsky
Organization: OpenBSD
User Reference:
Section: mmap
Page Number:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
Line Number:
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-06-28 22:42 UTC
Last Modified: 2014-08-07 15:37 UTC
======================================================================
Summary: Clarify MAP_FIXED semantics when replacing existing
locked mappings
======================================================================
----------------------------------------------------------------------
(0002334) geoffclare (manager) - 2014-08-07 15:37
http://austingroupbugs.net/view.php?id=852#c2334
----------------------------------------------------------------------
Interpretation response
------------------------
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on
this. This is being referred to the sponsor.
Rationale:
-------------
We believe this is a clarification of existing practice; removing locks
when remapping existing regions is important to applications but the
standard does not clearly specify what was supposed to happen in this
case.
Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 1324 lines 43807-43808 (mmap() description), change:<blockquote>If
a MAP_FIXED request is successful, the mapping established by <i>mmap</i>()
replaces any previous mappings for the pages in the range
[<i>pa,pa+len</i>) of the process.</blockquote>
to:<blockquote>If a MAP_FIXED request is successful, then any previous
mappings [ML|MLR]or memory locks[/] associated with the address range
[<i>pa,pa+len</i>) shall be removed, as if by an appropriate call to
<i>munmap</i>(), before the new mapping is established.</blockquote>
On page 1326 lines 43928-43937 (mmap() rationale) change:<blockquote>If an
application requests a mapping that would overlay existing mappings in the
process, it might be desirable that an implementation detect this and
inform the application. However, the default, portable (not MAP_FIXED)
operation does not overlay existing mappings. On the other hand, if the
program specifies a fixed address mapping (which requires some
implementation knowledge to determine a suitable address, if the function
is supported at all), then the program is presumed to be successfully
managing its own address space and should be trusted when it asks to map
over existing data structures. Furthermore, it is also desirable to make
as few system calls as possible, and it might be considered onerous to
require an <i>munmap</i>() before an <i>mmap</i>() to the same address
range. This volume of POSIX.1-2008 specifies that the new mappings replace
any existing mappings, following existing practice in this
regard.</blockquote>
to:<blockquote>If an application requests a mapping that overlaps existing
mappings in the process, it might be desirable that an implementation
detect this and inform the application. However, if the program specifies
a fixed address mapping (which requires some implementation knowledge to
determine a suitable address, if the function is supported at all), then
the program is presumed to be successfully managing its own address space
and should be trusted when it asks to map over existing data structures.
Furthermore, it is also desirable to make as few system calls as possible,
and it might be considered onerous to require an <i>munmap</i>() before an
<i>mmap</i>() to the same address range. This volume of POSIX.1-2008
specifies that the new mapping replaces any existing mappings (implying an
automatic <i>munmap</i>() on the address range), following existing
practice in this regard. The standard developers also considered whether
there should be a way for new mappings to overlay existing mappings, but
found no existing practice for this.</blockquote>
On page 1328 line 43983 (mmap() rationale) change MEMLOCK_FUTURE to
MCL_FUTURE.
Issue History
Date Modified Username Field Change
======================================================================
2014-06-28 22:42 mdempsky New Issue
2014-06-28 22:42 mdempsky Name => Matthew Dempsky
2014-06-28 22:42 mdempsky Organization => OpenBSD
2014-06-28 22:42 mdempsky Section => mmap
2014-06-28 22:42 mdempsky Page Number =>
http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
2014-06-28 22:56 mdempsky Note Added: 0002293
2014-06-29 00:20 mdempsky Note Added: 0002294
2014-07-02 18:02 mdempsky Note Added: 0002301
2014-07-04 17:04 markh Note Added: 0002302
2014-07-05 10:13 mdempsky Note Added: 0002303
2014-07-17 16:26 joerg Note Added: 0002311
2014-07-17 17:02 joerg Note Edited: 0002311
2014-07-17 17:03 joerg Note Edited: 0002311
2014-07-17 18:16 mdempsky Note Added: 0002312
2014-07-18 07:48 martinr Note Added: 0002313
2014-07-18 16:03 mdempsky Note Added: 0002316
2014-07-24 16:36 martinr Note Added: 0002323
2014-08-07 15:37 geoffclare Note Added: 0002334
======================================================================
======================================================================
http://austingroupbugs.net/view.php?id=852
======================================================================
Reported By: mdempsky
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 852
Category: System Interfaces
Type: Clarification Requested
Severity: Editorial
Priority: normal
Status: New
Name: Matthew Dempsky
Organization: OpenBSD
User Reference:
Section: mmap
Page Number:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
Line Number:
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-06-28 22:42 UTC
Last Modified: 2014-08-07 15:37 UTC
======================================================================
Summary: Clarify MAP_FIXED semantics when replacing existing
locked mappings
======================================================================
----------------------------------------------------------------------
(0002334) geoffclare (manager) - 2014-08-07 15:37
http://austingroupbugs.net/view.php?id=852#c2334
----------------------------------------------------------------------
Interpretation response
------------------------
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on
this. This is being referred to the sponsor.
Rationale:
-------------
We believe this is a clarification of existing practice; removing locks
when remapping existing regions is important to applications but the
standard does not clearly specify what was supposed to happen in this
case.
Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
On page 1324 lines 43807-43808 (mmap() description), change:<blockquote>If
a MAP_FIXED request is successful, the mapping established by <i>mmap</i>()
replaces any previous mappings for the pages in the range
[<i>pa,pa+len</i>) of the process.</blockquote>
to:<blockquote>If a MAP_FIXED request is successful, then any previous
mappings [ML|MLR]or memory locks[/] associated with the address range
[<i>pa,pa+len</i>) shall be removed, as if by an appropriate call to
<i>munmap</i>(), before the new mapping is established.</blockquote>
On page 1326 lines 43928-43937 (mmap() rationale) change:<blockquote>If an
application requests a mapping that would overlay existing mappings in the
process, it might be desirable that an implementation detect this and
inform the application. However, the default, portable (not MAP_FIXED)
operation does not overlay existing mappings. On the other hand, if the
program specifies a fixed address mapping (which requires some
implementation knowledge to determine a suitable address, if the function
is supported at all), then the program is presumed to be successfully
managing its own address space and should be trusted when it asks to map
over existing data structures. Furthermore, it is also desirable to make
as few system calls as possible, and it might be considered onerous to
require an <i>munmap</i>() before an <i>mmap</i>() to the same address
range. This volume of POSIX.1-2008 specifies that the new mappings replace
any existing mappings, following existing practice in this
regard.</blockquote>
to:<blockquote>If an application requests a mapping that overlaps existing
mappings in the process, it might be desirable that an implementation
detect this and inform the application. However, if the program specifies
a fixed address mapping (which requires some implementation knowledge to
determine a suitable address, if the function is supported at all), then
the program is presumed to be successfully managing its own address space
and should be trusted when it asks to map over existing data structures.
Furthermore, it is also desirable to make as few system calls as possible,
and it might be considered onerous to require an <i>munmap</i>() before an
<i>mmap</i>() to the same address range. This volume of POSIX.1-2008
specifies that the new mapping replaces any existing mappings (implying an
automatic <i>munmap</i>() on the address range), following existing
practice in this regard. The standard developers also considered whether
there should be a way for new mappings to overlay existing mappings, but
found no existing practice for this.</blockquote>
On page 1328 line 43983 (mmap() rationale) change MEMLOCK_FUTURE to
MCL_FUTURE.
Issue History
Date Modified Username Field Change
======================================================================
2014-06-28 22:42 mdempsky New Issue
2014-06-28 22:42 mdempsky Name => Matthew Dempsky
2014-06-28 22:42 mdempsky Organization => OpenBSD
2014-06-28 22:42 mdempsky Section => mmap
2014-06-28 22:42 mdempsky Page Number =>
http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
2014-06-28 22:56 mdempsky Note Added: 0002293
2014-06-29 00:20 mdempsky Note Added: 0002294
2014-07-02 18:02 mdempsky Note Added: 0002301
2014-07-04 17:04 markh Note Added: 0002302
2014-07-05 10:13 mdempsky Note Added: 0002303
2014-07-17 16:26 joerg Note Added: 0002311
2014-07-17 17:02 joerg Note Edited: 0002311
2014-07-17 17:03 joerg Note Edited: 0002311
2014-07-17 18:16 mdempsky Note Added: 0002312
2014-07-18 07:48 martinr Note Added: 0002313
2014-07-18 16:03 mdempsky Note Added: 0002316
2014-07-24 16:36 martinr Note Added: 0002323
2014-08-07 15:37 geoffclare Note Added: 0002334
======================================================================