Bug 799399

Summary: ftrace_dump() can cause issues on RT
Product: Red Hat Enterprise MRG Reporter: Steven Rostedt <srostedt>
Component: realtime-kernelAssignee: John Kacur <jkacur>
Status: CLOSED ERRATA QA Contact: David Sommerseth <davids>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.2CC: bhu, jkacur, jkastner, lgoncalv, ovasik
Target Milestone: 2.2   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
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
 Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-19 18:03:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Also check for interrupts disabled in ring buffer grabbing read lock none

Description Steven Rostedt 2012-03-02 16:31:41 UTC 
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.
Comment 1 Steven Rostedt 2012-03-02 16:35:49 UTC 
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.
Comment 2 John Kacur 2012-05-23 12:53:22 UTC 
This fix is equivalent to 9922864

git describe --contains 9922864
v3.2.14-rt24~9

Adding note to kernel-rt.spec
Comment 7 John Kacur 2012-06-20 22:26:08 UTC 
    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
Comment 9 errata-xmlrpc 2012-09-19 18:03:39 UTC 
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