Messages in this thread | | | Date | Tue, 28 Jun 2022 19:15:41 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH v4 12/12] sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state |
| |
On Tue, 21 Jun 2022 17:15:47 +0200 Alexander Gordeev <agordeev@linux.ibm.com> wrote:
> So I assume (checked actually) the return 0 below from kernel/sched/core.c: > wait_task_inactive() is where it bails out: > > 3303 while (task_running(rq, p)) { > 3304 if (match_state && unlikely(READ_ONCE(p->__state) != match_state)) > 3305 return 0; > 3306 cpu_relax(); > 3307 } > > Yet, the child task is always found in __TASK_TRACED state (as seen > in crash dumps): > > > 101447 11342 13 ce3a8100 RU 0.0 10040 4412 strace > 101450 101447 0 bb04b200 TR 0.0 2272 1136 kill_child > 108261 101447 2 d0b10100 TR 0.0 2272 532 kill_child > crash> task bb04b200 __state > PID: 101450 TASK: bb04b200 CPU: 0 COMMAND: "kill_child" > __state = 8, > > crash> task d0b10100 __state > PID: 108261 TASK: d0b10100 CPU: 2 COMMAND: "kill_child" > __state = 8,
If you are using crash, can you enable all trace events?
Then you should be able to extract the ftrace ring buffer from crash using the trace.so extend (https://github.com/fujitsu/crash-trace)
I guess it should still work with s390.
Then you can see the events that lead up to the crash.
-- Steve
| |