linux-kernel - Re: inode leak in 2.6.24?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080220010405.GF155407@sgi.com>
Date:	Wed, 20 Feb 2008 12:04:06 +1100
From:	David Chinner <dgc@....com>
To:	Ferenc Wagner <wferi@...f.hu>
Cc:	David Chinner <dgc@....com>, linux-kernel@...r.kernel.org
Subject: Re: inode leak in 2.6.24?

On Tue, Feb 19, 2008 at 05:57:08PM +0100, Ferenc Wagner wrote:
> David Chinner <dgc@....com> writes:
> > On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
> So, I loaded the same kernel on a different machine, but that seems to
> exhibit a very similar behaviour.  The machine is absolutely idle,
> nobody logged in during this period, though an updatedb ran during
> this period.  However, the increase seems steady, not correlated to
> cron.daily.
> 
> The contents of /proc/sys/fs/inode-nr after reboot was:
> 4421	95
> 
> and now, 13h35m later it's:
> 146182	0
> 
> Find the two slabinfo outputs attached.

Content-Description: slabinfo output immediately after reboot
> xfs_inode            791    800    384   10    1 : tunables   54   27    8 : slabdata     80     80      0
> xfs_vnode            790    790    384   10    1 : tunables   54   27    8 : slabdata     79     79      0
> dentry              5133   5133    132   29    1 : tunables  120   60    8 : slabdata    177    177      0

Content-Description: slabinfo output 13h35m after reboot
> xfs_inode         142548 142550    384   10    1 : tunables   54   27    8 : slabdata  14255  14255      0
> xfs_vnode         142548 142550    384   10    1 : tunables   54   27    8 : slabdata  14255  14255      0
> dentry            148003 148074    132   29    1 : tunables  120   60    8 : slabdata   5106   5106      0

> The xfs_inode, xfs_vnode and dentry lines show significant increase.
> The machine indeed uses XFS as its root filesystem.  Hope this gives
> enough clues to narrow down the problem.  I can try other kernels if
> needed.

The xfs inodes are clearly pinned by the dentry cache, so the issue
is dentries, not inodes. What's causing dentries not to be
reclaimed?  I can't see anything that cold pin them (e.g. no filp's
that would indicate open files being responsible), so my initial
thoughts are that memory reclaim may have changed behaviour.

I guess the first thing to find out is whether memory pressure
results in freeing the dentries. To simulate memory pressure causing
slab cache reclaim, can you run:

# echo 2 > /proc/sys/vm/drop_caches

and see if the number of dentries and inodes drops. If the number
goes down significantly, then we aren't leaking dentries and there's
been a change in memoy reclaim behaviour. If it stays the same, then
we probably are leaking dentries....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/