Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[James Yarbrough]

> This will always invalidate the page cache whenever we try to obtain
> the lock, hence you are guaranteed that the cache will be reread after

> the lock was grabbed.
> After unlocking however one needs no guarantees other than ensuring
> that any modifications were committed while we held the lock, so we
> flush the writebacks, drop the lock, and leave it at that.

What is done for bypassing the cache when the size of a file lock held
by the
reading/writing process is not a multiple of the caching granularity?
Consider
two different clients with processes sharing a file and locking 2k byte
regions
of the file and possibly updating these regions.  Suppose that each
system caches
4k byte blocks.  If system A locks the first 2k of a block and system B
locks
the second 2k, the updates from one of the systems may be lost if these
systems
cache the writes.  This is because each system will write back the 4k
block it
cached, not the 2k block that was locked.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/