Messages in this thread | | | Date | Fri, 8 Oct 1999 13:13:25 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: how to write get_block? |
| |
On Fri, 8 Oct 1999, Manfred Spraul wrote:
> 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/
| |