Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751093AbWAEBBZ (ORCPT ); Wed, 4 Jan 2006 20:01:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751078AbWAEBAs (ORCPT ); Wed, 4 Jan 2006 20:00:48 -0500 Received: from linuxhacker.ru ([217.76.32.60]:17542 "EHLO shrek.linuxhacker.ru") by vger.kernel.org with ESMTP id S1750992AbWAEBAM (ORCPT ); Wed, 4 Jan 2006 20:00:12 -0500 Date: Thu, 5 Jan 2006 03:00:47 +0200 From: Oleg Drokin To: linux-kernel@vger.kernel.org, trond.myklebust@fys.uio.no, viro@zeniv.linux.org.uk Subject: d_instantiate_unique / NFS inode leakage? Message-ID: <20060105010047.GJ5743@linuxhacker.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1225 Lines: 30 Hello! Searching for inode leakage in NFS code (seen in 2.6.14 and 2.6.15 at least, have not tried earlier versions), I see suspicious place in d_instantiate_unique (the only user happens to be NFS). There if we have found aliased dentry that we return, inode reference is not dropped and inode is not attached anywhere, so it seems the reference to inode is leaked in that case. This simple patch below fixes the problem. Unfortunatelly the leakage seems to be non-100% in my testing, so I will continue the testing to see if I still see inodes to leak or not (no leak seen so far with the patch). --- fs/dcache.c.orig 2006-01-05 02:28:57.000000000 +0200 +++ fs/dcache.c 2006-01-05 02:32:08.000000000 +0200 @@ -838,6 +838,7 @@ struct dentry *d_instantiate_unique(stru dget_locked(alias); spin_unlock(&dcache_lock); BUG_ON(!d_unhashed(alias)); + iput(inode); return alias; } list_add(&entry->d_alias, &inode->i_dentry); Bye, Oleg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/