Linux-Trace-Devel Archive on lore.kernel.org
 help / color / Atom feed
* Mutual debugging of 2 processes can stuck in unkillable stopped state
@ 2021-03-29 15:28 Igor Zhbanov
  2021-03-29 16:49 ` Oleg Nesterov
  0 siblings, 1 reply; 7+ messages in thread
From: Igor Zhbanov @ 2021-03-29 15:28 UTC (permalink / raw)
  To: linux-trace-devel, Oleg Nesterov

Mutual debugging of 2 processes can stuck in unkillable stopped state

Hi!

When one process, let's say "A", is tracing the another process "B", and the
process "B" is trying to attach to the process "A", then both of them are
getting stuck in the "t+" state. And they are ignoring all of the signals
including the SIGKILL, so it is not possible to terminate them without
a reboot.

To reproduce:
1) Run two terminals
2) Attach with "strace -p ..." from the first terminal to the shell (bash) of
    the second terminal.
3) In the second terminal run "exec strace -p ..." to attach to the PID of the
    first strace.

Then you'll see that the second strace is hanging without any output. And the
first strace will output following and hang too:
ptrace(PTRACE_SEIZE, 11795, NULL,
        PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT

(The 11795 is the PID of the first strace itself.)

And in the process list you will see following:
ps awux | grep strace
user   11776  0.0  0.0  24752  2248 pts/3    t+   13:53   0:00 strace -p 11795
user   11795  0.0  0.0  24752  3888 pts/1    t+   13:54   0:00 strace -p 11776

I suppose that there should be some way to break the deadlocked debug. And the
system administrator must be able to terminate non-privileged processes.

Thank you.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state
  2021-03-29 15:28 Mutual debugging of 2 processes can stuck in unkillable stopped state Igor Zhbanov
@ 2021-03-29 16:49 ` Oleg Nesterov
  2021-03-29 17:01   ` Igor Zhbanov
  0 siblings, 1 reply; 7+ messages in thread
From: Oleg Nesterov @ 2021-03-29 16:49 UTC (permalink / raw)
  To: Igor Zhbanov; +Cc: linux-trace-devel, linux-kernel

On 03/29, Igor Zhbanov wrote:
>
> Mutual debugging of 2 processes can stuck in unkillable stopped state

can't reproduce and can't understand...

> Hi!
>
> When one process, let's say "A", is tracing the another process "B", and the
> process "B" is trying to attach to the process "A", then both of them are
> getting stuck in the "t+" state. And they are ignoring all of the signals
> including the SIGKILL,

Why do you think so? What is your kernel version?

"t" means TASK_TRACED, SIGKILL should wake it up and terminate.

> so it is not possible to terminate them without
> a reboot.
> 
> To reproduce:
> 1) Run two terminals
> 2) Attach with "strace -p ..." from the first terminal to the shell (bash) of
>    the second terminal.
> 3) In the second terminal run "exec strace -p ..." to attach to the PID of the
>    first strace.
> 
> Then you'll see that the second strace is hanging without any output. And the
> first strace will output following and hang too:
> ptrace(PTRACE_SEIZE, 11795, NULL,
>        PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT
> 
> (The 11795 is the PID of the first strace itself.)
> 
> And in the process list you will see following:
> ps awux | grep strace
> user   11776  0.0  0.0  24752  2248 pts/3    t+   13:53   0:00 strace -p 11795
> user   11795  0.0  0.0  24752  3888 pts/1    t+   13:54   0:00 strace -p 11776

OK, may be they sleep in PTRACE_EVENT_EXIT? After you tried to send SIGKILL?

please show us the output from "cat /proc/{11795,11776}/stack". And
"cat /proc/{11795,11776}/status" just in case.

Oleg.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state
  2021-03-29 16:49 ` Oleg Nesterov
@ 2021-03-29 17:01   ` Igor Zhbanov
  2021-03-29 17:38     ` Oleg Nesterov
  0 siblings, 1 reply; 7+ messages in thread
