Re: [PATCH] address_space_operations unification

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Mon May 08 2000 - 13:06:40 EST


>>>>> " " == Jamie Lokier <lk@tantalophile.demon.co.uk> writes:

> 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 couldn't tell you for sure, but I'd imagine all sane clients use the
full 64-bit value (32-bit seconds + 32-bit mu/nano-seconds) as a
cookie for cache invalidation. NFSv4 takes this a step further and
formalizes it it the draft specs.

I first implemented this in the NFSv3 patches for 2.2.x, so it is
already available for the stable kernel too...

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

It's quite safe: __find_get_page() waits on the page, then releases
it, and looks up the page cache again. If the first page was dropped
from the page cache, then the new lookup will fail.

Cheers,
  Trond

-
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