Make the print-fatal-signals message more useful by printing the comm
and the exe name for the process which received the fatal signal:
Before:
potentially unexpected fatal signal 4
potentially unexpected fatal signal 11
After:
buggy-program: pool: potentially unexpected fatal signal 4
some-daemon: gdbus: potentially unexpected fatal signal 11
comm used to be present but was removed in commit 681a90ffe829b8ee25d
("arc, print-fatal-signals: reduce duplicated information") because it's
also included as part of the later stack trace. Having the comm as part
of the main "unexpected fatal..." print is rather useful though when
analysing logs, and the exe name is also valuable as shown in the
examples above where the comm ends up having some generic name like
"pool".
Signed-off-by: Vincent Whitchurch <[email protected]>
---
kernel/signal.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 2547fa73bde51..fe1ce5f003784 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -22,8 +22,10 @@
#include <linux/sched/cputime.h>
#include <linux/file.h>
#include <linux/fs.h>
+#include <linux/mm.h>
#include <linux/proc_fs.h>
#include <linux/tty.h>
+#include <linux/file.h>
#include <linux/binfmts.h>
#include <linux/coredump.h>
#include <linux/security.h>
@@ -1255,7 +1257,17 @@ int send_signal_locked(int sig, struct kernel_siginfo *info,
static void print_fatal_signal(int signr)
{
struct pt_regs *regs = task_pt_regs(current);
- pr_info("potentially unexpected fatal signal %d.\n", signr);
+ struct file *exe_file;
+
+ exe_file = get_task_exe_file(current);
+ if (exe_file) {
+ pr_info("%pD: %s: potentially unexpected fatal signal %d.\n",
+ exe_file, current->comm, signr);
+ fput(exe_file);
+ } else {
+ pr_info("%s: potentially unexpected fatal signal %d.\n",
+ current->comm, signr);
+ }
#if defined(__i386__) && !defined(__arch_um__)
pr_info("code at %08lx: ", regs->ip);
---
base-commit: 6995e2de6891c724bfeb2db33d7b87775f913ad1
change-id: 20230630-fatal-comm-163cc2402cfd
Best regards,
--
Vincent Whitchurch <[email protected]>