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

[Linus Torvalds <torvalds@osdl.org>]

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/