Bug 311391 - with DEBUG_PI_LIST a constantly prints out to console on futex
with DEBUG_PI_LIST a constantly prints out to console on futex
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: realtime-kernel (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Arnaldo Carvalho de Melo
Depends On:
  Show dependency treegraph
Reported: 2007-09-28 13:29 EDT by Steven Rostedt
Modified: 2008-02-27 14:57 EST (History)
0 users

See Also:
Fixed In Version: 2.6.21-51
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-05 12:18:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
DEBUG_PI_LIST RT fix (1.54 KB, patch)
2007-10-23 07:29 EDT, Arnaldo Carvalho de Melo
no flags Details | Diff
updated patch to fix futex DEBUG_PI printk storm on debug -rt kernel (1.08 KB, text/x-patch)
2007-11-30 11:31 EST, Clark Williams
no flags Details

  None (edit)
Description Steven Rostedt 2007-09-28 13:29:11 EDT
Description of problem:

When DEBUG_PI_LIST is enabled, we get a large amount of warnings with

BUG: at lib/plist.c:60 plist_check_head()
 [<c040618f>] dump_trace+0x5f/0x107
 [<c0406254>] show_trace_log_lvl+0x1d/0x3a
 [<c0406894>] show_trace+0x12/0x14
 [<c040691e>] dump_stack+0x16/0x18
 [<c0504158>] plist_check_head+0x3f/0x54
 [<c0504227>] plist_del+0x18/0x75
 [<c04480b3>] unqueue_me+0x61/0x8e
 [<c0448cb2>] futex_wait+0x3d1/0x466
 [<c04490cc>] do_futex+0x73/0xfef
 [<c044a116>] sys_futex+0xce/0xe1
 [<c04050e5>] syscall_call+0x7/0xb
 [<ffffe410>] pg0+0x3f408410/0xfffff4bc
| preempt count: 00000000 ]
| 0-level deep critical section nesting:

Looking at plist.c:60

	if (head->lock)

head is a pointer to the plist head.

The cause of this is that the futex code uses plist for the hash queues.
Each hash queue has its own lock to manipulate it. Instead of using the
plist lock, it locks the hash lock instead. To prevent this from triggering
these outputs, the futex code assigns plist->lock = hash->lock. So the test
to see if the lock is held succeeds.

The problem in PREEMPT_RT is that the hash lock is a spinlock that is converted
to a mutex where as the plist lock stays as a spinlock (raw lock). The reason
for this is that the plist is also used for the internals of the mutex code.

Now when this switch happens, the debugging test of spin_is_locked(head->lock)
fails since its testing a mutex instead of a spinlock.

Note: when this is configured, there is indeed a warning of assigning
incompatible types when plist->lock = hash->lock.

We'll need to determine what the proper fix for this is.
Comment 1 Arnaldo Carvalho de Melo 2007-10-02 13:03:51 EDT
First reaction: Shouldn't we use TYPE_OF tricks on spin_is_locked to apply the
right test for being locked?
Comment 2 Steven Rostedt 2007-10-02 13:11:36 EDT
First reply: No, because the code is not a macro, but a function. This means
that the TYPE_OF would always return the same.

The reall bug is that we are pointing a raw_spinlock_t pointer at a spin_lock_t
Comment 3 Arnaldo Carvalho de Melo 2007-10-23 07:28:29 EDT
Patch submitted to linux-rt-users:

Comment 4 Arnaldo Carvalho de Melo 2007-10-23 07:29:45 EDT
Created attachment 234971 [details]
Comment 5 Clark Williams 2007-11-30 11:31:01 EST
Created attachment 274001 [details]
updated patch to fix futex DEBUG_PI printk storm on debug -rt kernel

New patch from rostedt

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