Re: [PATCH] 2.5: further llseek cleanup (1/3)

[Robert Love <rml@tech9.net>]

On Thu, 2002-01-31 at 10:19, Jan Harkes wrote:

> I'm not sure whether the Coda part of this patch is correct. Coda does
> rely in the inode semaphore to protect from concurrency between the
> userspace cachemanager that accesses the file on the host filesystem
> directly and the applications that access the same file through the
> /coda mount.
> 
> See for instance coda_file_write, where we also use the host inode
> semaphore for protection. Only sys_stat() accesses i_size unprotected,
> but that doesn't matter much in my opinion. Any application relying on
> the result of sys_stat to do appending or subsequent lseeks would be
> racy anyways. (and it can only be fixed correctly when we get a FS
> specific getattr method).

Hmm ... the race you mention in sys_stat is the problem I saw.  I also
can't say for sure whether any code, or future code, would touch
i_size.  It is just not safe.

Note also that reverting to the remote_llseek method won't break
anything; it is the previous behavior.  Certainly I would much rather
just use the inode semaphore, but I'd prefer to not introduce any
races.  Ideally we need a solution that eliminates the BKL _and_ is not
racy.

I'd be happy to keep Coda using the new generic_file_llseek if Al Viro
agrees with you.  Al?

	Robert Love