From: Igor Zhbanov @ 2021-03-29 17:01 UTC (permalink / raw)
  To: Oleg Nesterov; +Cc: linux-trace-devel, linux-kernel

Hi Oleg!

I've tried both 5.3.18 and 5.10.0. The behavior is the same.
The important thing is to run "exec strace -p ..." on the second terminal
to create the loop A->B->A.

So the last line from the first strace we see is:
ptrace(PTRACE_SEIZE, 1990, NULL, PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT

I.e. it printed the syscall prior to its execution and hanged after the
execution.

izh@suse2:~> ps awux|grep strace
izh       1891  0.0  0.0  24752  3828 pts/1    ts+  19:52   0:00 strace -p 1990
izh       1990  0.0  0.0  24752  3628 pts/0    t+   19:53   0:00 strace -p 1891

izh@suse2:~> kill 1990 1891
izh@suse2:~> kill -9 1990 1891

izh@suse2:~> sudo cat /proc/1891/stack
[sudo] password for root:
[<0>] ptrace_stop+0x14a/0x260
[<0>] ptrace_do_notify+0x91/0xb0
[<0>] ptrace_notify+0x4e/0x70
[<0>] do_exit+0x910/0xb70
[<0>] do_group_exit+0x3a/0xa0
[<0>] get_signal+0x124/0x800
[<0>] arch_do_signal_or_restart+0xa9/0x290
[<0>] exit_to_user_mode_prepare+0xe7/0x1a0
[<0>] syscall_exit_to_user_mode+0x18/0x40
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

izh@suse2:~> sudo cat /proc/1990/stack
[<0>] ptrace_stop+0x14a/0x260
[<0>] ptrace_do_notify+0x91/0xb0
[<0>] ptrace_notify+0x4e/0x70
[<0>] do_exit+0x910/0xb70
[<0>] do_group_exit+0x3a/0xa0
[<0>] get_signal+0x124/0x800
[<0>] arch_do_signal_or_restart+0xa9/0x290
[<0>] exit_to_user_mode_prepare+0xe7/0x1a0
[<0>] syscall_exit_to_user_mode+0x18/0x40
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

izh@suse2:~> cat /proc/1891/status
Name:   strace
Umask:  0022
State:  t (tracing stop)
Tgid:   1891
Ngid:   0
Pid:    1891
PPid:   1890
TracerPid:      1990
Uid:    1000    1000    1000    1000
Gid:    100     100     100     100
FDSize: 256
Groups: 100
NStgid: 1891
NSpid:  1891
NSpgid: 1891
NSsid:  1891
VmPeak:    24752 kB
VmSize:    24752 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:      3828 kB
VmRSS:      3828 kB
RssAnon:             520 kB
RssFile:            3308 kB
RssShmem:              0 kB
VmData:      284 kB
VmStk:       132 kB
VmExe:      1108 kB
VmLib:      2828 kB
VmPTE:        80 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
CoreDumping:    0
THP_enabled:    1
Threads:        1
SigQ:   4/15639
SigPnd: 0000000000000000
ShdPnd: 0000000000014100
SigBlk: 0000000000002000
SigIgn: 0000000000300000
SigCgt: 0000000180007007
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Seccomp:        0
Seccomp_filters:        0
Speculation_Store_Bypass:       vulnerable
SpeculationIndirectBranch:      always enabled
Cpus_allowed:   7
Cpus_allowed_list:      0-2
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        1561
nonvoluntary_ctxt_switches:     7

izh@suse2:~> cat /proc/1990/status
Name:   strace
Umask:  0022
State:  t (tracing stop)
Tgid:   1990
Ngid:   0
Pid:    1990
PPid:   1847
TracerPid:      1891
Uid:    1000    1000    1000    1000
Gid:    100     100     100     100
FDSize: 256
Groups: 100
NStgid: 1990
NSpid:  1990
NSpgid: 1990
NSsid:  1847
VmPeak:    24752 kB
VmSize:    24752 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:      3628 kB
VmRSS:      3628 kB
RssAnon:             520 kB
RssFile:            3108 kB
RssShmem:              0 kB
VmData:      284 kB
VmStk:       132 kB
VmExe:      1108 kB
VmLib:      2828 kB
VmPTE:        88 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
CoreDumping:    0
THP_enabled:    1
Threads:        1
SigQ:   4/15639
SigPnd: 0000000000000000
ShdPnd: 0000000000014100
SigBlk: 0000000000002000
SigIgn: 0000000000300000
SigCgt: 0000000180007007
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Seccomp:        0
Seccomp_filters:        0
Speculation_Store_Bypass:       vulnerable
SpeculationIndirectBranch:      always enabled
Cpus_allowed:   7
Cpus_allowed_list:      0-2
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        180
nonvoluntary_ctxt_switches:     848

On 29.03.2021 19:49, Oleg Nesterov wrote:
> On 03/29, Igor Zhbanov wrote:
>>
>> Mutual debugging of 2 processes can stuck in unkillable stopped state
> 
> can't reproduce and can't understand...
> 
>> Hi!
>>
>> When one process, let's say "A", is tracing the another process "B", and the
>> process "B" is trying to attach to the process "A", then both of them are
>> getting stuck in the "t+" state. And they are ignoring all of the signals
>> including the SIGKILL,
> 
> Why do you think so? What is your kernel version?
> 
> "t" means TASK_TRACED, SIGKILL should wake it up and terminate.
> 
>> so it is not possible to terminate them without
>> a reboot.
>>
>> To reproduce:
>> 1) Run two terminals
>> 2) Attach with "strace -p ..." from the first terminal to the shell (bash) of
>>     the second terminal.
>> 3) In the second terminal run "exec strace -p ..." to attach to the PID of the
>>     first strace.
>>
>> Then you'll see that the second strace is hanging without any output. And the
>> first strace will output following and hang too:
>> ptrace(PTRACE_SEIZE, 11795, NULL,
>>         PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT
>>
>> (The 11795 is the PID of the first strace itself.)
>>
>> And in the process list you will see following:
>> ps awux | grep strace
>> user   11776  0.0  0.0  24752  2248 pts/3    t+   13:53   0:00 strace -p 11795
>> user   11795  0.0  0.0  24752  3888 pts/1    t+   13:54   0:00 strace -p 11776
> 
> OK, may be they sleep in PTRACE_EVENT_EXIT? After you tried to send SIGKILL?
> 
> please show us the output from "cat /proc/{11795,11776}/stack". And
> "cat /proc/{11795,11776}/status" just in case.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state
  2021-03-29 17:01   ` Igor Zhbanov
@ 2021-03-29 17:38     ` Oleg Nesterov
  2021-03-29 17:44       ` Igor Zhbanov
  0 siblings, 1 reply; 7+ messages in thread
From: Oleg Nesterov @ 2021-03-29 17:38 UTC (permalink / raw)
  To: Igor Zhbanov; +Cc: linux-trace-devel, linux-kernel

Hi Igor,

So. As expected, they sleep in EVENT_EXIT _after_ you have already sent SIGKILL.

Oh. I can only repeat that PTRACE_EVENT_EXIT must die ;) Or at least we should
finally define its semantics.

Igor, thanks for your report, but (I think) this has nothing to do with mutual
debugging. I'll return to this problem in a couple of days, I'm a bit busy right
now.

Thanks,

Oleg.

On 03/29, Igor Zhbanov wrote:
> Hi Oleg!
> 
> I've tried both 5.3.18 and 5.10.0. The behavior is the same.
> The important thing is to run "exec strace -p ..." on the second terminal
> to create the loop A->B->A.
> 
> So the last line from the first strace we see is:
> ptrace(PTRACE_SEIZE, 1990, NULL, PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT
> 
> I.e. it printed the syscall prior to its execution and hanged after the
> execution.
> 
> izh@suse2:~> ps awux|grep strace
> izh       1891  0.0  0.0  24752  3828 pts/1    ts+  19:52   0:00 strace -p 1990
> izh       1990  0.0  0.0  24752  3628 pts/0    t+   19:53   0:00 strace -p 1891
> 
> izh@suse2:~> kill 1990 1891
> izh@suse2:~> kill -9 1990 1891
> 
> izh@suse2:~> sudo cat /proc/1891/stack
> [sudo] password for root:
> [<0>] ptrace_stop+0x14a/0x260
> [<0>] ptrace_do_notify+0x91/0xb0
> [<0>] ptrace_notify+0x4e/0x70
> [<0>] do_exit+0x910/0xb70
> [<0>] do_group_exit+0x3a/0xa0
> [<0>] get_signal+0x124/0x800
> [<0>] arch_do_signal_or_restart+0xa9/0x290
> [<0>] exit_to_user_mode_prepare+0xe7/0x1a0
> [<0>] syscall_exit_to_user_mode+0x18/0x40
> [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> izh@suse2:~> sudo cat /proc/1990/stack
> [<0>] ptrace_stop+0x14a/0x260
> [<0>] ptrace_do_notify+0x91/0xb0
> [<0>] ptrace_notify+0x4e/0x70
> [<0>] do_exit+0x910/0xb70
> [<0>] do_group_exit+0x3a/0xa0
> [<0>] get_signal+0x124/0x800
> [<0>] arch_do_signal_or_restart+0xa9/0x290
> [<0>] exit_to_user_mode_prepare+0xe7/0x1a0
> [<0>] syscall_exit_to_user_mode+0x18/0x40
> [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> izh@suse2:~> cat /proc/1891/status
> Name:   strace
> Umask:  0022
> State:  t (tracing stop)
> Tgid:   1891
> Ngid:   0
> Pid:    1891
> PPid:   1890
> TracerPid:      1990
> Uid:    1000    1000    1000    1000
> Gid:    100     100     100     100
> FDSize: 256
> Groups: 100
> NStgid: 1891
> NSpid:  1891
> NSpgid: 1891
> NSsid:  1891
> VmPeak:    24752 kB
> VmSize:    24752 kB
> VmLck:         0 kB
> VmPin:         0 kB
> VmHWM:      3828 kB
> VmRSS:      3828 kB
> RssAnon:             520 kB
> RssFile:            3308 kB
> RssShmem:              0 kB
> VmData:      284 kB
> VmStk:       132 kB
> VmExe:      1108 kB
> VmLib:      2828 kB
> VmPTE:        80 kB
> VmSwap:        0 kB
> HugetlbPages:          0 kB
> CoreDumping:    0
> THP_enabled:    1
> Threads:        1
> SigQ:   4/15639
> SigPnd: 0000000000000000
> ShdPnd: 0000000000014100
> SigBlk: 0000000000002000
> SigIgn: 0000000000300000
> SigCgt: 0000000180007007
> CapInh: 0000000000000000
> CapPrm: 0000000000000000
> CapEff: 0000000000000000
> CapBnd: 000001ffffffffff
> CapAmb: 0000000000000000
> NoNewPrivs:     0
> Seccomp:        0
> Seccomp_filters:        0
> Speculation_Store_Bypass:       vulnerable
> SpeculationIndirectBranch:      always enabled
> Cpus_allowed:   7
> Cpus_allowed_list:      0-2
> Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
> Mems_allowed_list:      0
> voluntary_ctxt_switches:        1561
> nonvoluntary_ctxt_switches:     7
> 
> izh@suse2:~> cat /proc/1990/status
> Name:   strace
> Umask:  0022
> State:  t (tracing stop)
> Tgid:   1990
> Ngid:   0
> Pid:    1990
> PPid:   1847
> TracerPid:      1891
> Uid:    1000    1000    1000    1000
> Gid:    100     100     100     100
> FDSize: 256
> Groups: 100
> NStgid: 1990
> NSpid:  1990
> NSpgid: 1990
> NSsid:  1847
> VmPeak:    24752 kB
> VmSize:    24752 kB
> VmLck:         0 kB
> VmPin:         0 kB
> VmHWM:      3628 kB
> VmRSS:      3628 kB
> RssAnon:             520 kB
> RssFile:            3108 kB
> RssShmem:              0 kB
> VmData:      284 kB
> VmStk:       132 kB
> VmExe:      1108 kB
> VmLib:      2828 kB
> VmPTE:        88 kB
> VmSwap:        0 kB
> HugetlbPages:          0 kB
> CoreDumping:    0
> THP_enabled:    1
> Threads:        1
> SigQ:   4/15639
> SigPnd: 0000000000000000
> ShdPnd: 0000000000014100
> SigBlk: 0000000000002000
> SigIgn: 0000000000300000
> SigCgt: 0000000180007007
> CapInh: 0000000000000000
> CapPrm: 0000000000000000
> CapEff: 0000000000000000
> CapBnd: 000001ffffffffff
> CapAmb: 0000000000000000
> NoNewPrivs:     0
> Seccomp:        0
> Seccomp_filters:        0
> Speculation_Store_Bypass:       vulnerable
> SpeculationIndirectBranch:      always enabled
> Cpus_allowed:   7
> Cpus_allowed_list:      0-2
> Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
> Mems_allowed_list:      0
> voluntary_ctxt_switches:        180
> nonvoluntary_ctxt_switches:     848
> 
> On 29.03.2021 19:49, Oleg Nesterov wrote:
> >On 03/29, Igor Zhbanov wrote:
> >>
> >>Mutual debugging of 2 processes can stuck in unkillable stopped state
> >
> >can't reproduce and can't understand...
> >
> >>Hi!
> >>
> >>When one process, let's say "A", is tracing the another process "B", and the
> >>process "B" is trying to attach to the process "A", then both of them are
> >>getting stuck in the "t+" state. And they are ignoring all of the signals
> >>including the SIGKILL,
> >
> >Why do you think so? What is your kernel version?
> >
> >"t" means TASK_TRACED, SIGKILL should wake it up and terminate.
> >
> >>so it is not possible to terminate them without
> >>a reboot.
> >>
> >>To reproduce:
> >>1) Run two terminals
> >>2) Attach with "strace -p ..." from the first terminal to the shell (bash) of
> >>    the second terminal.
> >>3) In the second terminal run "exec strace -p ..." to attach to the PID of the
> >>    first strace.
> >>
> >>Then you'll see that the second strace is hanging without any output. And the
> >>first strace will output following and hang too:
> >>ptrace(PTRACE_SEIZE, 11795, NULL,
> >>        PTRACE_O_TRACESYSGOOD|PTRACE_O_TRACEEXEC|PTRACE_O_TRACEEXIT
> >>
> >>(The 11795 is the PID of the first strace itself.)
> >>
> >>And in the process list you will see following:
> >>ps awux | grep strace
> >>user   11776  0.0  0.0  24752  2248 pts/3    t+   13:53   0:00 strace -p 11795
> >>user   11795  0.0  0.0  24752  3888 pts/1    t+   13:54   0:00 strace -p 11776
> >
> >OK, may be they sleep in PTRACE_EVENT_EXIT? After you tried to send SIGKILL?
> >
> >please show us the output from "cat /proc/{11795,11776}/stack". And
> >"cat /proc/{11795,11776}/status" just in case.
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state
  2021-03-29 17:38     ` Oleg Nesterov
@ 2021-03-29 17:44       ` Igor Zhbanov
  2021-04-12  7:25         ` Igor Zhbanov
  0 siblings, 1 reply; 7+ messages in thread
From: Igor Zhbanov @ 2021-03-29 17:44 UTC (permalink / raw)
  To: Oleg Nesterov; +Cc: linux-trace-devel, linux-kernel

Hi Oleg,

On 29.03.2021 20:38, Oleg Nesterov wrote:
> Hi Igor,
> 
> So. As expected, they sleep in EVENT_EXIT _after_ you have already
> sent SIGKILL.

Here is the processes stack before sending any signals to them:

izh@suse2:~> sudo cat /proc/1751/stack
[<0>] ptrace_stop+0x14e/0x260
[<0>] ptrace_do_notify+0x91/0xb0
[<0>] ptrace_notify+0x4e/0x70
[<0>] syscall_slow_exit_work+0x90/0x150
[<0>] do_syscall_64+0x129/0x1f0
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

izh@suse2:~> sudo cat /proc/1979/stack
[<0>] ptrace_stop+0x14e/0x260
[<0>] get_signal+0x4d5/0x840
[<0>] do_signal+0x30/0x6a0
[<0>] exit_to_usermode_loop+0x8b/0x120
[<0>] do_syscall_64+0x1c3/0x1f0
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

> Igor, thanks for your report, but (I think) this has nothing to do
> with mutual debugging. I'll return to this problem in a couple of
> days, I'm a bit busy right now.

Sorry for inexact description. I said it from the user perspective when
the processes are stopped and can't be killed. :-)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state
  2021-03-29 17:44       ` Igor Zhbanov
@ 2021-04-12  7:25         ` Igor Zhbanov
  2021-04-13 17:17           ` Oleg Nesterov
  0 siblings, 1 reply; 7+ messages in thread
From: Igor Zhbanov @ 2021-04-12  7:25 UTC (permalink / raw)
  To: Oleg Nesterov; +Cc: linux-trace-devel, linux-kernel

Hi Oleg,

So what is the cause of this problem?

Thank you.

On 29.03.2021 20:44, Igor Zhbanov wrote:
> 
> Here is the processes stack before sending any signals to them:
> 
> izh@suse2:~> sudo cat /proc/1751/stack
> [<0>] ptrace_stop+0x14e/0x260
> [<0>] ptrace_do_notify+0x91/0xb0
> [<0>] ptrace_notify+0x4e/0x70
> [<0>] syscall_slow_exit_work+0x90/0x150
> [<0>] do_syscall_64+0x129/0x1f0
> [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> izh@suse2:~> sudo cat /proc/1979/stack
> [<0>] ptrace_stop+0x14e/0x260
> [<0>] get_signal+0x4d5/0x840
> [<0>] do_signal+0x30/0x6a0
> [<0>] exit_to_usermode_loop+0x8b/0x120
> [<0>] do_syscall_64+0x1c3/0x1f0
> [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
>> Igor, thanks for your report, but (I think) this has nothing to do
>> with mutual debugging. I'll return to this problem in a couple of
>> days, I'm a bit busy right now.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Mutual debugging of 2 processes can stuck in unkillable stopped state
  2021-04-12  7:25         ` Igor Zhbanov
@ 2021-04-13 17:17           ` Oleg Nesterov
  0 siblings, 0 replies; 7+ messages in thread
From: Oleg Nesterov @ 2021-04-13 17:17 UTC (permalink / raw)
  To: Igor Zhbanov; +Cc: linux-trace-devel, linux-kernel

Hi Igor,

sorry for delay...

On 04/12, Igor Zhbanov wrote:
>
> Hi Oleg,
>
> So what is the cause of this problem?

The cause is clear. And well known ;) And again, this has almost nothing to do
with the mutual debugging.

The tracee sleeps in ptrace_stop(). You send SIGKILL. This wakes the tracee up,
it dequeues the signal, calls do_exit(), and stops again in PTRACE_EVENT_EXIT.
With SIGKILL in signal->shared_pending. This all looks as if the tracee doesn't
react to SIGKILL.

The only problem is that any change can break something which relies on the
current behaviour :/ I'll write another email on this.

Oleg.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-29 15:28 Mutual debugging of 2 processes can stuck in unkillable stopped state Igor Zhbanov
2021-03-29 16:49 ` Oleg Nesterov
2021-03-29 17:01   ` Igor Zhbanov
2021-03-29 17:38     ` Oleg Nesterov
2021-03-29 17:44       ` Igor Zhbanov
2021-04-12  7:25         ` Igor Zhbanov
2021-04-13 17:17           ` Oleg Nesterov

Linux-Trace-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-trace-devel/0 linux-trace-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-trace-devel linux-trace-devel/ https://lore.kernel.org/linux-trace-devel \
		linux-trace-devel@vger.kernel.org
	public-inbox-index linux-trace-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-trace-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git