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.
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.