On Thu, 15 Jan 2009 09:21:13 -0500 Theodore Tso <tytso@xxxxxxx> wrote: > On Thu, Jan 15, 2009 at 06:22:52AM -0700, Matthew Wilcox wrote: > > > > Of course if you have multiple threads, they will share a struct file, > > and you're updating f_pos and f_version without locking. Maybe that's > > OK, but it's soemthing you didn't discuss. > > f_pos is updated by sys_write(), and friends without locking, so we're > fine on that front, or at least no worse off. bug ;) > SUSv3 doesn't seem to > say one way or another what should happen if two threads try to > write() to a file at the same time using the same file descriptor in > terms of whether or not f_pos gets updated intelligently. We've opted > for speed over determinism already. I think our thinking was that if two threads are racily updating f_pos with different values, then it should end up with one of those values. >From a quality-of-implementation POV (what _is_ that, anyway) it would be bad if the kernel were to set f_pos to the upper 32 bits of position A and the lower 32 bits of position B. Which could happen if we remove the i_mutex protection on 32-bits. We could perhaps omit some locking if CONFIG_64BIT. There's probably quite a bit of locking which could be omitted in that case. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
