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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
