> On Fri, 8 Oct 1999, Alexander Viro wrote:
>
> >AFAICS. The next thing I'm going to do is a (dumb) implementation of
> >blocking rwlocks. write() being reader and truncate() - writer.
>
> To make the design of the code simpler write(2) should be a writer too.
>
> All the VM checks i_size without any lock. So if you don't want to play
> with everything you should grab the writer lock at the VFS layer if you
> know your path may change i_size in any way (and write definitely can).
I don't think so. Look, it's not a matter of protecting i_size - it's a
separate problem. We are seriously abusing i_size in the call of
->truncate() anyway. What I am looking for is
truncate may be sure that blocks belonging to file will remain
that way and no new will appear. IOW, truncate can trust the contents of
inode/indirect blocks/FAT chain/whatever.
That's it. write() does lock the page before writing to it/allocating new
blocks/etc. _That_ protection should be enough to avoid several callers of
write() messing with each other.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/