Minutes of the 15th December 2022 Teleconference Austin-1280 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 16th December 2022 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Geoff Clare, The Open Group Mark Ziegast, SHware Systems Dev. Tom Thompson, IEEE Eric Blake, Red Hat, The Open Group OR Apologies: Andrew Josey, The Open Group Eric Ackermann, HPI, University of Potsdam * General news A reminder that there are no more meetings until January 5th. * Carried Forward This section trimmed -- see Austin/1264 Bug 1593: specify whether struct sockaddr_un.sun_path can be a flexible array member OPEN https://austingroupbugs.net/view.php?id=1593 Wait for Eric to complete his action on bug 561 Bug 1406: clarification of SEEK_END when current pointer doesn't match buffer size OPEN https://austingroupbugs.net/view.php?id=1406 Actions carried forward: ACTION: Andrew to contact Rich Felker (dalias) and Alan Coopersmith (Solaris) for feedback. Completed ACTION: Eric B to contact glibc folks. Bug 1616: Standardize mktemp utility OPEN https://austingroupbugs.net/view.php?id=1616 We will need a sponsor; it is not suitable for inclusion in Issue 8. ACTION: Eric to ask The Open Group to sponsor adding the mktemp utility (for Issue 9). Bug 1291: Add method to obtain pthread attributes OPEN https://austingroupbugs.net/view.php?id=1291 Needs additional details and sponsor for Issue 9 Bug 1616: Standardize mktemp utility OPEN https://austingroupbugs.net/view.php?id=1616 Will need a sponsor; not suitable for inclusion in Issue 8. AI Eric to ask The Open Group to sponsor adding the mktemp utility (for Issue 9). * Current Business Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN http://austingroupbugs.net/view.php?id=251 (brought forward) Don has an action to produce a proposal. Bug 768: add "fd-private" POSIX locks to spec Accepted as Marked https://austingroupbugs.net/view.php?id=768 This item is tagged for Issue 8. On page 48 line 1558 section 3.138 File Lock, change: A lock obtained on a file through the use of fcntl() or lockf(). to: Any advisory lock, including a record lock (see [xref to Record Lock]), obtained on a file for the purpose of coordinating transactions among cooperating processes accessing the same file with the same lock type. See also [xref to OFD-Owned File Lock] and [xref to Process-Owned File Lock]. Note: All file locks created by interfaces defined in this standard are record locks; however, implementations commonly also support a file lock extension interface named flock(), that creates non-record locks (that is, a file lock that can only be held on the whole file). Note: Advisory locks do not prevent a process with sufficient access permissions from modifying the file without taking locks. After page 61 line 1905 section 3 Definitions, add: 3.NNN OFD-Owned File Lock A record lock owned by an open file description. OFD-owned file locks are obtained through the use of fcntl() with F_OFD_SETLK or F_OFD_SETLKW. Whenever a file descriptor associated with the owning open file description is inherited these locks remain in effect. OFD-owned file locks are automatically released on the last close of the open file description. These locks are only shared among file descriptors associated with the same open file description. Thus, a multi-threaded process can use multiple open file descriptions (such as by open()) to create independent OFD-owned locks that can then be used to coordinate access patterns to the same file, while multiple file descriptors associated with the same file description (such as by dup()) share lock actions among all other descriptors associated with the same file description. After page 68 line 2126 section 3 Definitions, add: 3.NNN Process-Owned File Lock A record lock owned by a process. Process-owned file locks are obtained through the use of fcntl() with F_SETLK or F_SETLKW, or the use of lockf(). Process-owned file locks are not inherited by child processes, but are preserved across the exec*() family of functions. A process-owned file lock is released when the process exits, or when any file descriptor in the process referring to the same file is closed (even if via a different open file description). Locks are shared among all file descriptions referring to the same file in the process, making the use of process-owned file locks unsuitable for use for coordination of record access among multiple threads in a process. (Note to the editor: also move 3.276 Process-To-Process Communication to after this new definition.) After page 70 line 2165 section 3 Definitions, add: 3.NNN Record Lock A file lock held on a record within a file. A record lock can be used to lock a whole file by specifying a special record with starting offset zero and length zero. (This special record extends to any future end-of-file, not just the current end-of-file.) This includes an OFD-owned file lock (see [xref to OFD-Owned File Lock]) or a process-owned file lock (see [xref to Process-Owned File Lock]). It is unspecified whether an implementation will detect and prevent deadlocks caused by two competing lock owners holding separate locks where each tries to obtain a lock that is blocked by the other's lock. On page 229 line 7920 section , change: F_GETLK Get record locking information. F_SETLK Set record locking information. F_SETLKW Set record locking information; wait if blocked. to: F_GETLK Get information about file locks. F_SETLK Set a process-owned file lock. F_SETLKW Set a process-owned file lock; wait if blocked. F_OFD_GETLK Get information about file locks. F_OFD_SETLK Set an OFD-owned file lock. F_OFD_SETLKW Set an OFD-owned file lock; wait if blocked. On page 231 line 8019 section , change l_pid text from: Process ID of the process holding the lock; returned with F_GETLK. to: For a process-owned file lock, ignored on input or the process ID of the owning process on output; for an OFD-owned file lock, zero on input or (pid_t)-1 on output. On page 506 line 17959 section 2.9.5.2 Cancellation Points, change: When the cmd argument is F_SETLKW. to: When the cmd argument is F_SETLKW or F_OFD_SETLKW. On page 667 line 23031 section close(), change: All outstanding record locks owned by the process on the file associated with the file descriptor shall be removed (that is, unlocked). to: All process-owned file locks that the calling process owns on the file associated with the file descriptor shall be unlocked. On page 776 line 26503 section exec, change: For any file descriptor that is closed for this reason, file locks are removed as a result of the close as described in close(). to: For any file descriptor that is closed for this reason, process-owned file locks that the calling process owns on the file associated with the file descriptor shall be unlocked as a result of the close, as described in close(). On page 811 line 27663 section fcntl(), change: F_GETLK Get any lock which blocks the lock description pointed to by the third argument, arg, taken as a pointer to type struct flock, defined in . The information retrieved shall overwrite the information passed to fcntl() in the structure flock. If no lock is found that would prevent this lock from being created, then the structure shall be left unchanged except for the lock type which shall be set to F_UNLCK. F_SETLK Set or clear a file segment lock according to the lock description pointed to by the third argument, arg, taken as a pointer to type struct flock, defined in . F_SETLK can establish shared (or read) locks (F_RDLCK) or exclusive (or write) locks (F_WRLCK), as well as to remove either type of lock (F_UNLCK). F_RDLCK, F_WRLCK, and F_UNLCK are defined in . If a shared or exclusive lock cannot be set, fcntl() shall return immediately with a return value of −1. F_SETLKW This command shall be equivalent to F_SETLK except that if a shared or exclusive lock is blocked by other locks, the thread shall wait until the request can be satisfied. If a signal that is to be caught is received while fcntl() is waiting for a region, fcntl() shall be interrupted. Upon return from the signal handler, fcntl() shall return −1 with errno set to [EINTR], and the lock operation shall not be done. to: F_GETLK Get any file lock which blocks the process-owned file lock description pointed to by the third argument, arg, taken as a pointer to type struct flock, defined in . The information retrieved shall overwrite the information passed to fcntl() in the structure flock. If no lock is found that would prevent this lock from being created, then the structure shall be left unchanged except for the lock type in l_type which shall be set to F_UNLCK. F_SETLK Set or clear a process-owned file lock according to the lock description pointed to by the third argument, arg, taken as a pointer to type struct flock, defined in . F_SETLK can establish shared (or read) locks (F_RDLCK) or exclusive (or write) locks (F_WRLCK), as well as to remove either type of lock (F_UNLCK). F_RDLCK, F_WRLCK, and F_UNLCK are defined in . If a shared or exclusive lock cannot be set, fcntl() shall return immediately with a return value of −1. F_SETLKW This command shall be equivalent to F_SETLK except that if a shared or exclusive lock is blocked by other locks, the thread shall wait until the request can be satisfied. If a signal that is to be caught is received while fcntl() is waiting for a region, fcntl() shall be interrupted. Upon return from the signal handler, fcntl() shall return −1 with errno set to [EINTR], and the lock operation shall not be done. F_OFD_GETLK Get any file lock which blocks the OFD-owned file lock description pointed to by the third argument, arg, taken as a pointer to type struct flock, defined in ; the application shall ensure that the l_pid member of the structure pointed to by arg is set to 0 on input. The information retrieved shall overwrite the information passed to fcntl() in the structure flock. If no lock is found that would prevent this lock from being created, then the structure shall be left unchanged except for the lock type in l_type which shall be set to F_UNLCK. F_OFD_SETLK Set or clear an OFD-owned file lock according to the lock description pointed to by the third argument, arg, taken as a pointer to type struct flock, defined in ; the application shall ensure that the l_pid member of the structure pointed to by arg is set to 0 on input. F_SETLK can establish shared (or read) locks (F_RDLCK) or exclusive (or write) locks (F_WRLCK), as well as to remove either type of lock (F_UNLCK). F_RDLCK, F_WRLCK, and F_UNLCK are defined in . If a shared or exclusive lock cannot be set, fcntl() shall return immediately with a return value of −1. F_OFD_SETLKW This command shall be equivalent to F_OFD_SETLK except that if a shared or exclusive lock is blocked by other locks, the thread shall wait until the request can be satisfied. If a signal that is to be caught is received while fcntl() is waiting for a region, fcntl() shall be interrupted. Upon return from the signal handler, fcntl() shall return −1 with errno set to [EINTR], and the lock operation shall not be done. At page 812 line 27696, change: The l_pid field is only used with F_GETLK to return the process ID of the process holding a blocking lock. After a successful F_GETLK request, when a blocking lock is found, the values returned in the flock structure shall be as follows: to: On input, the l_pid field shall be ignored for F_GETLK, F_SETLK and F_SETLKW; the application shall ensure that it is set to zero for F_OFD_GETLK, F_OFD_SETLK and F_OFD_SETLKW. It is set by F_GETLK and F_OFD_GETLK when identifying a blocking lock. After a successful F_GETLK or F_OFD_GETLK request, when a blocking lock is found, the values returned in the flock structure shall be as follows: At page 812 line 27704, change: l_pid Process ID of the process that holds the blocking lock. to: l_pid Process ID of the process that holds the blocking lock if the blocking lock is a process-owned file lock, or (pid_t)-1 if the blocking lock is an OFD-owned file lock. At page 812 line 22705, change: If the command is F_SETLKW and the process must wait for another process to release a lock, to: If the command is F_SETLKW or F_OFD_SETLKW and the thread needs to wait for a blocking lock to be released, At line 27714, change: There shall be at most one type of lock set for each byte in the file. Before a successful return from an F_SETLK or an F_SETLKW request when the calling process has previously existing locks on bytes in the region specified by the request, the previous lock type for each byte in the specified region shall be replaced by the new lock type. As specified above under the descriptions of shared locks and exclusive locks, an F_SETLK or an F_SETLKW request (respectively) shall fail or block when another process has existing locks on bytes in the specified region and the type of any of those locks conflicts with the type specified in the request. All locks associated with a file for a given process shall be removed when a file descriptor for that file is closed by that process or the process holding that file descriptor terminates. Locks are not inherited by a child process. A potential for deadlock occurs if a process controlling a locked region is put to sleep by attempting to lock the locked region of another process. If the system detects that sleeping until a locked region is unlocked would cause a deadlock, fcntl() shall fail with an [EDEADLK] error. to: Each byte in the file can be locked either with one or more shared locks (F_RDLCK) or with one exclusive lock (F_WRLCK). Before a successful return from an F_SETLK or an F_SETLKW request when the calling process has previously existing process-owned locks on bytes in the region specified by the request, the previous shared or exclusive lock for each byte in the specified region shall be replaced by the new shared or exclusive lock. An F_SETLK or an F_SETLKW request (respectively) shall fail or block when another process has existing process-owned locks, or any open file description (including the one associated with fildes) has existing OFD-owned locks, on bytes in the specified region and any of those locks conflicts with the requested lock. Before a successful return from an F_OFD_SETLK or an F_OFD_SETLKW request when the open file description associated with fildes has previously existing OFD-owned locks on bytes in the region specified by the request, the previous shared or exclusive lock for each byte in the specified region shall be replaced by the new shared or exclusive lock. An F_OFD_SETLK or an F_OFD_SETLKW request (respectively) shall fail or block when another open file description has existing OFD-owned locks, or any process (including the calling process) has existing process-owned locks, on bytes in the specified region and any of those locks conflicts with the requested lock. All process-owned locks associated with a file for a given process shall be removed when any file descriptor for that file is closed by that process (even if via a different open file description) or the process holding that file descriptor terminates. Process-owned locks shall not be inherited by a child process. All OFD-owned locks associated with a given open file description shall be removed when all file descriptors associated with that open file description have been closed (either directly or as a side-effect of, for example, process termination or FD_CLOEXEC). OFD-owned locks shall be shared across all file descriptors that are associated with the owning open file description, regardless of which process holds the file descriptor. A potential for deadlock occurs if a process or thread controlling a locked region is put to sleep by attempting to lock a region that has an existing conflicting lock. If the system detects that sleeping until a locked region is unlocked would cause a deadlock, fcntl() shall fail with an [EDEADLK] error. Deadlock detection may differ between process-owned locks and OFD-owned locks. [XSI]The interaction between fcntl() and lockf() locks is unspecified.[/XSI] On page 813 line 27729 section fcntl(), change: when the process has an existing lock in which l_len is 0 to: when the process (for F_SETLK and F_SETLKW) or open file description (for F_OFD_SETLK and F_OFD_SETLKW) has an existing lock in which l_len is 0 On page 813 line 27735 section fcntl(), change: shall be unspecified: F_SETFL, F_GETLK, F_SETLK, and F_SETLKW. to:  is unspecified: F_SETFL, F_GETLK, F_SETLK, F_SETLKW, F_OFD_GETLK, F_OFD_SETLK, and F_OFD_SETLKW. After page 813 line 27751 section fcntl(), add to RETURN VALUE: F_OFD_GETLK Value other than -1. F_OFD_SETLK Value other than -1. F_OFD_SETLKW Value other than -1. On page 813 line 27758 section fcntl(), change: [EACCES] or [EAGAIN] The cmd argument is F_SETLK; the type of lock (l_type) is a shared (F_RDLCK) or exclusive (F_WRLCK) lock and the segment of a file to be locked is already exclusive-locked by another process, or the type is an exclusive lock and some portion of the segment of a file to be locked is already shared-locked or exclusive-locked by another process. to: [EACCES] or [EAGAIN] The cmd argument is F_SETLK, the type of lock (l_type) is a shared (F_RDLCK) or exclusive (F_WRLCK) lock, and the requested lock cannot be set because it is blocked by an existing lock on the file. [EAGAIN] The cmd argument is F_OFD_SETLK, the type of lock (l_type) is a shared (F_RDLCK) or exclusive (F_WRLCK) lock, and the requested lock cannot be set because it is blocked by an existing lock on the file. On page 814 line 27763-27781 section fcntl() ERRORS, change: All occurrences of "F_GETLK, F_SETLK, or F_SETLKW" to "F_GETLK, F_SETLK, F_SETLKW, F_OFD_GETLK, F_OFD_SETLK, or F_OFD_SETLKW" All occurrences of "F_SETLK or F_SETLKW" to "F_SETLK, F_SETLKW, F_OFD_SETLK, or F_OFD_SETLKW" All other occurrences of "F_SETLKW" to "F_SETLKW or F_OFD_SETLKW" On page 814 line 27787 section fcntl() EDEADLK, change: The cmd argument is F_SETLKW, the lock is blocked by a lock from another process, and putting the calling process to sleep to wait for that lock to become free would cause a deadlock. to: The cmd argument is F_SETLKW or F_OFD_SETLKW, the type of lock (l_type) is a shared (F_RDLCK) or exclusive (F_WRLCK) lock, the requested lock is blocked by an existing lock on the file, and the system determines that waiting for that lock to be released would cause a deadlock. After page 816 line 27870 section fcntl(), add to APPLICATION USAGE: Record-locking should not be used in combination with buffered standard I/O streams (see [xref to 2.5]). Instead, non-buffered I/O should be used. Unexpected results may occur in processes that do buffering in the user address space. The process may later read/write data which is/was locked. Functions that operate on standard I/O streams are the most common source of such buffering. On page 886 line 30174 section fork(), change: File locks set by the parent process shall not be inherited by the child process. to: Process-owned file locks set by the parent process shall not be inherited by the child process. On page 1245 line 41729 section lockf(), change: The lockf() function shall lock sections of a file with advisory-mode locks. to: The lockf() function shall lock sections of a file with advisory-mode process-owned locks. On page 1245 line 41760 section lockf(), change: File locks shall be released on first close by the locking process of any file descriptor for the file. to: Process-owned file locks shall be released on first close by the locking process of any file descriptor for the file. On page 1449 line 48446,48457 section posix_spawn(), change: ... child process shall not inherit any file locks to: ... child process shall not inherit any process-owned file locks On page 2068 line 67057 section system(), change:  that file locks are not inherited to:  that process-owned file locks are not inherited On page 3669 line 127004 section D.2.3 Access to Data, change: The file-locking mechanism provides for advisory locking to: The file-locking mechanisms provide for advisory locking Bug 1617: what tsort should do with cycles? OPEN https://austingroupbugs.net/view.php?id=1617 We started on this item and will continue again next time. Next Steps ---------- The next calls are on: Thu 2023-01-05 (general bugs) Mon 2023-01-09 (general bugs) The calls are for 90 minutes Calls are anchored on US time. (8am Pacific) Please check the calendar invites for dial in details. Bugs are at: https://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/20xx-mm-dd (For write access this uses The Open Group single sign on, for those individuals with gitlab.opengroup.org accounts. Please contact Andrew if you need to be setup)