linux-kernel - Re: detecting kernel mem leak

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:	Fri, 16 May 2008 11:50:38 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Stéphane ANCELOT <sancelot@...e.fr>
cc:	Pekka Enberg <penberg@...helsinki.fi>, linux-kernel@...r.kernel.org
Subject: Re: detecting kernel mem leak

On Fri, 16 May 2008, Stéphane ANCELOT wrote:

> In the kernel, there is SLAB or SLUB , my kernel is at this time configured
> for SLAB allocator.

SLAB does not support the slabinfo tool. It only supports /proc/slabinfo.

> it is documented SLUB minimizes cache line usage.
> Do you think I have to switch to SLUB ?

If you want to use the slabinfo tool then yes.

> 2) regarding memory debugging, your reply and some mesages told it was normal
> the memory was growing (with ext3 buffer_heads...) and released on demand.
> This sounds to me it becomes VERY VERY difficult telling if my system is
> STABLE or NOT. Is there a way to bypass it ?

This the basic design of memory handling in Linux. Why would the use of 
memory mean that your system is unstable?

> I assume I have to do some kind of small program trying to allocate almost the
> full remaining memory available at startup to empty caches ?

There is a way to drop caches. See what you can do with 
/proc/sys/vm/drop_caches

f.e.

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

Should free most of memory.