Minutes of the 24 July 2014 Teleconference

[Andrew Josey]

All
Enclosed are the minutes of the 24 July 2014 Teleconference. The next call is in two weeks time
regards
Andrew
-----

Minutes of the 24 July 2014 Teleconference Austin-668 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 25 July 2014

Attendees:
Andrew Josey, The Open Group (joined 30 mins late)
Richard Hansen, BBN (had to leave at 1 hour)
Don Cragun, IEEE PASC OR
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Geoff Clare, The Open Group
Joerg Schilling FOKUS Fraunhofer
Mark Ziegast, SHware Systems
Martin Rehak, Oracle
David Clissold, IBM (missed 0:18 to 0:57 meeting time)
Matthew Dempsky, OpenBSD

Apologies
Mark Brown, Canonical
Eric Blake, Red Hat

* General news
Approval of the PAR within the PASC SEC is still stalled while some
procedural issues related to SEC membership are resolved.

* Outstanding actions

+Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN
http://austingroupbugs.net/view.php?id=251
Don has an action to produce a proposal.

+Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN
http://austingroupbugs.net/view.php?id=561
Eric has an action to update the proposal.

+Bug 0000573: Please add '+' to the portable filename character set OPEN
http://austingroupbugs.net/view.php?id=573
Joerg has an action to prepare a proposed change.

+Bug 0000592: consistent use of struct timespec OPEN
http://austingroupbugs.net/view.php?id=592
Jim had provided additional information in bugnote 1627.
This was discussed and Jim took an action to provide further information.

+Bug 0000598: OH shading and new interfaces OPEN
http://austingroupbugs.net/view.php?id=598
Eric has an action to propose a new solution with self-contained headers.

+Bug 0000517: EBNF support OPEN
http://austingroupbugs.net/view.php?id=517
Action on Joerg to look at this.

+Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe
OPEN
http://austingroupbugs.net/view.php?id=633
We noted that feedback has settled down on the mailing list, and
will discuss next session.

+Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer
are insufficiently specified OPEN
http://austingroupbugs.net/view.php?id=657
Eric has an action to propose wording to clarify the behavior for
fmemopen(), and also to contact the glibc developers to get their
feedback.

+Bug 0000658: Undefined/unspecified behavior clauses in description of
open have race conditions OPEN
http://austingroupbugs.net/view.php?id=658
It was noted that there is some overlap with changes in TC1. Eric took an
action to update the proposal to resolve the overlaps appropriately.

+Bug 0000615: pthread_setcancelstate should be async-signal-safe OPEN
http://austingroupbugs.net/view.php?id=615
We now have reports on AIX and Apple. Jim to report back on whether
pthread_cancelstate() is async-signal-safe on Solaris. Andrew to ask
HP whether pthread_cancelstate() is async-signal-safe on HP-UX.


+Bug 0000672: Necessary step(s) to synchronize filename operations on disk
OPEN
http://austingroupbugs.net/view.php?id=672

Geoff has a new proposed resolution in note 1618. Decided to solicit input
from FS developers. Eric to go to Linux, David to AIX and Jim to Solaris.
Jim has completed his action (see bugnote 1691).
Andrew should chase HP and Apple for input.

+Bug 0000663: Specification of str[n]casecmp is ambiguous reopened
http://austingroupbugs.net/view.php?id=663

Action on David to follow up with the IBM developers about the EBCDIC
collation sequence.

Bug 696 either NAME_MAX shouldn't be optional, or readdir_r() needs clarification
http://www.austingroupbugs.net/view.php?id=696

Don has an action to propose a resolution.

Bug 0000721: Internal storage vs static storage OPEN
http://austingroupbugs.net/view.php?id=721

This item is still open.

Bug 0000375: Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef OPEN
http://austingroupbugs.net/view.php?id=375

This is still left open due to discussions pending on the reflector.

Bug 0000789: Add set -o pipefail OPEN
http://austingroupbugs.net/view.php?id=789



