Eventual OOM with profile reloads

Bug #1750594 reported by Jamie Strandboge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
Fix Committed
Undecided
Unassigned

Bug Description

In profile set A I have 120 profiles then in profile set B I have the same 120 profile names but with different rules. If I use apparmor_parser -r on A, then B, then A, etc, eventually OOM is triggered.

Reproducer (I did it with a 768M i386 17.10 desktop install in a VM, but am told that amd64 is affected too, just takes longer):

$ wget http://people.canonical.com/~jamie/aa/bug.tar.gz
$ tar -zxvf ./bug.tar.gz
$ while /bin/true ; do for i in bug/orig/* bug/new/* ; do sudo apparmor_parser --write-cache -O no-expr-simplify --cache-loc=/var/cache/apparmor --quiet -r $i ; done ; done

I tested this with the 4.13 artful release and -updates kernels (ie, before meltdown/spectre and after) with the same result. I'm told the bionic kernel is also affected. 4.10 may also be affected.

First reported here: https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101

description: updated
description: updated
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

From IRC:
07:06 <@jdstrand> mvo: hey, so jjohansen looked at the memory issue quite a bit yesterday. the summary is that the profiles themselves are is a small leak (*much* smaller than 30M; on the order of 2M after processing all the profiles in /var (if I'm reading jj's numbers right))
07:07 <@jdstrand> mvo: so it seems that the system was already under memory pressure, and that straw caused it to oom, but it was simply the straw that broke the camel's back. there were many more straws before it
07:08 <@jdstrand> mvo: jjohansen said he'll contine searching for that small leak. he's also investigating reducing that 30M by quite a bit

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

I confirmed this bug and I will provide a simple reproducer. I'm bisecting kernels to find what is causing the (most) of the leak. I will post additional details as they become available.

Changed in apparmor:
status: New → Confirmed
Revision history for this message
Zygmunt Krynicki (zyga) wrote :

Some quick facts from the forum:

 First broken kernel is 4.13, last working kernel is 4.8.
 Leak affects only the code path where the profile is identical.
 Loading otherwise-empty profile with a random rule in a loop doesn't leak memory.

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

I can confirm that jj's patch fixes this issue.

Changed in apparmor:
status: Confirmed → Fix Committed
Revision history for this message
intrigeri (intrigeri) wrote :

I wanted to triage this but I don't know what's "jj's patch". I found no reference to this bug report in our Git repo, so I guess it was a kernel patch? If so, was it merged in mainline?

Revision history for this message
John Johansen (jjohansen) wrote :

It was a kernel patch (really it should have been attached here), and it was upstreamed so if there is a similar issue it is a different bug.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.