summaryrefslogtreecommitdiffstats
path: root/crypto/aead.c
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2008-02-11 10:00:20 -0500
committerTrond Myklebust <Trond.Myklebust@netapp.com>2008-02-13 23:24:04 -0500
commit8e60029f403781b8a63b7ffdb7dc1faff6ca651e (patch)
tree9eb13d36a8951ef160250bb973648426b456c46b /crypto/aead.c
parente760e716d47b48caf98da348368fd41b4a9b9e7e (diff)
downloadkernel-crypto-8e60029f403781b8a63b7ffdb7dc1faff6ca651e.tar.gz
kernel-crypto-8e60029f403781b8a63b7ffdb7dc1faff6ca651e.tar.xz
kernel-crypto-8e60029f403781b8a63b7ffdb7dc1faff6ca651e.zip
NFS: fix reference counting for NFSv4 callback thread
The reference counting for the NFSv4 callback thread stays artificially high. When this thread comes down, it doesn't properly tear down the svc_serv, causing a memory leak. In my testing on an older kernel on x86_64, memory would leak out of the 8k kmalloc slab. So, we're leaking at least a page of memory every time the thread comes down. svc_create() creates the svc_serv with a sv_nrthreads count of 1, and then svc_create_thread() increments that count. Whenever the callback thread is started it has a sv_nrthreads count of 2. When coming down, it calls svc_exit_thread() which decrements that count and if it hits 0, it tears everything down. That never happens here since the count is always at 2 when the thread exits. The problem is that nfs_callback_up() should be calling svc_destroy() on the svc_serv on both success and failure. This is how lockd_up_proto() handles the reference counting, and doing that here fixes the leak. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'crypto/aead.c')
0 files changed, 0 insertions, 0 deletions