Messages in this thread | | | Date | Thu, 13 Apr 2006 08:01:25 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: PROBLEM: pthread-safety bug in write(2) on Linux 2.6.x |
| |
On Thu, 13 Apr 2006, Nick Piggin wrote: > > Didn't Linus explicitly made the decision not to add synchronisation for > writes with the same file?
I would be _very_ nervous to do it, yes. In particular, I do not consider it at all unlikely to have something database-like that does concurrent writes to the same file at different offsets, and serializing them on the VFS layer seems pretty broken.
Also, doing it unconditionally in the VFS layer is actually pretty seriously broken: the VFS layer doesn't even know what kind of file it is, and locking on writes can be literally the wrong thing for some file descriptors (think pipes or sockets: if we have one blocking write holding the lock, that should _not_ imply that other - possibly nonblocking - writes shouldn't be able to call in to the low-level write handler).
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".
Comments?
Linus - 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/
| |