summaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2017-09-17 08:16:36 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2017-09-17 08:16:36 -0700
commit0666f560b71b899cd11a7caf39fd45129e9030fd (patch)
tree24c537b475c6237e99af316d34605a9ad52f3a12 /fs
parente77d3b0c4a6a973872652601aae35d4ab1785fb4 (diff)
parentfd7d56270b526ca3ed0c224362e3c64a0f86687a (diff)
downloadlinux-0-day-0666f560b71b899cd11a7caf39fd45129e9030fd.tar.gz
linux-0-day-0666f560b71b899cd11a7caf39fd45129e9030fd.tar.xz
Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull misc fixes from Thomas Gleixner: - A fix for a user space regression in /proc/$PID/stat - A couple of objtool fixes: ~ Plug a memory leak ~ Avoid accessing empty sections which upsets certain binutil versions ~ Prevent corrupting the obj file when section sizes did not change * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: fs/proc: Report eip/esp in /prod/PID/stat for coredumping objtool: Fix object file corruption objtool: Do not retrieve data from empty sections objtool: Fix memory leak in elf_create_rela_section()
Diffstat (limited to 'fs')
-rw-r--r--fs/proc/array.c9
1 files changed, 9 insertions, 0 deletions
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 88c355574aa0a..525157ca25cbe 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -62,6 +62,7 @@
#include <linux/mman.h>
#include <linux/sched/mm.h>
#include <linux/sched/numa_balancing.h>
+#include <linux/sched/task_stack.h>
#include <linux/sched/task.h>
#include <linux/sched/cputime.h>
#include <linux/proc_fs.h>
@@ -421,7 +422,15 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *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).
+ *
+ * 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->flags & PF_DUMPCORE)) {
+ eip = KSTK_EIP(task);
+ esp = KSTK_ESP(task);
+ }
}
get_task_comm(tcomm, task);