Bug 799399 - ftrace_dump() can cause issues on RT
ftrace_dump() can cause issues on RT
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: realtime-kernel (Show other bugs)
2.2
Unspecified Unspecified
unspecified Severity unspecified
: 2.2
: ---
Assigned To: John Kacur
David Sommerseth
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-02 11:31 EST by Steven Rostedt
Modified: 2016-05-22 19:34 EDT (History)
5 users (show)

See Also:
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 14:03:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Also check for interrupts disabled in ring buffer grabbing read lock (837 bytes, patch)
2012-03-02 11:35 EST, Steven Rostedt
no flags Details | Diff

  None (edit)
Description Steven Rostedt 2012-03-02 11:31:41 EST
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 11:35:49 EST
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 08:53:22 EDT
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 18:26:08 EDT
    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 14:03:39 EDT
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

Note You need to log in before you can comment on or make changes to this bug.