> On Wed, 28 Apr 1999, Trond Myklebust wrote:
>> This is just a function for initializing the cached inode,
>> before it is filled in __nfs_fhget. Are you talking about the
>> latter?
> Right. Sorry.
The reason why we don't have a limit to the number of tries there is
because it should normally not be necessary. We only loop when we
detect an inode as being stale: in which case we unhash it so that
'iget' returns a fresh inode.
In theory, you can loop forever if the server is returning a zero
value for fattr->nlink, but that would be a definite bug in the
server. If you see it looping within that routine for some other case,
I'd be very interested in details about the inode in question.
Please note that there is a bug in 'nfs_lookup_revalidate' that has
been reported to give problems with named sockets and the like. The
latter seem (on some Linux servers) to have volatile file
handles. This has been reported to cause a loop with dentry
revalidation, in which case you would see a lot of messages from
__nfs_fhget about freeing dentries and the like. Typically, it has
been seen on NFSroot-based systems which access /tmp/.X11/X0.
A fix for this problem has already been included in the pre-2.2.7
patches, and has been in the '2.2.6-ac' series all along. Have you
seen the problem with any of these kernels?
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/