> 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/