* Current Business

Bug #853: references to tables broken, says "Batch Services Summary" Accepted
http://austingroupbugs.net/view.php?id=853
Confirmed as a bug. Andrew has now made the correction to the html translation.

Bug #851: pthread_atfork orphans handlers in unloaded shared libraries OPEN
http://www.austingroupbugs.net/view.php?id=851

Action item for Andrew from 17/7/2014: See if anyone familiar with the history
of this can provide some background.

Andrew reported back by email, that the routines were
introduced by the Aspen Group (Sun, HP, Digital) in 1995/1996. Unclear
that we have a named individual we can reach.

Bug #852: Clarify MAP_FIXED semantics when replacing existing locked mappings OPEN
http://www.austingroupbugs.net/view.php?id=852

This item was discussed at length, but not yet closed.

Feedback from AIX team:
MAP_FIXED will first remove any mapping that intersects the requested address range. This includes unlocking it first.
If the mapping succeeds *and* mlockall(MCL_FUTURE) is in effect,
then we will relock the new mapping. If it is not in effect, then
we won't.


Feedback from AIX team:

MAP_FIXED will first remove any mapping that intersects the
requested address range. This includes unlocking it first.

If the mapping succeeds *and* mlockall(MCL_FUTURE) is in
effect, then we will relock the new mapping. If it is not
in effect, then we won't.

Some proposed changes were drafted in the etherpad:
(see http://posix.rhansen.org:9001/p/2014-07-24 for the full details)

For Issue 7 TC2:

On page 1324 lines 43807-43808 (mmap() description), change:

If a MAP_FIXED request is successful, the mapping established
by mmap() replaces any previous mappings for the pages in the
range [pa,pa+len) of the process.

to:

If a MAP_FIXED request is successful, then any previous mappings
[ML|MLR]or memory locks[/] associated with the address range
[pa,pa+len) shall be removed, as if by an appropriate call to
munmap(), before the new mapping is established.

On page 1326 lines 43928-43937 (mmap() rationale) change:

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 munmap() before an
mmap() 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.

to:

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 munmap() before an mmap() to the same address
range. This volume of POSIX.1-2008 specifies that the new
mapping replaces any existing mappings (implying an automatic
munmap() on the address range) , following existing practice
in this regard.

TODO: Try to keep the term "overlay mapping"

On page 1328 line 43983 (mmap() rationale) change MEMLOCK_FUTURE to MCL_FUTURE.

There is a part in the rationale at page 1326 line 43928 that should be reworked.

For the Rationale part it seems there are 3 cases:

The current behavior where an overlay request creates separate mapping silently

The behavior discussed where an overlay request creates separate
mapping but provides an alternate return value indicating a
previous mapping was overlaid and split up
as a fairly easy to implement extension

The third behavior where two mappings are made when address
ranges overlap, but does not invalidate the previous mapping,
as a future directions option. As the first mapping would still
be valid it seems reasonable that any locks
established on it would not be released in this type of
implementation, in keeping with goal of making new mapping
as quickly as practical (the "as few system calls as possible"
part)


This will be continued on the next call

Next Steps
----------
The next call is on August 7, 2014 (a Thursday)

There will be no call on July 31st.


Calls are anchored on US time. (8am Pacific)

This call will be for the regular 90 minutes.

http://austingroupbugs.net

An IRC channel will be available for the meeting
irc://irc.freenode.net/austingroupbugs

An etherpad is usually up for the meeting, with a URL using the date format as below:

http://posix-aA9aGynHYqB/thfjNshNs9i2O/***@public.gmane.org:9001/p/201x-mm-dd
password=2115756#

--------
Andrew Josey The Open Group
Austin Group Chair Apex Plaza, Forbury Road
Email: a.josey-7882/***@public.gmane.org Reading,Berks.RG1 1AX,England
Tel:[phone] US fax: [phone]
Mobile:[phone] UK fax: [phone]