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: <20061121003745.aeda4f7c.akpm@osdl.org>
Date:	Tue, 21 Nov 2006 00:37:45 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Michael Raskin <a1d23ab4@...l.ru>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.19-rc1-mm1+ memory problem

On Mon, 20 Nov 2006 09:26:29 +0300
Michael Raskin <a1d23ab4@...l.ru> wrote:

> Short description: when X is loaded (maybe any heavy application is 
> sufficient, but I don't use anything heavy in console), 'free' says used 
> memory is growing.
> 
> Keywords: memory.
> 
> Kernel: built locally, gcc 4.0.3
> 
> I have a strange problem with 2.6.19-rc-mm kernels. After I load X, I 
> notice that memory is marked used at rate of tens of KB/s. Then it 
> starts to swap very heavily, when physical memory is all used. I tried 
> to verify it - it is so with all -mm kernels after 2.6.19-rc1-mm1, 
> including 2.6.19-rc5-mm2. At the meantime everything works OK with 
> kernels 2.6.18-mm3 and 2.6.19-rc1 through 2.6.19-rc6. I do not see any 
> options that should be memory eating in my .config . Module list is 
> short enough to include inline.
> 
> When I just run some things like periodical suck, oops proxy server etc 
> with X shut down, I do not notice "leak" from console because of small 
> fluctuations of memory use. When I run X and shut it down, used memory 
> count goes up a few megs (consistent with speed of eating it by X).
> 
> I didn't find exactly this problem in lkml or www, though the problem 
> with OOM on 2.6.19-rc-mm seems similar.
> 
> What should I check to fix problem or produce a useful bug report?

Monitor /proc/meminfo

If the leak is slab, monitor /proc/slabinfo and /proc/slab_allocators.
/proc/slab_allocators needs CONFIG_DEBUG_SLAB_LEAK.

Thanks.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