[BUG] utrace_attach_task() never returns when called from the report_clone callback

[Ananth N Mavinakayanahalli]

Roland,

With the current utrace/master tree, I am seeing that utrace_attach_task()
never returns when invoked from the clone callback. The same module
works fine with prior utrace (rcu as well as with my embed version).

The testcase is simple:
a. attach an engine to attachstop-mt (from the gdb testsuite) _before_ it
   calls pthread_create.
b. Watch for CLONE_THREAD and try to attach a utrace engine to the new
   thread. The utrace_attach_task() call never returns.

If the utrace module is unloaded, the kernel barfs with the following
innocuous information:

BUG: unable to handle kernel paging request at fffffffffffffdff
IP: [<ffffffffa012009a>] 0xffffffffa012009a
PGD 203067 PUD 204067 PMD 0 
Oops: 0002 [#1] SMP 
last sysfs file: /sys/devices/pci0000:01/0000:01:01.1/irq
CPU 6 
Modules linked in: <big list>
[last unloaded: utrace_quiesce_threads]
Pid: 6203, comm: attachstop-mt Not tainted 2.6.29-rc7-ut #1 eserver
xSeries 366-[88632RA]-
RIP: 0010:[<ffffffffa012009a>]  [<ffffffffa012009a>] 0xffffffffa012009a
RSP: 0018:ffff8801d34ebe10  EFLAGS: 00010246
RAX: fffffffffffffdff RBX: ffff8801f11a36c0 RCX: 00000000c0000100
RDX: 0000000000000000 RSI: ffff8801dd0507f8 RDI: ffff88022daf4500
RBP: 00000000fffffff4 R08: ffff8801d34ea000 R09: ffff88022f2596a0
R10: ffff8800280b1600 R11: 0000000000000018 R12: ffff8801d34f1860
R13: ffff8802210dd300 R14: ffff8801dd07e2c0 R15: 00000000003d0f00
FS:  00007f58c8d286e0(0000) GS:ffff88022f18e5c0(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: fffffffffffffdff CR3: 00000002029bd000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process attachstop-mt (pid: 6203, threadinfo ffff8801d34ea000, task
ffff8801d3512440)
Stack:
 00000000003d0f00 ffff8801d34f1860 ffff8802210dd300 ffff8801d3512440
 ffff8801d34ebe70 ffffffffa012028d ffff8801dd050618 ffff8801d35129e0
 ffff8801d35129d8 ffffffff80260480 0000000000000000 ffff8801d34f1860
Call Trace:
 [<ffffffff80260480>] ? utrace_report_clone+0x95/0xfc
 [<ffffffff80239120>] ? do_fork+0x20b/0x2f3
 [<ffffffff804a4035>] ? do_page_fault+0x3c7/0x74e
 [<ffffffff8020c243>] ? stub_clone+0x13/0x20
 [<ffffffff8020bedb>] ? system_call_fastpath+0x16/0x1b
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
RIP  [<ffffffffa012009a>] 0xffffffffa012009a
 RSP <ffff8801d34ebe10>
CR2: fffffffffffffdff
---[ end trace 96bb7eb644ab73a4 ]---

I have verified that the earlier version of utrace works just fine.

In the earlier case, the engine would go directly on to the attached
list if the calling task was the creator of the new thread. This has
changed with the new implementation.

I haven't yet zeroed in on what exact change caused this problem.

Ananth