[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240617234133.1167523-1-romank@linux.microsoft.com>
Date: Mon, 17 Jun 2024 16:41:29 -0700
From: Roman Kisel <romank@...ux.microsoft.com>
To: akpm@...ux-foundation.org,
apais@...ux.microsoft.com,
ardb@...nel.org,
bigeasy@...utronix.de,
brauner@...nel.org,
ebiederm@...ssion.com,
jack@...e.cz,
keescook@...omium.org,
linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
nagvijay@...rosoft.com,
oleg@...hat.com,
tandersen@...flix.com,
vincent.whitchurch@...s.com,
viro@...iv.linux.org.uk
Cc: apais@...rosoft.com,
ssengar@...rosoft.com,
sunilmut@...rosoft.com,
vdso@...bites.dev
Subject: [PATCH 0/1] binfmt_elf, coredump: Log the reason of the failed core dumps
A powerful way to diagnose crashes is to analyze the core dump produced upon
the failure. Missing or malformed core dump files hinder these investigations.
I'd like to propose changes that add logging as to why the kernel would not
finish writing out the core dump file.
These changes don't attempt to turn the code into a state machine with the numerical
error codes. This is just the next step to not logging which is logging :).
Please let me know what is good, bad and ugly with these changes!
Signed-off-by: Roman Kisel <romank@...ux.microsoft.com>
Roman Kisel (1):
binfmt_elf, coredump: Log the reason of the failed core dumps
fs/binfmt_elf.c | 48 +++++++++++++++++++++-------
fs/coredump.c | 69 +++++++++++++++++++++++++++++++---------
include/linux/coredump.h | 4 +--
kernel/signal.c | 5 ++-
4 files changed, 96 insertions(+), 30 deletions(-)
base-commit: 831bcbcead6668ebf20b64fdb27518f1362ace3a
--
2.45.2
Powered by blists - more mailing lists