* Unkillable processes due to PTRACE_TRACEME again
@ 2016-12-02 18:48 Dmitry Vyukov
2016-12-02 21:02 ` Pavel Machek
2016-12-05 10:46 ` Oleg Nesterov
0 siblings, 2 replies; 8+ messages in thread
From: Dmitry Vyukov @ 2016-12-02 18:48 UTC (permalink / raw)
To: Oleg Nesterov, Pavel Machek, Denys Vlasenko, jan.kratochvil,
palves, Roland McGrath
Cc: syzkaller, LKML
Hello,
There was an issue discussed a year ago which leads to
unkillalble/unwaitable zombie processes due to PTRACE_TRACEME:
https://groups.google.com/d/msg/syzkaller/uGzwvhlCXAw/E-cfY2ejAgAJ
and I though it has been fixed by "wait/ptrace: assume __WALL if the
child is traced":
https://groups.google.com/d/msg/syzkaller/caeB1ebZWAs/gcbvcM2HDAAJ
I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
the same unwaitable zombie processes.
Reproducer is:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/syscall.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <signal.h>
void *thr(void *arg)
{
ptrace(PTRACE_TRACEME, 0, 0, 0);
}
int main()
{
int pid = fork();
if (pid == 0) {
pthread_t th;
pthread_create(&th, 0, thr, 0);
usleep(100000);
exit(0);
}
usleep(200000);
kill(pid, SIGKILL);
int status = 0;
waitpid(pid, &status, __WALL);
return 0;
}
It creates the following process tree:
root 15730 0.0 0.0 1156 4 pts/0 S+ 18:33 0:00 |
\_ ./a.out
root 15731 0.0 0.0 0 0 pts/0 Zl+ 18:33 0:00 |
\_ [a.out] <defunct>
Both threads of the child processes terminated:
# ls -l /proc/15731/task/
total 0
dr-xr-xr-x 7 root root 0 Dec 2 18:33 15731
dr-xr-xr-x 7 root root 0 Dec 2 18:33 15732
root@dvyukov-z840:~# cat /proc/15731/status
Name: a.out
State: Z (zombie)
Tgid: 15731
Ngid: 0
Pid: 15731
PPid: 15730
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 0
Groups: 0
NStgid: 15731
NSpid: 15731
NSpgid: 15730
NSsid: 6670
Threads: 2
SigQ: 1/3098
SigPnd: 0000000000000000
ShdPnd: 0000000000000100
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180000000
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
# cat /proc/15732/status
Name: a.out
State: Z (zombie)
Tgid: 15731
Ngid: 0
Pid: 15732
PPid: 15730
TracerPid: 15730
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 0
Groups: 0
NStgid: 15731
NSpid: 15732
NSpgid: 15730
NSsid: 6670
Threads: 2
SigQ: 1/3098
SigPnd: 0000000000000000
ShdPnd: 0000000000000100
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180000000
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
The parent process is blocked in waitpid(__WALL):
# cat /proc/15730/stack
[<ffffffff8140fbbb>] do_wait+0x34b/0xb30 kernel/exit.c:1574
[< inline >] SYSC_wait4 kernel/exit.c:1684
[<ffffffff814143bd>] SyS_wait4+0x20d/0x340 kernel/exit.c:1653
[<ffffffff81009a24>] do_syscall_64+0x2f4/0x940 arch/x86/entry/common.c:280
[<ffffffff881a3dcd>] entry_SYSCALL64_slow_path+0x25/0x25
arch/x86/entry/entry_64.S:251
Shouldn't __WALL cause the wait to return?
Again, it's easy to change the repro so that the process first
reparents to init, and then does PTRACE_TRACEME. Which will cause a
forever hanged processes.
Thanks
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unkillable processes due to PTRACE_TRACEME again
2016-12-02 18:48 Unkillable processes due to PTRACE_TRACEME again Dmitry Vyukov
@ 2016-12-02 21:02 ` Pavel Machek
2016-12-03 15:55 ` Dmitry Vyukov
2016-12-05 10:46 ` Oleg Nesterov
1 sibling, 1 reply; 8+ messages in thread
From: Pavel Machek @ 2016-12-02 21:02 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Oleg Nesterov, Denys Vlasenko, jan.kratochvil, palves,
Roland McGrath, syzkaller, LKML
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
On Fri 2016-12-02 19:48:40, Dmitry Vyukov wrote:
> Hello,
>
> There was an issue discussed a year ago which leads to
> unkillalble/unwaitable zombie processes due to PTRACE_TRACEME:
> https://groups.google.com/d/msg/syzkaller/uGzwvhlCXAw/E-cfY2ejAgAJ
> and I though it has been fixed by "wait/ptrace: assume __WALL if the
> child is traced":
> https://groups.google.com/d/msg/syzkaller/caeB1ebZWAs/gcbvcM2HDAAJ
>
> I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
"Now on"?
> the same unwaitable zombie processes.
Well.. I guess git bisect is one option...?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unkillable processes due to PTRACE_TRACEME again
2016-12-02 21:02 ` Pavel Machek
@ 2016-12-03 15:55 ` Dmitry Vyukov
2016-12-03 19:11 ` Pavel Machek
0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Vyukov @ 2016-12-03 15:55 UTC (permalink / raw)
To: syzkaller
Cc: Oleg Nesterov, Denys Vlasenko, jan.kratochvil, palves,
Roland McGrath, LKML
On Fri, Dec 2, 2016 at 10:02 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Fri 2016-12-02 19:48:40, Dmitry Vyukov wrote:
>> Hello,
>>
>> There was an issue discussed a year ago which leads to
>> unkillalble/unwaitable zombie processes due to PTRACE_TRACEME:
>> https://groups.google.com/d/msg/syzkaller/uGzwvhlCXAw/E-cfY2ejAgAJ
>> and I though it has been fixed by "wait/ptrace: assume __WALL if the
>> child is traced":
>> https://groups.google.com/d/msg/syzkaller/caeB1ebZWAs/gcbvcM2HDAAJ
>>
>> I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
>
> "Now on"?
Yes.
>> the same unwaitable zombie processes.
>
> Well.. I guess git bisect is one option...?
I've checked on:
commit 91c4e8ea8f05916df0c8a6f383508ac7c9e10dba
Author: Oleg Nesterov <oleg@redhat.com>
Date: Mon May 23 16:23:53 2016 -0700
wait: allow sys_waitid() to accept __WNOTHREAD/__WCLONE/__WALL
and the program hangs the same way. So it seems that it was just never fixed.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unkillable processes due to PTRACE_TRACEME again
2016-12-03 15:55 ` Dmitry Vyukov
@ 2016-12-03 19:11 ` Pavel Machek
0 siblings, 0 replies; 8+ messages in thread
From: Pavel Machek @ 2016-12-03 19:11 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzkaller, Oleg Nesterov, Denys Vlasenko, jan.kratochvil, palves,
Roland McGrath, LKML
[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]
Hi!
You cc-ed me on initial mail, I replied, and you removed me from cc. Ouch.
On Sat 2016-12-03 16:55:49, Dmitry Vyukov wrote:
> On Fri, Dec 2, 2016 at 10:02 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Fri 2016-12-02 19:48:40, Dmitry Vyukov wrote:
> >> Hello,
> >>
> >> There was an issue discussed a year ago which leads to
> >> unkillalble/unwaitable zombie processes due to PTRACE_TRACEME:
> >> https://groups.google.com/d/msg/syzkaller/uGzwvhlCXAw/E-cfY2ejAgAJ
> >> and I though it has been fixed by "wait/ptrace: assume __WALL if the
> >> child is traced":
> >> https://groups.google.com/d/msg/syzkaller/caeB1ebZWAs/gcbvcM2HDAAJ
> >>
> >> I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
> >
> > "Now on"?
>
> Yes.
>
> >> the same unwaitable zombie processes.
> >
> > Well.. I guess git bisect is one option...?
>
> I've checked on:
>
> commit 91c4e8ea8f05916df0c8a6f383508ac7c9e10dba
> Author: Oleg Nesterov <oleg@redhat.com>
> Date: Mon May 23 16:23:53 2016 -0700
> wait: allow sys_waitid() to accept __WNOTHREAD/__WCLONE/__WALL
>
> and the program hangs the same way. So it seems that it was just never fixed.
Ouch #2. Oleg, any ideas?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unkillable processes due to PTRACE_TRACEME again
2016-12-02 18:48 Unkillable processes due to PTRACE_TRACEME again Dmitry Vyukov
2016-12-02 21:02 ` Pavel Machek
@ 2016-12-05 10:46 ` Oleg Nesterov
2016-12-05 11:00 ` Oleg Nesterov
1 sibling, 1 reply; 8+ messages in thread
From: Oleg Nesterov @ 2016-12-05 10:46 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Pavel Machek, Denys Vlasenko, jan.kratochvil, palves,
Roland McGrath, syzkaller, LKML
On 12/02, Dmitry Vyukov wrote:
>
> I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
> the same unwaitable zombie processes.
This is another thing, and notabug. This is how ptrace works,
> void *thr(void *arg)
> {
> ptrace(PTRACE_TRACEME, 0, 0, 0);
> }
>
> int main()
> {
> int pid = fork();
> if (pid == 0) {
> pthread_t th;
> pthread_create(&th, 0, thr, 0);
> usleep(100000);
> exit(0);
> }
> usleep(200000);
> kill(pid, SIGKILL);
> int status = 0;
> waitpid(pid, &status, __WALL);
waitpid(pid) hangs because you need to reap the sub-thread first.
Oleg.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unkillable processes due to PTRACE_TRACEME again
2016-12-05 10:46 ` Oleg Nesterov
@ 2016-12-05 11:00 ` Oleg Nesterov
2016-12-05 14:07 ` Dmitry Vyukov
0 siblings, 1 reply; 8+ messages in thread
From: Oleg Nesterov @ 2016-12-05 11:00 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Pavel Machek, Denys Vlasenko, jan.kratochvil, palves,
Roland McGrath, syzkaller, LKML
On 12/05, Oleg Nesterov wrote:
>
> On 12/02, Dmitry Vyukov wrote:
> >
> > I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
> > the same unwaitable zombie processes.
>
> This is another thing, and notabug. This is how ptrace works,
>
> > void *thr(void *arg)
> > {
> > ptrace(PTRACE_TRACEME, 0, 0, 0);
> > }
> >
> > int main()
> > {
> > int pid = fork();
> > if (pid == 0) {
> > pthread_t th;
> > pthread_create(&th, 0, thr, 0);
> > usleep(100000);
> > exit(0);
> > }
> > usleep(200000);
> > kill(pid, SIGKILL);
> > int status = 0;
> > waitpid(pid, &status, __WALL);
>
> waitpid(pid) hangs because you need to reap the sub-thread first.
I'm afraid I wasn't clear...
So the child process has 2 threads, the leader thread L and the sub-thread T.
waitpid(pid == L->pid) will block until all the threads go away, but since T is
traced it won't autoreap, the tracer should do waitpid(T->pid) first to reap
this zombie. waitpid(-1) should work too.
Oleg.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unkillable processes due to PTRACE_TRACEME again
2016-12-05 11:00 ` Oleg Nesterov
@ 2016-12-05 14:07 ` Dmitry Vyukov
2016-12-05 16:59 ` Oleg Nesterov
0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Vyukov @ 2016-12-05 14:07 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Pavel Machek, Denys Vlasenko, jan.kratochvil, palves,
Roland McGrath, syzkaller, LKML
On Mon, Dec 5, 2016 at 12:00 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 12/05, Oleg Nesterov wrote:
>>
>> On 12/02, Dmitry Vyukov wrote:
>> >
>> > I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
>> > the same unwaitable zombie processes.
>>
>> This is another thing, and notabug. This is how ptrace works,
>>
>> > void *thr(void *arg)
>> > {
>> > ptrace(PTRACE_TRACEME, 0, 0, 0);
>> > }
>> >
>> > int main()
>> > {
>> > int pid = fork();
>> > if (pid == 0) {
>> > pthread_t th;
>> > pthread_create(&th, 0, thr, 0);
>> > usleep(100000);
>> > exit(0);
>> > }
>> > usleep(200000);
>> > kill(pid, SIGKILL);
>> > int status = 0;
>> > waitpid(pid, &status, __WALL);
>>
>> waitpid(pid) hangs because you need to reap the sub-thread first.
>
> I'm afraid I wasn't clear...
>
> So the child process has 2 threads, the leader thread L and the sub-thread T.
> waitpid(pid == L->pid) will block until all the threads go away, but since T is
> traced it won't autoreap, the tracer should do waitpid(T->pid) first to reap
> this zombie. waitpid(-1) should work too.
Do you mean that I need to replace:
waitpid(pid, &status, __WALL);
with:
while (waitpid(-1, &status, __WALL) != pid) {}
?
It seems to work. But want to make sure.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Unkillable processes due to PTRACE_TRACEME again
2016-12-05 14:07 ` Dmitry Vyukov
@ 2016-12-05 16:59 ` Oleg Nesterov
0 siblings, 0 replies; 8+ messages in thread
From: Oleg Nesterov @ 2016-12-05 16:59 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Pavel Machek, Denys Vlasenko, jan.kratochvil, palves,
Roland McGrath, syzkaller, LKML
On 12/05, Dmitry Vyukov wrote:
>
> On Mon, Dec 5, 2016 at 12:00 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 12/05, Oleg Nesterov wrote:
> >>
> >> On 12/02, Dmitry Vyukov wrote:
> >> >
> >> > I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
> >> > the same unwaitable zombie processes.
> >>
> >> This is another thing, and notabug. This is how ptrace works,
> >>
> >> > void *thr(void *arg)
> >> > {
> >> > ptrace(PTRACE_TRACEME, 0, 0, 0);
> >> > }
> >> >
> >> > int main()
> >> > {
> >> > int pid = fork();
> >> > if (pid == 0) {
> >> > pthread_t th;
> >> > pthread_create(&th, 0, thr, 0);
> >> > usleep(100000);
> >> > exit(0);
> >> > }
> >> > usleep(200000);
> >> > kill(pid, SIGKILL);
> >> > int status = 0;
> >> > waitpid(pid, &status, __WALL);
> >>
> >> waitpid(pid) hangs because you need to reap the sub-thread first.
> >
> > I'm afraid I wasn't clear...
> >
> > So the child process has 2 threads, the leader thread L and the sub-thread T.
> > waitpid(pid == L->pid) will block until all the threads go away, but since T is
> > traced it won't autoreap, the tracer should do waitpid(T->pid) first to reap
> > this zombie. waitpid(-1) should work too.
>
> Do you mean that I need to replace:
> waitpid(pid, &status, __WALL);
> with:
> while (waitpid(-1, &status, __WALL) != pid) {}
> ?
Yes. Or, if you knew the pid of the traced thread you could do
// need to do this first, the traced sub-thread won't autoreap,
// and the leader which represents the whole process is not reapable
// until all other threads go away
waitpid(tracee_pid, &status, __WALL);
waitpid(pid, &status, __WALL);
Oleg.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-12-05 17:00 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-02 18:48 Unkillable processes due to PTRACE_TRACEME again Dmitry Vyukov
2016-12-02 21:02 ` Pavel Machek
2016-12-03 15:55 ` Dmitry Vyukov
2016-12-03 19:11 ` Pavel Machek
2016-12-05 10:46 ` Oleg Nesterov
2016-12-05 11:00 ` Oleg Nesterov
2016-12-05 14:07 ` Dmitry Vyukov
2016-12-05 16:59 ` Oleg Nesterov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).