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
