Bug 311391

Description of problem:

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

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)
		WARN_ON_SMP(!spin_is_locked(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.