ftrace_dump() is a debug utility to dump out the ftrace ring buffer to console, and is useful for when ftrace_dump_on_oops is set on the command line. It can be dumped from any location in the kernel. As reading the ftrace ring buffer is not the same as writing, the reader expects to take a lock. In RT, this lock happens to be a mutex. This usually isn't an issue because readers are usually userspace tasks asking to see what's in the ftrace ring buffer. But ftrace_dump() is the exception, and can be called from any context. There's already a check in the ring buffer to see if the context is OK to take the lock. In no-RT it just checks if it's in an NMI context or not, as the lock is a spin lock that disables interrupts. In RT, there's a check to see if preemption is disabled. The issue is that the RT version only checks the preempt count, and does not check if interrupts are disabled. If interrupts are disabled, the RT version will still grab the lock and might cause a scheduling while atomic. Not to mention, it shouldn't grab the lock in this context anyway, as we want to print the ftrace ring buffer regardless.
Created attachment 567106 [details] Also check for interrupts disabled in ring buffer grabbing read lock In RT, check if interrupts are disabled before giving the OK to grab the ring buffer reader lock.
This fix is equivalent to 9922864 git describe --contains 9922864 v3.2.14-rt24~9 Adding note to kernel-rt.spec
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: RT in_atomic only checks preempt_count Consequence: RT can grab the lock even if irqs are disabled, and cause a scheduling while atomic Fix: Check if interrupts are disabled before giving the OK to grab the ring buffer reader lock. Result: The ring buffer reader lock works correctly
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-1282.html