summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRoman Gushchin <guro@fb.com>2017-11-17 15:26:45 -0800
committerSeung-Woo Kim <sw0312.kim@samsung.com>2020-06-03 02:36:17 +0000
commitcdb2b5ce28c78720ac2afe033f1d264b8b8c13f5 (patch)
tree96c2f59379b15d903d4608dd75b0cad04bf01bf2
parent4bf16d3d958547e6cf36d8740cd42ad1eb73f5c7 (diff)
downloademulator-kernel-cdb2b5ce28c78720ac2afe033f1d264b8b8c13f5.tar.gz
emulator-kernel-cdb2b5ce28c78720ac2afe033f1d264b8b8c13f5.tar.bz2
emulator-kernel-cdb2b5ce28c78720ac2afe033f1d264b8b8c13f5.zip
Right now there is no convenient way to check if a process is being coredumped at the moment. It might be necessary to recognize such state to prevent killing the process and getting a broken coredump. Writing a large core might take significant time, and the process is unresponsive during it, so it might be killed by timeout, if another process is monitoring and killing/restarting hanging tasks. We're getting a significant number of corrupted coredump files on machines in our fleet, just because processes are being killed by timeout in the middle of the core writing process. We do have a process health check, and some agent is responsible for restarting processes which are not responding for health check requests. Writing a large coredump to the disk can easily exceed the reasonable timeout (especially on an overloaded machine). This flag will allow the agent to distinguish processes which are being coredumped, extend the timeout for them, and let them produce a full coredump file. To provide an ability to detect if a process is in the state of being coredumped, we can expose a boolean CoreDumping flag in /proc/pid/status. Example: $ cat core.sh #!/bin/sh echo "|/usr/bin/sleep 10" > /proc/sys/kernel/core_pattern sleep 1000 & PID=$! cat /proc/$PID/status | grep CoreDumping kill -ABRT $PID sleep 1 cat /proc/$PID/status | grep CoreDumping $ ./core.sh CoreDumping: 0 CoreDumping: 1 [guro@fb.com: document CoreDumping flag in /proc/<pid>/status] Link: http://lkml.kernel.org/r/20170928135357.GA8470@castle.DHCP.thefacebook.com Link: http://lkml.kernel.org/r/20170920230634.31572-1-guro@fb.com Signed-off-by: Roman Gushchin <guro@fb.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Ingo Molnar <mingo@kernel.org> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [k.lewandowsk: backport mainline commit c643401218 for userspace process managers (eg. resourced) to be able to avoid killing dead processes, breaking crash reports] Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com> Change-Id: I5ba2fcbf4f388be752db542e80ebca367dba618c
-rw-r--r--Documentation/filesystems/proc.txt3
-rw-r--r--fs/proc/array.c6
2 files changed, 9 insertions, 0 deletions
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 6716413c17ba..4d34a9495584 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -176,6 +176,7 @@ read the file /proc/PID/status:
VmPTE: 20 kb
VmSwap: 0 kB
HugetlbPages: 0 kB
+ CoreDumping: 0
Threads: 1
SigQ: 0/28578
SigPnd: 0000000000000000
@@ -240,6 +241,8 @@ Table 1-2: Contents of the status files (as of 4.1)
VmPMD size of second level page tables
VmSwap size of swap usage (the number of referred swapents)
HugetlbPages size of hugetlb memory portions
+ CoreDumping process's memory is currently being dumped
+ (killing the process may lead to a corrupted core)
Threads number of threads
SigQ number of signals queued/max. number for queue
SigPnd bitmap of pending signals for the thread
diff --git a/fs/proc/array.c b/fs/proc/array.c
index b6c00ce0e29e..0485d897598f 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -351,6 +351,11 @@ static void task_cpus_allowed(struct seq_file *m, struct task_struct *task)
cpumask_pr_args(&task->cpus_allowed));
}
+static inline void task_core_dumping(struct seq_file *m, struct mm_struct *mm)
+{
+ seq_printf(m, "CoreDumping:\t%d\n", !!mm->core_state);
+}
+
int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task)
{
@@ -361,6 +366,7 @@ int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
if (mm) {
task_mem(m, mm);
+ task_core_dumping(m, mm);
mmput(mm);
}
task_sig(m, task);