SRU justification:
Impact: With activated network namespace (CONFIG_NET_NS) support it is possible to create new namespaces much faster than cleaning them up. This can lead to memory pressure and in the case of vsftp it is easily possible to bring down the server by just repeatedly connecting to it.
Fix: The issue was fixed by a long series of changes to make cleanup quicker. The vast amount of changes makes them unsuited for SRU. So it was decided that the safest way for a 2.6.32 based kernel is to turn that feature off (it was considered experimental until 2.6.37 anyway).
Testcase: Se report.
---
A simple stress test conducted on a KVM guest running standard updated Lucid with vsftpd demonstrates that memory is continuously used up until OOM Killer starts to protect the system (after ~12 min on my system). If test is terminated before that point is reached then memory is freed only after several hours. If vsftpd is stopped then memory is freed (after ~45 min on my system).
This does not occur with the 2.6.35 kernel (LTS backported kernel).
The test is started in this way:
$ for i in 1 2 3 4 5 6 7 8 ; do ./feedftp $i >/dev/null & done
What is observed during the test is that /proc/vmallocinfo grows continually with lines like the following being added:
0xffffe8ffff800000-0xffffe8ffffa00000 2097152 pcpu_get_vm_areas+0x0/0x790 vmalloc
0xffffe8ffffa00000-0xffffe8ffffc00000 2097152 pcpu_get_vm_areas+0x0/0x790 vmalloc
0xffffe8ffffc00000-0xffffe8ffffe00000 2097152 pcpu_get_vm_areas+0x0/0x790 vmalloc
Attached:
- test script (see feedftp)
- tarball containing the proc file at various times during the test (see vmallocinfo.32.tar)
- dmesg output showing OOM Killer at work (see dmesg-oom.32.txt)
May be related: https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/682865
=========
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: linux-image-2.6.32-28-server (not installed)
Regression: No
Reproducible: Yes
ProcVersionSignature: User Name 2.6.32-28.55-server 2.6.32.27+drm33.12
Uname: Linux 2.6.32-28-server x86_64
AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access /dev/snd/: No such file or directory
AplayDevices: Error: [Errno 2] No such file or directory
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory
CurrentDmesg: [ 12.360149] eth0: no IPv6 routers present
Date: Wed Feb 16 14:00:19 2011
Lspci: Error: [Errno 2] No such file or directory
Lsusb: Error: [Errno 2] No such file or directory
MachineType: Bochs Bochs
PciMultimedia:
ProcCmdLine: root=UUID=7bbf58be-9c5f-4113-ad1b-4611fd131d33 ro
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: linux
dmi.bios.date: 01/01/2007
dmi.bios.vendor: Bochs
dmi.bios.version: Bochs
dmi.chassis.type: 1
dmi.chassis.vendor: Bochs
dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr:
dmi.product.name: Bochs
dmi.sys.vendor: Bochs
From the report it seems that this was broken in v2.6.32 and maybe fixed in v2.6.35. The commit below sounds plausable and might be worth looking at:
commit 02b709df817c0db
Author: Nick Piggin <email address hidden>
Date: Mon Feb 1 22:25:57 2010 +1100
mm: purge fragmented percpu vmap blocks
Improve handling of fragmented per-CPU vmaps. We previously don't free
up per-CPU maps until all its addresses have been used and freed. So
fragmented blocks could fill up vmalloc space even if they actually had
no active vmap regions within them.
Add some logic to allow all CPUs to have these blocks purged in the case
of failure to allocate a new vm area, and also put some logic to trim
such blocks of a current CPU if we hit them in the allocation path (so
as to avoid a large build up of them).
Christoph reported some vmap allocation failures when using the per CPU
vmap APIs in XFS, which cannot be reproduced after this patch and the
previous bug fix.
Cc: <email address hidden>
Cc: <email address hidden>
Tested-by: Christoph Hellwig <email address hidden>
Signed-off-by: Nick Piggin <email address hidden>
--
Signed-off-by: Linus Torvalds <email address hidden>