Trond Myklebust wrote:
> Nope. Try 2.3.99-prex against a server which supports
> microsecond/nanosecond resolution. I've already changed the code in
> nfs_refresh_inode() to take into account this sort of thing. Look for
> the NFS_CACHE_*(inode) stuff.
Do you know how good other clients are about taking into account the
microsecond/nanosecond field? Is Linux the only cacheing NFS client
with this problem, so I can otherwise rely on using microseconds?
> > I don't think you have to explicitly invalidate the page cache
> > after using it -- and the races that implies. Instead, just
> > pretend the attribute check always says "the server has newer
> > data". Conceptually simpler IMO.
>
> No races. We wait on page, so if you remove the page from the page
> cache after it's been filled but before unlocking the page it will
> never be seen by anyone but you.
> The code in read_page_cache() and __find_get_page() is quite sane in
> this respect.
The race I'm thinking of is
Task1 Task2
allocate a page
send readlink request
wait_on_page
allocate a page -- same symlink so
find the one allocated by Task1
wait_on_page
response arrives
see Task1's symlink value see Task1's symlink value
Possibly the page cache won't do this (I've not studied it) but your
comment "we wait on page" doesn't sound like enough to avoid this
situation.
-- Jamie
-
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/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:11 EST