]> sourceware.org Git - systemtap.git/commit
Revert "runtime: unregister the control channel before cleaning up"
authorSultan Alsawaf <sultan@openresty.com>
Fri, 27 Aug 2021 21:00:26 +0000 (14:00 -0700)
committerSultan Alsawaf <sultan@openresty.com>
Fri, 27 Aug 2021 21:48:42 +0000 (14:48 -0700)
commit0b5bc934a2576f642250e5e41c748cbb447ab3b5
tree5e991685cc58a30e340e2e9a6a324b039f4892fb
parent166a95089af2f7c911afd85c53e6bdaeba95b950
Revert "runtime: unregister the control channel before cleaning up"

This reverts commit dbe08f1acbdf47718a5f4c2a965b246c778eaac6.

There's a circular dependency because _stp_cleanup_and_exit() may send a
message over the control channel to indicate an issue, like with
_stp_warn(). The reordering thus causes this crash:

BUG: unable to handle kernel paging request at ffff8800ffffffff
IP: [<ffffffff81436c39>] __list_del_entry+0x29/0xd0
PGD 385f067 PUD 0
Oops: 0000 [#1] SMP
CPU: 14 PID: 28496 Comm: staprun-d Kdump: loaded Tainted: GF          OE  ------------ T 3.10.0-1127.19.1.el7.x86_64.debug #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 04/01/2014
task: ffff88016f948000 ti: ffff880055a88000 task.ti: ffff880055a88000
RIP: 0010:[<ffffffff81436c39>]  [<ffffffff81436c39>] __list_del_entry+0x29/0xd0
RSP: 0018:ffff880055a8bd18  EFLAGS: 00010006
RAX: ffff8800ffffffff RBX: ffff8800364d8b40 RCX: dead000000000200
RDX: ffff8800364d8cc0 RSI: ffffffffc116e204 RDI: ffff8800364d8b40
RBP: ffff880055a8bd18 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800364d8660
R13: ffff8800364d8678 R14: 0000000000000092 R15: 0000000000000000
FS:  00007fcdb6ff7780(0000) GS:ffff880237200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8800ffffffff CR3: 000000015ed98000 CR4: 0000000000360fe0
DR0: ffffffffc044a0e0 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
 [<ffffffffc116e218>] _stp_mempool_alloc+0x38/0x80 [stap_b0934ab5a589458489ec9c296ca81d66_20480]
 [<ffffffffc1173114>] _stp_ctl_send+0xc4/0x350 [stap_b0934ab5a589458489ec9c296ca81d66_20480]
 [<ffffffffc1172ef3>] _stp_vlog.constprop.133+0xf3/0x1d0 [stap_b0934ab5a589458489ec9c296ca81d66_20480]
 [<ffffffffc1173034>] _stp_warn+0x64/0x80 [stap_b0934ab5a589458489ec9c296ca81d66_20480]
 [<ffffffffc1177b87>] _stp_cleanup_and_exit+0x367/0x410 [stap_b0934ab5a589458489ec9c296ca81d66_20480]
 [<ffffffffc117ea0a>] cleanup_module+0x1a/0xe0 [stap_b0934ab5a589458489ec9c296ca81d66_20480]
 [<ffffffff8115420e>] SyS_delete_module+0x19e/0x310
 [<ffffffff81895d3e>] tracesys+0xa6/0xcc

The original bug that the reorder attempted to fix is already fixed by
166a95089 ("runtime: fix panics when polling on the control channel
while unloading"). That commit doesn't allow delete_module() to run when
there are open file descriptors to the control channel, which guarantees
that the control channel cannot be in use during module cleanup. Thus,
we can simply restore the old ordering.
runtime/transport/transport.c
This page took 0.032224 seconds and 5 git commands to generate.