Re: PROBLEM: pthread-safety bug in write(2) on Linux 2.6.x

[Dan Bonachea <bonachead@comcast.net>]

At 02:50 PM 4/13/2006, Alan Cox wrote:
> The only serious case historically has been O_APPEND which does have
> pretty precise semantics. Nowdays we also have pread/pwrite which have
> pretty clear semantics and deal with threading. The O_APPEND case is
> very important to get correct and 2.4 certainly did so.
...
> As such I belive that the O_APPEND case must be kept locked properly and
> the non O_APPEND cases are already correctly handled by the kernel. That
> seems to argue for f_pos serialization on O_APPEND only.

I agree that O_APPEND is important to get correct. However, would that also 
handle the specific case of stdout redirection to a file? (ie "a.out > 
result", not just "a.out >> result" - the latter incidentally does not 
currently seem to fail, at least with my tests)

> Looking at the spec it says the following
>
> "If the O_APPEND flag of the file status flags is set, the file offset
> shall be set to the end of the file prior to each write and no
> intervening file modification operation shall occur between changing the
> file offset and the write operation."
>
> This is what 2.4 took great paints to guarantee for file writes. Now in
> actual fact no OS I know of implements this to the extreme (mmap) but
> does for the other cases.
>
> Outside of O_APPEND the specification says only that
> - The write starts at the file position
> - The file position is updated before the syscall returns
>
> It makes no other guarantee I can see.

The POSIX 1003.1-2001 spec seems to provide a very clear guarantee of 
thread-safety behavior wrt threads:

2.9.1 Thread-Safety
All functions defined by this volume of IEEE Std 1003.1-2001 shall be 
thread-safe, except that the following functions need not be thread-safe.
   <omitted list of functions, which does not include write>
Implementations shall provide internal synchronization as necessary in order 
to satisfy this
requirement.
...
2.9.7 Thread Interactions with Regular File Operations
All of the functions chmod( ), close( ), fchmod( ), fcntl( ), fstat( ), 
ftruncate( ), lseek( ), open( ), read( ), readlink( ), stat( ), symlink( ), 
and write( ) shall be atomic with respect to each other in the effects 
specified in IEEE Std 1003.1-2001 when they operate on regular files. 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.

Unless I'm missing something, that doesn't leave much ambiguity regarding 
what's required for POSIX compliance on this issue (although I'm not sure 
POSIX compliance is the right metric).

Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/