Messages in this thread | | | Subject | [ptrace] Problem with ptrace cleanup logic. | From | Tetsuo Handa <> | Date | Thu, 23 Feb 2012 14:26:39 +0900 |
| |
I noticed that ptrace(PTRACE_ATTACH, 1) makes the global init process remain killable even after a process that called ptrace(PTRACE_ATTACH, 1) exits.
Steps to reproduce:
(1) Compile ptrace-init.c as ./a.out .
----- ptrace-init.c ----- #include <sys/ptrace.h> #include <stdio.h>
int main(int argc, char *argv[]) { printf("PTRACE_ATTACH=%ld\n", ptrace(PTRACE_ATTACH, 1)); return 0; } ----- ptrace-init.c -----
(2) Run below commands as root user.
# ./a.out # kill -KILL 1
Result on 2.6.26.8 to 2.6.29.6 is
# head -n 2 /proc/1/status Name: init State: S (sleeping) # ./a.out PTRACE_ATTACH=0 # head -n 2 /proc/1/status Name: init State: S (sleeping) # kill -KILL 1
Result on 2.6.30.10 to 3.3-rc4 is
# head -n 2 /proc/1/status Name: init State: S (sleeping) # ./a.out PTRACE_ATTACH=0 # head -n 2 /proc/1/status Name: init State: T (stopped) # kill -KILL 1 Kernel panic - not syncing: Attempted to kill init!
As you can see, the global init process remains "T (stopped)" state. I think this is a regression because it always triggers kernel panic upon sysvinit's shutdown sequence.
Sending all processes the TERM signal...done. Sending all processes the KILL signal... Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 3.2.7 #1 Call Trace: [<c10354c3>] panic+0x63/0x170 [<c1038123>] find_new_reaper+0xa3/0xb0 [<c103824c>] forget_original_parent+0x2c/0x180 [<c11c7f24>] ? get_current_tty+0x54/0x70
If ptrace-init.c were expected to do some cleanup logic before exit, we can't force ptrace-init.c to do it, for ptrace-init.c can be terminated unexpectedly.
| |