Hi Trond,
We found that a machine which made moderately heavy use of
'automount' was leaking some nfs data structures - particularly the
4K allocated by rpc_alloc_iostats.
It turns out that this only happens with filesystems with -onolock
set.
The problem is that if NFS_MOUNT_NONLM is set, nfs_start_lockd doesn't
set server->destroy, so when the filesystem is unmounted, the
->client_acl is not shutdown, and so several resources are still
held. Multiple mount/umount cycles will slowly eat away memory
several pages at a time.
The following patch seems the simplest fix, but it may not be what you
prefer. Arguably nfs_start_lockd isn't really the right place to set
server->destroy as it relates to both lockd and client_acl. Maybe
->destroy could be set at the end of nfs_init_server in the no-error
case.
It looks like this bug was introduced by
54ceac4515986030c2502960be620198dd8fe25b
so has been present since 2.6.19 (we found it in 2.6.22).
NeilBrown
Signed-off-by: NeilBrown <[EMAIL PROTECTED]>
diff .prev/fs/nfs/client.c ./fs/nfs/client.c
--- .prev/fs/nfs/client.c 2007-12-11 15:42:54.000000000 +1100
+++ ./fs/nfs/client.c 2007-12-11 15:44:19.000000000 +1100
@@ -432,9 +432,9 @@ static int nfs_start_lockd(struct nfs_se
IPPROTO_TCP : IPPROTO_UDP);
if (error < 0)
server->flags |= NFS_MOUNT_NONLM;
- else
- server->destroy = nfs_destroy_server;
out:
+ if (! error)
+ server->destroy = nfs_destroy_server;
return error;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
