Comment 9 for bug 1645037

I think I may have replicated, in that I got log entries with task blocked for more than 120 seconds, very similar to the above logs. And the apparmor_parser could running ps on the system did show several apparmor_parsers waiting. However it did not crash nor did the apparmor_parser instances hang for ever, it all eventually cleared up.

To replicate I overloaded the system spawning 1000 apparmor_parsers loading/replacing profiles and 1000 apparmor_parsers removing profiles. This resulted in each parser competing for the policy load mutex lock, that causes all loads and replaces to be serialized. With the system under very high load several processes even after obtaining the policy mutex would be slept waiting on the memory subsystem and oom killer.

This isn't an exact parallel as I didn't cause it to create namespaces etc, I am now planning to do that as another round of testing.