Messages in this thread | | | Date | Sun, 27 Jan 2008 16:18:26 -0600 | From | "Steve French" <> | Subject | Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek |
| |
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@netapp.com> 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
| |