Messages in this thread | | | Date | Fri, 8 Oct 1999 11:46:01 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: how to write get_block? |
| |
On Fri, 8 Oct 1999, Manfred Spraul wrote:
> Alexander Viro wrote: > >All stuff with truncate()/write() is racey right now, > > AFAICS. The next thing I'm going to do is a (dumb) implementation of > > blocking rwlocks. write() being reader and truncate() - writer. > > IMHO that's the wrong approach: > > 1) overlapping concurrent write operations violate Nfsv2.
Yes, that is serious.
> 2) the pipe code needs O_NONBLOCK characteristics, ie no synchonization > is allowed. The 2.2 code uses an ugly hack: sys_write() acquires i_sem, > and inside the pipe code the semaphore is dropped.
Huh? It's not a sys_write(), it's generic_file_write(). Pipes do not come even close to that place. And I'm talking about 2.3 - 2.2 is _way_ too different.
> 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.
> What about these ideas: > a) rename i_sem (*), and add public functions such as > inode_lock_exclusive(), inode_lock_truncate(), inode_lock_write() etc. > > Currently, everyone directly accesses the VFS synchonization (nfsd, > drivers/char/tty_io.c; arch/*/kernel/sys*.c). > > b) the requirements of the VFS users differ completely, add flags: > 0: synchonize nothing, eg pipes. > I_FPOS_SYNC: synchonize f_pos access, nothing else > I_FILE_SYNC: multiple read, non-overlapping write, truncate. > > Since it will be hidden by inode_lock_??(), it will be easy to optimize > the implementation as needed. > > Eg I'm pretty sure that Stephen will not like it if raw-io is slowed > down by a multiple reader-single writer synchonization.
Erm? Writer access is for truncate() and I don't see where the raw-io comes into the picture.
- 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/
| |