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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, 13 Apr 2006, Dan Bonachea wrote:
>
> 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).

Interesting. That's certainly not something we've guaranteed. My suggested 
patch makes read/write on the same file descriptor atomic wrt each other, 
but does not serialize them wrt different file descriptors (even if it's 
the same file). So you could see "half a write" from another read, for 
example, or fstat() could easily return the half-way file size for a write 
that hasn't completed.

Quite frankly, being totally atomic wrt each other seems unreasonable. 
Having fstat take the inode lock between threads is insane. It's 
definitely not even something you'd _want_ between processes (ie if 
somebody is doing a 2GB write, you want to be able to do an "ls" to see 
the file grow!), doing it between threads would just be insane.

Or maybe the "effects specified in IEEE Std 1003.1-2001" is really about 
the _other_ effects (ie things like write clearing SUID bits, atime/mtime 
etc).

So it smells like POSIX is broken here, in that it expects bad behaviour 
that isn't sane. But a subset of it would potentially be sane (ie exactly 
that write/write or write/read atomicity on the same file _descriptor_, 
exactly because they share f_pos).

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux