> I think it's wrong to fix synchonization on a problem-by-problem basis:
> VFS synchonization for read()/write()/truncate()/file lock's is broken,
> and I would try to find one solution instead of patch-work.
There are different things to protect. E.g. i_sem is (ab)used for dcache
race-prevention. Lumping everything together is not a good idea, IMO.
> Alexander Viro wrote:
> > > 1) overlapping concurrent write operations violate Nfsv2.
> >
> > Yes, that is serious.
> > > 3) do not forget f_pos when you implement a synchonization: even
> > > concurrent reads are not allowed if both use the same file pointer.
> >
> > Ditto. It's a separate issue.
>
> These are 2 pending problems which must be fixed before 2.4
>
> If you fix them, then you will add synchonization to sys_write(), and
> raw-io will be affected since raw-io is accessed through sys_write() to
> a special character device driver.
Wait a minute. It's exactly the reason why we should not do it in
sys_write() - synchronization issues vary depending on _what_ you are
accessing.
> Other pending problems are O_APPEND
writer.
>, mandantory file locks.
broken so badly, that... well, for example there is a nice race with
mmap(). There is a whole crapload of horror in the implementation - I have
some fixes, but they are pretty obsolete now (late July; I was net.dead
in August and beginning of September ;-/). And there is an interesting
stuff in interaction of fs/locks.c with fs/lockd/*. If NFS folks are ready
to comment on their side of code - fine, but IMHO the locking stuff is
not going to be fixed soon.
-
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/