Comment 61 for bug 1759920

I think that I've figured out this lockup thanks to some information in duplicate bugs. Specifically, this comment:

https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1760264/comments/7

as well as the nice git bisect work of jsalisbury that I recently discovered in bug 1746418. This is the problematic commit:

https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/artful/commit/?id=96d520d

When the kernel does a task switch due to a task that was confined by AppArmor exiting, the task's pi_lock is taken in the exit() path and then switch_mm() is calling ___ptrace_may_access() which then calls down into apparmor which then calls into audit if the old task can't ptrace the new task. Eventually, the audit subsystem tries to take the pi_lock again when waking up the task.

This would be a little easier to be sure of with a nice lockdep warning from a debug kernel build but I'm fairly sure this is what's going on. I suspect that swapping out the commit above with this upstream commit will fix the problem:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18bf3c3ea

It doesn't call into AppArmor to see if IBPB should be used when switching tasks. I'll build a test kernel for affected folks to test with. In the meantime, if someone affected wanted to boot with the apparmor=0 kernel command line option (with the latest artful kernel, without the noibpb kernel command line option, and with the latest intel-microcode package), I'd really appreciate it.