Comment 61 for bug 1759920

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

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

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:

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.