Messages in this thread | | | Date | Fri, 08 Oct 1999 19:39:38 +0200 | From | Manfred Spraul <> | Subject | Re: how to write get_block? |
| |
Alexander Viro wrote: > 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. > Of course. But it's wrong to start fixing on one end of the problem before you see the complete problem: if you start with a rw-semaphore (called ERESOURCE in WinNT kernel, if you search for a name), then I'm 99% sure that this code will die before 2.4.
> 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.
think about f_pos: VFS hides the difference between sys_pread() and sys_read(). Filesystems can't implement the locking.
I think VFS should (and must) offer 3 or 4 locking options through i_flags, otherwise every filesystem must reinvent the wheel. (do nothing; protect f_pos; EOF and NvsV2 protection)
> >, mandantory file locks. > > broken so badly, that... well, for example there is a nice race with > mmap().
mandantory filelocks and mmap() are incompatible, there is no chance to fix that.
eg. under Windows, all filelocks are mandantory locks. This means that noone can use mmap() for databases, that's a known and unsolvable problem.
I'll check the POSIX standard, perhaps we can just reject mmap() or file-locks in this situation.
Btw, look at default_llseek(): it's not POSIX compliant because it does not check for file system specific file size limits. As a result, ext2 has it's own llseek-function. A few weeks ago I noticed that UDF has a special llseek function. That's the wrong aproach - I posted a patch which fixes default_llseek(), but it was ignored.
-- Manfred
- 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/
| |