Messages in this thread | | | Subject | Re: PROBLEM: pthread-safety bug in write(2) on Linux 2.6.x | From | Alan Cox <> | Date | Thu, 13 Apr 2006 22:50:22 +0100 |
| |
On Iau, 2006-04-13 at 08:01 -0700, Linus Torvalds wrote: > That said, I wouldn't be 100% against it, especially under certain > circumstances. However, the circumstances when I think it might be > acceptable are fairly specific: > > - when we use f_pos (ie we'd synchronize write against write, but only > per "struct file", not on an inode basis) > - only for files that are marked seekable with FMODE_LSEEK (thus avoiding > the stream-like objects like pipes and sockets) > > Under those two circumstances, I'd certainly be ok with it, and I think we > could argue that it is a "good thing". It would be a "f_pos" lock (so we > migt do it for reads too), not a "data lock".
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.
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.
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.
Alan
- 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/
| |