If two seeks overlap, can't you end up with an f_pos value that is different than what either thread seeked to? or if you have a seek and a read overlap can't you end up with the read occurring in the midst of an update of f_pos (which takes more than one instruction on various architectures), e.g. reading an f_pos, which has only the lower half of a 64 bit field updated? I agree that you shouldn't have seeks racing in parallel but I think it is preferable to get either the updated f_pos or the earlier f_pos not something 1/2 updated. On Jan 27, 2008 11:56 AM, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: > > On Sun, 2008-01-27 at 10:57 -0600, Steve French wrote: > > Don't you need to a spinlock/spinunlock(i_lock) or something similar > > (there isn't a spinlock in the file struct unfortunately) around the > > reads and writes from f_pos in fs/read_write.c in remote_llseek with > > your patch since the reads/writes from that field are not necessarily > > atomic and threads could be racing in seek on the same file struct? > > Where does is state in POSIX or SUS that we need to cater to that kind > of application? > In any case, the current behaviour of f_pos if two threads are sharing > the file struct is undefined no matter whether you spinlock or not, > since there is no special locking around sys_read() or sys_write(). > > Trond > -- Thanks, Steve - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
