On Wed, 2013-02-13 at 10:33 +0100, Gunnar Beutner wrote: > Package: linux-2.6 > Version: 2.6.32-46 > Severity: normal > > When using vfork() followed by any one of the exec*() functions the > parent task's virtual memory size increases even though the > segment sizes as reported by /proc/<pid>/maps do not change. Here's an > example program that shows the problem: [...] > When running the program one can see the VIRT size of the process (as > reported by ps/top or /proc/<pid>/stat) increase > indefinitely. Changing the vfork() call to fork() makes the problem > disappear. > > The increase in virtual memory size is directly proportional to the > size of the arguments passed to the child process.
We want the virtual memory size to increase, but only temporarily. > Also, the upstream kernel (tested versions: 2.6.31, 2.6.32, 2.6.34, > 3.1.0, 3.5.0) does not exhibit this behavior. > > One of the Debian patches > (exec-make-argv-envp-memory-visible-to-oom-killer.patch) directly > affects how argv-related memory > is accounted for. This is an upstream bug fix made in 2.6.37 and then applied to all the older stable branches. > I believe that it is this patch which does not properly account for > the fact that child processes spawned > by vfork() share the same mm struct like their parent proccesses. [...] I strongly suspect that this bug was introduced the following patch exec-Get-rid-of-linux_binprm-vma_pages.patch, which I made to avoid a kernel ABI change from the previous fix. In particular, I assumed that: - The calls to acct_arg_size(bprm, 0) are redundant, since neither the cache nor the dead mm need to be updated which is not true in the vfork() case. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus
signature.asc
Description: This is a digitally signed message part