lkml.org 
[lkml]   [2006]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: d_instantiate_unique / NFS inode leakage?
    From
    Date
    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/

    \
     
     \ /
      Last update: 2006-01-05 02:29    [W:4.107 / U:0.560 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site