On 12/17, Oleg Nesterov wrote:
On 11/06, Nam Cao wrote:
@@ -534,6 +517,23 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, ppid = task_tgid_nr_ns(task->real_parent, ns); pgid = task_pgrp_nr_ns(task, ns);
/** esp and eip are intentionally zeroed out. There is no* non-racy way to read them without freezing the task.* Programs that need reliable values can use ptrace(2).OK,
but then:
* The only exception is if the task is core dumping because* a program is not able to use ptrace(2) in that case. It is* safe because the task has stopped executing permanently.*/if (permitted && task->signal->core_state) {if (try_get_task_stack(task)) {eip = KSTK_EIP(task);esp = KSTK_ESP(task);put_task_stack(task);How can the task->signal->core_state check help ?
Suppose we have a task T1 with T1-pid == 100 and you read /proc/100/stat. It is possible that the T1's sub-thread T2 starts the coredumping and sets signal->core_state != NULL.
But read(/proc/100/stat) can run before T1 gets SIGKILL from T2 and enters the kernel mode?
Can't the trivial patch below fix the problem?
Oleg.
--- xfs/proc/array.c +++ x/fs/proc/array.c @@ -500,7 +500,7 @@ * a program is not able to use ptrace(2) in that case. It is * safe because the task has stopped executing permanently. */ - if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE))) { + if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE|PF_POSTCOREDUMP))) { if (try_get_task_stack(task)) { eip = KSTK_EIP(task); esp = KSTK_ESP(task);