there are a couple things going on here. The batch update recompiles the policy which is cpu intensive, more so as multiple profiles are being done in parallel. Once done, the compiled policy is cached in /etc/apparmor.d/cache/
We have discussed dropping the parallel compute part which would help reducing the load, and memory consumption
to replicate the compile load do
> sudo rm /etc/apparmor.d/cache/*
> sudo /etc/init.d/apparmor reload
The memory error message is simple bug where the __NO_WARN flag got missed on the fast path of a memory allocation, that falls back to a slower vmalloc when it fails.
The perpetual effect being reported by Johan is another bug that I haven't been able to rule out as being related to this bug yet.
there are a couple things going on here. The batch update recompiles the policy which is cpu intensive, more so as multiple profiles are being done in parallel. Once done, the compiled policy is cached in /etc/apparmor. d/cache/
We have discussed dropping the parallel compute part which would help reducing the load, and memory consumption
to replicate the compile load do d/cache/ * d/apparmor reload
> sudo rm /etc/apparmor.
> sudo /etc/init.
The memory error message is simple bug where the __NO_WARN flag got missed on the fast path of a memory allocation, that falls back to a slower vmalloc when it fails.
The perpetual effect being reported by Johan is another bug that I haven't been able to rule out as being related to this bug yet.