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