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] [day] [month] [year] [list]

Date:	Sat, 01 Mar 2008 16:25:25 +0100
From:	Ferenc Wagner <wferi@...f.hu>
To:	David Chinner <dgc@....com>
Cc:	linux-kernel@...r.kernel.org, wferi@...f.hu
Subject: Re: inode leak in 2.6.24?

David Chinner <dgc@....com> writes:

> On Wed, Feb 20, 2008 at 03:36:53PM +0100, Ferenc Wagner wrote:
>
>>David Chinner <dgc@....com> writes:
>>
>>> 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....
>> 
>> Thanks for looking into this.  There's no real conclusion yet: the
>> simulated memory pressure sent the numbers down allright, but
>> meanwhile it turned out that this is a different case: on this machine
>> the increase wasn't a constant growth, but related to the daily
>> updatedb job.  I'll reload the original kernel on the original
>> machine, and collect the same info if the problem reappers.
>
> Ok, let me know how it goes when you get a chance.

So, the leak is ruled out now.  The machine has been running the
"leaky" kernel for a week; the inode usage grows, but simulated memory
pressure gets it back to normal (to 1k right now).  See the graph again:

Download attachment "open_inodes-month.png" of type "image/png" (31794 bytes)

For orientation: week 7 alerted me, but changing to 2.6.24.2 helped.
Then on the last day of week 8 I rebooted the same kernel for further
investigation, and simulated memory pressure 3 times, which resulted
in the drops (down to about 1k each time).  The increase seems to be
sublinear now for some reason, though the usage pattern of the machine
is very much the same.

Week 05           : 2.6.23.14
Week 06 Feb.   -10:   -""-
Week 07 Feb. 11-17: 2.6.24 (HEAD: 25f666300625d894ebe04bac2b4b3aadb907c861)
Week 08 Feb. 18-23: 2.6.24.2
Week 09 Feb. 24-  : 2.6.24 (same as before)

So, it looks like there's no leak, but the reclaim behaviour has
changed significantly, exactly as you suspected.
-- 
Thanks for your time,
Feri.