lkml.org 
[lkml]   [2002]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] 2.5: further llseek cleanup (1/3)


On 31 Jan 2002, Robert Love wrote:

> 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).

That will happen pretty soon, actually.

> 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?

I'm OK with that.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:16    [W:1.532 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site