Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #64341 > unrolled thread

Bug#931111: linux-image-4.9.0-9-amd64: Memory leak - fixed with 4.9.174 (or earlier)

Back to article view | Back to linux.debian.kernel

Contents

  Bug#931111: linux-image-4.9.0-9-amd64: Memory leak - fixed with 4.9.174 (or earlier) Philipp Hahn <hahn@univention.de> - 2019-06-26 12:30 +0200
    Bug#931111: linux-image-4.9.0-9: Memory "leak" caused by CGroup as used by pam_systemd Ben Hutchings <ben@decadent.org.uk> - 2019-07-24 00:10 +0200

#64341 — Bug#931111: linux-image-4.9.0-9-amd64: Memory leak - fixed with 4.9.174 (or earlier)

Package: linux-image-4.9.0-9-amd64
Version: 4.9.168-1+deb9u3
Severity: important

Dear fellow DDs,

we (Univention GmbH) have several reports of a memory leak wtih 4.9.168
as shipped by Debian (and used by us):

https://help.univention.com/t/memoryleak-auf-slave-contoller/11892/8
https://forge.univention.org/bugzilla/show_bug.cgi?id=49614

I was not yet able to pin-point the area where the leak occurs, but the
bug seemd to be fixed after switching to 4.9.174.a( I hand-applied the
incremental patches on top of Debians 4.9.168 fixing the rejects and
enabled KMEMLEAK.) The fix can be earlied than 174; I chose that version
from a hint given by one of our customers, who reported 174 to be fixed.

4.9.144 was also fine (at leat no leak was observed).

Stopping all processes did NOT free the memory again.
My interpretation of this is, that the leak is not in user-space, but in
kernel-land.

<https://www.kernel.org/doc/html/v4.10/dev-tools/kmemleak.html> does not
show any leaks so far.

One of the affected systems is a system of us, where I can do some
limited testing, e.g. install self-compiled kernel version.
As I don't have a (simple) reproducer running `git bisect` is somehow
inefficient.
So if you have any idea on what to test or where I can help just ask.


-- System Information:
Debian Release: 9.9
  APT prefers 
  APT policy: (500, 'stretch')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-9-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.9.0-9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod                                    23-2
ii  linux-base                              4.5

Versions of packages linux-image-4.9.0-9-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance           1.1.0-2.3

Versions of packages linux-image-4.9.0-9-amd64 suggests:
pn  debian-kernel-handbook  <none>
ii  grub-pc                 2.02~beta3-5+deb9u1A~4.3.3.201812061306
pn  linux-doc-4.9           <none>

Versions of packages linux-image-4.9.0-9-amd64 is related to:
ii  firmware-amd-graphics     20161130-5
ii  firmware-atheros          20161130-5
ii  firmware-bnx2             20161130-5
ii  firmware-bnx2x            20161130-5
ii  firmware-brcm80211        20161130-5
ii  firmware-cavium           20161130-5
pn  firmware-intel-sound      <none>
ii  firmware-intelwimax       20161130-5
pn  firmware-ipw2x00          <none>
pn  firmware-ivtv             <none>
ii  firmware-iwlwifi          20161130-5
ii  firmware-libertas         20161130-5
ii  firmware-linux-nonfree    20161130-5
ii  firmware-misc-nonfree     20161130-5
ii  firmware-myricom          20161130-5
ii  firmware-netxen           20161130-5
ii  firmware-qlogic           20161130-5
ii  firmware-realtek          20161130-5
pn  firmware-samsung          <none>
pn  firmware-siano            <none>
ii  firmware-ti-connectivity  2016113

[toc] | [next] | [standalone]

#64521 — Bug#931111: linux-image-4.9.0-9: Memory "leak" caused by CGroup as used by pam_systemd

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2019-07-23 at 15:56 +0200, Philipp Hahn wrote:
[...]
> - when the job / session terminates, the directory is deleted by
> pam_systemd.
> 
> - but the Linux kernel still uses the CGroup to track kernel internal
> memory (SLAB objects, pending cache pages, ...?)
> 
> - inside the kernel the CGroup is marked as "dying", but it is only
> garbage collected very later on
[...]
> I do not know who is at fault here, if it is
> - the Linux kernel for not freeing those resources earlier
> - systemd for using CGs in a broken way
> - someone others fault.
[...]

I would say this is a kernel bug.  I think it's the same problem that
this patch series is trying to solve:
https://lwn.net/ml/linux-kernel/20190611231813.3148843-1-guro@fb.com/

Does the description there seem to match what you're seeing?

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web