linux-kernel - possible (ext4 related?) memory leak in kernel 2.6.26

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

Date:	Tue, 30 Sep 2008 22:27:29 +0200
From:	Quentin Godfroy <godfroy@...pper.ens.fr>
To:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	David.Madore@....fr
Subject: possible (ext4 related?) memory leak in kernel 2.6.26

Hi lists,

I'd like to report the following problem : after ~ 10 days' uptime on a
Debian 2.6.26-1-686 kernel, my system becomes extremely sluggish and
unresponsive and the OOM-killer starts targeting even innocent processes like
identd or rsync (when the swap is disabled). The machine is low on RAM (192
MB) but this has never been a problem before. As for the slowness, strace
shows that the brk() syscall takes ages to complete; the blocking processes
are in the D state (and for some reason the kernel gives no wchan info).

Free reports a large and constantly growing 'buffers' figure (more than
50% of the available memory). No userland processes seems to be consuming
lare amounts of memory (sum of RSS in 'ps aux' is about 30 megs), and the
overall system is mostly idle.

for instance, the following command reports 

$ free ; dpkg -l '*' >/dev/null; dmesg | tail -n 2
             total       used       free     shared    buffers     cached
Mem:        190356     178920      11436          0     126104      12520
-/+ buffers/cache:      40296     150060
Swap:            0          0          0
/* Waits a minute or so */
Killed
[811245.911859] Out of memory: kill process 6639 (dpkg-query) score 7292 or a child
[811245.911972] Killed process 6639 (dpkg-query)

Config has nothing unusual except that all fs are ext4, which I am begining
to suspect may be the culprit, as every night some process stat()s and
read()s something like 850,000 files, which is maybe fs-stressing; also,
umounting then remounting /home makes the 'buffers' drop from 127304 to
55920 and partially solves the problem.

For info, on umount the last lines in the dmesg read:

[811842.209432] EXT4-fs: mballoc: 12288 blocks 12288 reqs (0 success)
[811842.209547] EXT4-fs: mballoc: 13038 extents scanned, 5902 goal hits,
6315 2^N hits, 0 breaks, 0 lost
[811842.209638] EXT4-fs: mballoc: 768 generated and it took 12577042
[811842.209695] EXT4-fs: mballoc: 1588424 preallocated, 371043 discarded
[811842.372165] kjournald2 starting.  Commit interval 5 seconds
[811842.373381] EXT4 FS on hda4, internal journal
[811842.373473] EXT4-fs: mounted filesystem with ordered data mode.
[811842.373529] EXT4-fs: file extents enabled
[811842.374013] EXT4-fs: mballoc enabled

I believe the problem appeared in 2.6.25, but I am not sure.

Regards,
Quentin Godfroy
--
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/