Re: Backward compatibility for insn probe point

[David Smith <dsmith@redhat.com>]

David Smith wrote:
> Maynard Johnson wrote:
>>> David Smith wrote:
>>> One last thing.  I thought I'd try block stepping, so I got access to an
>>> ia64 machine.  Unfortunately, using systemtap insn probes (either single
>>> or block step) lock up the system with a spinlock lockup.  Sigh.
>> Does anyone know who maintains ia64/utrace?  David, was the above error
>> on "old" utrace or "new"?
> 
> The error is on "old" utrace.  I'm trying to look into the ia64 utrace
> problem now.

Here's what I see on the console (running lockdep enabled
2.6.18-146.el5debug):

====
BUG: spinlock lockup on CPU#0, ls/2576, e0000040fe1092d8 (Tainted: G)

Call Trace:
 [<a000000100013b40>] show_stack+0x40/0xa0
                                sp=e0000003f640f870 bsp=e0000003f6409440
 [<a000000100013bd0>] dump_stack+0x30/0x60
                                sp=e0000003f640fa40 bsp=e0000003f6409428
 [<a0000001002de200>] _raw_spin_lock+0x200/0x260
                                sp=e0000003f640fa40 bsp=e0000003f64093e8
 [<a00000010065ff50>] _spin_lock_irqsave+0x30/0x60
                                sp=e0000003f640fa40 bsp=e0000003f64093c0
 [<a00000010009c730>] force_sig_info+0x30/0x160
                                sp=e0000003f640fa40 bsp=e0000003f6409380
 [<a000000100661450>] ia64_fault+0xff0/0x1280
                                sp=e0000003f640fa40 bsp=e0000003f6409328
 [<a00000010000bfe0>] __ia64_leave_kernel+0x0/0x280
                                sp=e0000003f640fc60 bsp=e0000003f6409328
 [<a0000001002de0d0>] _raw_spin_lock+0xd0/0x260
                                sp=e0000003f640fe30 bsp=e0000003f64092c0
 [<a00000010065ff50>] _spin_lock_irqsave+0x30/0x60
                                sp=e0000003f640fe30 bsp=e0000003f6409298
 [<a00000010009c730>] force_sig_info+0x30/0x160
                                sp=e0000003f640fe30 bsp=e0000003f6409258
 [<a00000010009c890>] force_sig+0x30/0x60
                                sp=e0000003f640fe30 bsp=e0000003f6409230
 [<a00000010002cfe0>] syscall_trace_leave+0x100/0x140
                                sp=e0000003f640fe30 bsp=e0000003f64091d0
 [<a00000010000bda0>] __ia64_trace_syscall+0x100/0x110
                                sp=e0000003f640fe30 bsp=e0000003f64091d0
 [<a000000000010620>] __start_ivt_text+0xffffffff00010620/0x400
                                sp=e0000003f6410000 bsp=e0000003f64091d0
====

From what I can tell, the spinlock that is stuck is
current->sighand->siglock.  force_sig_info() (from kernel/signal.c:739)
grabs the spinlock, but we get a fault somewhere? and end up in
__ia64_leave_kernel() (from arch/ia64/kernel/entry.S:813).  The fault
handling in ia64_fault() calls force_sig_info() again, which tries to
grab same spinlock again.

If anyone has a better understanding of this, I'd love to know how we
ended up in __ia64_leave_kernel().

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)