Subject: Re: d_instantiate_unique / NFS inode leakage?
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk
In-Reply-To: <20060105010047.GJ5743@linuxhacker.ru>
References: <20060105010047.GJ5743@linuxhacker.ru>
Content-Type: text/plain
Date: Thu, 05 Jan 2006 02:26:47 +0100
Message-Id: <1136424407.7847.37.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1482
Lines: 36

On Thu, 2006-01-05 at 03:00 +0200, Oleg Drokin wrote:
> 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);

Yep, that looks like it ought to be the correct behaviour. Could you
please also add a note to this effect in the DocBook header for
d_instantiate_unique?

Cheers,
  Trond

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