task_finder2: fix panics due to broken task work cancellation
The task_work_cancel() API uses function pointers to uniquely identify
task work structs, so there's no guarantee that a specific task work
struct we want to cancel is the one that will actually get canceled.
This issue would cause task work structs to be freed while they were
still queued up on the task's task-worker list.
This is an example of one such panic, where the DEBUG_MEM feature
reported that a __stp_tf_task_work struct (56 bytes) wasn't freed,
because that specific task worker got canceled and instead an active
task worker got freed!
orxray_resty_mem_X_35062: ERROR: Memory
ffff8809ed388620 len=56 allocation type: kmalloc. Not freed.
BUG: unable to handle kernel paging request at
ffffffffa0570877
IP: [<
ffffffffa0570877>] 0xffffffffa0570876
PGD
1abd067 PUD
1abe063 PMD
1028286067 PTE 0
Oops: 0010 [#1] SMP
CPU: 3 PID: 1338 Comm: nginx Tainted: G OE ------------ 3.10.0-514.10.2.el7.x86_64.debug #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
task:
ffff880eae2d0000 ti:
ffff880eaf2e4000 task.ti:
ffff880eaf2e4000
RIP: 0010:[<
ffffffffa0570877>] [<
ffffffffa0570877>] 0xffffffffa0570876
RSP: 0018:
ffff880eaf2e7d78 EFLAGS:
00010282
RAX:
0000000000000001 RBX:
0000000000000000 RCX:
0000000000000000
RDX:
ffff8809ed388640 RSI:
0000000000000000 RDI:
ffff8809ed388640
RBP:
ffff880eaf2e7da0 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000001 R11:
ffffffffff90001c R12:
ffffffff8248b1c0
R13:
ffff880eae2d0818 R14:
ffff880eae2d0000 R15:
00007eff3d2490b0
FS:
00007eff3dcd2740(0000) GS:
ffff881037c00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
ffffffffa0570877 CR3:
0000000ebce67000 CR4:
00000000003406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Stack:
ffffffff810c6544 ffff880eaf2e7f58 ffff880eaf2e7e70 ffff880eae2d0000
00007eff3dcb3338 ffff880eaf2e7e38 ffffffff810b31ba ffff880eaf2e7dc0
ffffffff8106c279 ffff880eaf2e7e50 ffff880ef8a792c0 ffff880eaf2e7df8
Call Trace:
[<
ffffffff810c6544>] ? task_work_run+0xb4/0xe0
[<
ffffffff810b31ba>] get_signal_to_deliver+0x85a/0x960
[<
ffffffff8106c279>] ? kvm_sched_clock_read+0x9/0x20
[<
ffffffff810e7b4d>] ? sched_clock_local+0x1d/0x80
[<
ffffffff810e7dd8>] ? sched_clock_cpu+0xb8/0xe0
[<
ffffffff810324a7>] do_signal+0x57/0x6e0
[<
ffffffff8176dba6>] ? int_very_careful+0x5/0xd
[<
ffffffff81032b8f>] do_notify_resume+0x5f/0xb0
[<
ffffffff8176dbfd>] int_signal+0x12/0x17
Code: Bad RIP value.
RIP [<
ffffffffa0570877>] 0xffffffffa0570876
RSP <
ffff880eaf2e7d78>
CR2:
ffffffffa0570877
---[ end trace
1cdf8e5b522b246e ]---