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
| ||
|
Date: Wed, 12 Dec 2007 14:28:48 +0100 (CET) From: Krzysztof Oledzki <olel@....pl> To: bugme-daemon@...zilla.kernel.org cc: Andrew Morton <akpm@...ux-foundation.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Nick Piggin <nickpiggin@...oo.com.au> Subject: Re: [Bug 9182] Critical memory leak (dirty pages) On Tue, 11 Dec 2007, Krzysztof Oledzki wrote: > > > On Wed, 5 Dec 2007, Krzysztof Oledzki wrote: > >> >> >> On Wed, 5 Dec 2007, bugme-daemon@...zilla.kernel.org wrote: >> >>> http://bugzilla.kernel.org/show_bug.cgi?id=9182 >>> >>> >>> ------- Comment #20 from akpm@...l.org 2007-12-05 13:37 ------- >>> Please monitor the "Dirty:" record in /proc/meminfo. Is it slowly rising >>> and never falling? >> >> It is slowly rising with respect to a small fluctuation caused by a current >> load. >> >>> Does it then fall if you run /bin/sync? >> Only a little, by ~1-2MB like in a normal system. But it is not able to >> fall below a local minimum. So, after a first sync it does not fall more >> with additional synces. >> >>> Compile up usemem.c from >>> http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz and run >>> >>> usemem -m <N> >>> >>> where N is the number of megabytes whcih that machine has. >> >> It has 2GB but: >> >> # ./usemem -m 1662 ; echo $? >> 0 >> >> # ./usemem -m 1663 ; echo $? >> ./usemem: mmap failed: Cannot allocate memory >> 1 >> >>> Did this cause /proc/meminfo:Dirty to fall? >> No. > > OK, I booted a kernel without 2:2 memsplit but instead with a standard > 3.1:0.9 and even without highmem. So, now I have ~900MB and I am able to set > -m to the number of megabytes which themachine has. However, usemem still > does does not cause dirty memory usage to fall. :( OK, I can confirm that this is a regression from 2.6.18 where it works OK: ole@...gar:~$ uname -r 2.6.18.8 ole@...gar:~$ uptime;grep Dirt /proc/meminfo;sync;sleep 2;sync;sleep 1;sync;grep Dirt /proc/meminfo 14:21:53 up 1:00, 1 user, load average: 0.23, 0.36, 0.35 Dirty: 376 kB Dirty: 0 kB It seems that this leak also exists in my other system as even after many synces number of dirty pages are still >> 0, but this the only one where it is so critical and at the same time - so easy to reproduce. Best regards, Krzysztof Olędzki
Powered by blists - more mailing lists