Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000695 [1003.1(2008)/Issue 7] System Interfaces Editorial Clarification Requested 2013-05-12 04:08 2024-06-11 08:52
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Rich Felker
Organization musl libc
User Reference
Section XSH 2.9.7 Thread Interactions with Regular File Operations
Page Number unknown
Line Number unknown
Interp Status ---
Final Accepted Text Note: 0005934
Summary 0000695: Missing/lax atomicity requirements for file operations
Description XSH 2.9.7 guarantees atomicity of most operations on file descriptors, but only when they refer to regular files. I suspect the main situation in which it was desired to leave atomicity unspecified was for actual input and output on non-regular files. However, this leaves ambiguous several potentially-important cases such as:

- Atomicity of ftruncate on shared memory objects.
- Atomicity of dup2 and fcntl F_DUPFD[_CLOEXEC].
- Atomicity of F_SETOWN on sockets.
- Atomicity of ownership/permissions changes on non-regular files.
Desired Action Provide a reasonable degree of atomicity requirements for file operations consistent with present real-world implementations, preferably enumerating the non-atomic cases rather than the atomic ones.

Document that, even in the case where file operations are not atomic, concurrent access does not result in undefined behavior, but may result in data interleaving (and possibly data loss if it's deemed important to leave that possibility open as well).
Tags issue8
Attached Files

- Relationships

-  Notes
(0005934)
geoffclare (manager)
2022-08-18 15:49

 On D2.1 page 509 line 18074 section 2.9.7, change:
Thread Interactions with Regular File Operations

All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-202x when they operate on regular files or symbolic links:

[function list]

If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them. The requirement on the close( ) function shall also apply whenever a file descriptor is successfully closed, however caused (for example, as a consequence of calling close( ), calling dup2( ), or of process termination).
to:
Thread Interactions with File Operations

All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-202x when they operate on files in the file hierarchy:

chmod( )
chown( )
creat( )
fchmod( )
fchmodat( )
fchown( )
fchownat( )
fstat( )
fstatat( )
ftruncate( )
futimens( )
lchown( )
link( )
linkat( )
lstat( )
open( )
openat( )
readlink( )
readlinkat( )
rename( )
renameat( )
stat( )
symlink( )
symlinkat( )
truncate( )
unlink( )
unlinkat( )
utimensat( )
utimes( )
[Note to the editor: arrange the above list into 5 columns]

If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them.

Except where specified otherwise, all of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-202x when they operate on file descriptors that are open, or being opened, to files in the file hierarchy:

close( )
dup2( )
dup3( )
fcntl( )
fstat( )
fstatat( )
ftruncate( )
futimens( )
lseek( )
open( )
openat( )
pread( )
read( )
readv( )
pwrite( )
write( )
writev( )
[Note to the editor: arrange the above list into 5 columns]

If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them. The requirement on the close( ) function shall also apply whenever a file descriptor is successfully closed, however caused (for example, as a consequence of calling close( ), calling dup2( ), or of process termination).

On D2.1 page 881 line 27641 section fcntl(), change:
set the process ID or process group ID specified to receive SIGURG signals
to:
atomically set the process ID or process group ID specified to receive SIGURG signals

After D2.1 page 1885 line 61391 section shm_open(), add a new paragraph:
The following functions shall be atomic with respect to each other in the effects specified in POSIX.1-202x when they operate on shared memory objects:

close(), ftruncate(), mmap(), shm_open(), shm_unlink()

If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them. The requirement on the close( ) function shall also apply whenever a file descriptor is successfully closed, however caused (for example, as a consequence of calling close( ), calling dup2( ), or of process termination).

- Issue History
Date Modified Username Field Change
2013-05-12 04:08 dalias New Issue
2013-05-12 04:08 dalias Status New => Under Review
2013-05-12 04:08 dalias Assigned To => ajosey
2013-05-12 04:08 dalias Name => Rich Felker
2013-05-12 04:08 dalias Organization => musl libc
2013-05-12 04:08 dalias Section => XSH 2.9.7 Thread Interactions with Regular File Operations
2013-05-12 04:08 dalias Page Number => unknown
2013-05-12 04:08 dalias Line Number => unknown
2022-08-18 15:49 geoffclare Note Added: 0005934
2022-08-18 15:50 geoffclare Interp Status => ---
2022-08-18 15:50 geoffclare Final Accepted Text => Note: 0005934
2022-08-18 15:50 geoffclare Status Under Review => Resolved
2022-08-18 15:50 geoffclare Resolution Open => Accepted As Marked
2022-08-18 15:50 geoffclare Tag Attached: issue8
2022-10-21 09:17 geoffclare Status Resolved => Applied
2024-06-11 08:52 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker