Hi Ingo and Andi,
I've run into an issue with x86_64 CONFIG_PREEMPT_RT kernels that I
would like to mention. I'm afraid that I have no ideas for a solution.
I created a kernel with the following items:
linux-2.6.22.tar.bz2
patch-2.6.23-rc2.bz
patch-2.6.23-rc2-rt2
And I enabled CONFIG_PREEMPT_RT along with the various DEBUG parameters,
such as CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP, etc.
When I run some ptrace-base tests that make use of int3 breakpoints,
singlesteps or hardware debug registers on x86_64 systems, I see BUG
messages that indicate an issue with calling force_sig()/force_sig_info()
from do_debug()/do_int3()->do_trap() since we're running on the IST
kernel stack with preemptions disabled.
[ It's interesting that the i386 version of do_trap() has
some CONFIG_PREEMPT_RT code in it that does a
local_irq_enable() and preempt_check_resched() before
it gets to the force_sig() code, but that won't work
for x86_64 due to the per-cpu IST stack. ]
Below is an example of the output from a ptrace singlestep test where
we actually end up switching away from the current task:
BUG: scheduling while atomic: ssdd/0x00000002/5333, CPU#1
Call Trace:
<#DB> [<ffffffff8057f304>] __sched_text_start+0xcc/0x90a
[<ffffffff80236634>] release_console_sem+0x17f/0x1ae
[<ffffffff80236a06>] printk+0x8d/0x95
[<ffffffff80252887>] __rt_mutex_adjust_prio+0x9/0x1b
[<ffffffff80253134>] task_blocks_on_rt_mutex+0x17d/0x1d0
[<ffffffff8057fe0f>] schedule+0xdf/0xff
[<ffffffff80580fb9>] rt_spin_lock_slowlock+0xed/0x18a
[<ffffffff80282459>] kmem_cache_alloc+0x56/0x118
[<ffffffff8023f669>] __sigqueue_alloc+0x32/0x5d
[<ffffffff8023fd79>] send_signal+0x65/0x149
[<ffffffff8023febf>] specific_send_sig_info+0x62/0x96
[<ffffffff8023ff72>] force_sig_info+0x7f/0x9b
[<ffffffff8020e445>] do_debug+0xf2/0x141
[<ffffffff8023fb7a>] signal_wake_up+0x1e/0x2d
[<ffffffff8023fee8>] specific_send_sig_info+0x8b/0x96
[<ffffffff8023ff87>] force_sig_info+0x94/0x9b
[<ffffffff80581fb3>] debug+0x93/0x9f
and here's one more example of an int3 breakpoint:
BUG: sleeping function called from invalid context de5(4222) at
kernel/rtmutex.c:636
in_atomic():1 [00000001], irqs_disabled():0
Call Trace:
<#DB> [<ffffffff80225608>] __might_sleep+0xf8/0xfa
[<ffffffff8068bfae>] __rt_spin_lock+0x2c/0x4e
[<ffffffff8068bfd9>] rt_spin_lock+0x9/0xb
[<ffffffff8023ad82>] force_sig_info+0x25/0xa9
[<ffffffff8023b3a1>] force_sig+0x11/0x13
[<ffffffff8020bdd4>] do_trap+0x1dd/0x27b
[<ffffffff8023dfdf>] __raw_notifier_call_chain+0x9/0xb
[<ffffffff8023dff0>] raw_notifier_call_chain+0xf/0x11
[<ffffffff8020c911>] do_int3+0x6a/0x7e
[<ffffffff8068cfe3>] int3+0x93/0xb0
<<EOE>>
---------------------------
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
----------------------------------------
.. [<ffffffff8020c8e8>] .... do_int3+0x41/0x7e
.....[<ffffffff8068cfe3>] .. ( <= int3+0x93/0xb0)
BUG: de5:4222 task might have lost a preemption check!
Call Trace:
<#DB> [<ffffffff8022d343>] preempt_enable_no_resched+0x5c/0x5e
[<ffffffff8020c920>] do_int3+0x79/0x7e
[<ffffffff8068cfe3>] int3+0x93/0xb0
<<EOE>>
---------------------------
| preempt count: 00000000 ]
| 0-level deep critical section nesting:
----------------------------------------
Thanks in advance for any input or comments.
John Blackwood [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
