d_instantiate_unique / NFS inode leakage?

d_instantiate_unique / NFS inode leakage?

[Oleg Drokin]

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

Re: d_instantiate_unique / NFS inode leakage?

[Trond Myklebust]

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

Re: d_instantiate_unique / NFS inode leakage?

[Oleg Drokin]

Hello!

On Thu, Jan 05, 2006 at 02:26:47AM +0100, Trond Myklebust wrote:
> >    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.
> 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?

Sure.

--- fs/dcache.c.orig	2006-01-05 02:28:57.000000000 +0200
+++ fs/dcache.c	2006-01-05 10:04:02.000000000 +0200
@@ -808,10 +808,14 @@ void d_instantiate(struct dentry *entry,
  *
  * Fill in inode information in the entry. On success, it returns NULL.
  * If an unhashed alias of "entry" already exists, then we return the
- * aliased dentry instead.
+ * aliased dentry instead and drop one reference to inode.
  *
  * Note that in order to avoid conflicts with rename() etc, the caller
  * had better be holding the parent directory semaphore.
+ *
+ * This also assumes that the inode count has been incremented
+ * (or otherwise set) by the caller to indicate that it is now
+ * in use by the dcache.
  */
 struct dentry *d_instantiate_unique(struct dentry *entry, struct inode *inode)
 {
@@ -838,6 +842,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

Re: d_instantiate_unique / NFS inode leakage?

[Trond Myklebust]

On Thu, 2006-01-05 at 10:09 +0200, Oleg Drokin wrote:
> Hello!
> 
> On Thu, Jan 05, 2006 at 02:26:47AM +0100, Trond Myklebust wrote:
> > >    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.
> > 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?
> 
> Sure.

Looks good to me. ACKed

Cheers,
  Trond

> --- fs/dcache.c.orig	2006-01-05 02:28:57.000000000 +0200
> +++ fs/dcache.c	2006-01-05 10:04:02.000000000 +0200
> @@ -808,10 +808,14 @@ void d_instantiate(struct dentry *entry,
>   *
>   * Fill in inode information in the entry. On success, it returns NULL.
>   * If an unhashed alias of "entry" already exists, then we return the
> - * aliased dentry instead.
> + * aliased dentry instead and drop one reference to inode.
>   *
>   * Note that in order to avoid conflicts with rename() etc, the caller
>   * had better be holding the parent directory semaphore.
> + *
> + * This also assumes that the inode count has been incremented
> + * (or otherwise set) by the caller to indicate that it is now
> + * in use by the dcache.
>   */
>  struct dentry *d_instantiate_unique(struct dentry *entry, struct inode *inode)
>  {
> @@ -838,6 +842,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