From: Kees Cook <kees@kernel.org>
To: Roman Kisel <romank@linux.microsoft.com>
Cc: akpm@linux-foundation.org, apais@linux.microsoft.com,
ardb@kernel.org, bigeasy@linutronix.de, brauner@kernel.org,
ebiederm@xmission.com, jack@suse.cz,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, nagvijay@microsoft.com, oleg@redhat.com,
tandersen@netflix.com, vincent.whitchurch@axis.com,
viro@zeniv.linux.org.uk, apais@microsoft.com,
benhill@microsoft.com, ssengar@microsoft.com,
sunilmut@microsoft.com, vdso@hexbites.dev
Subject: Re: [PATCH v2 1/1] binfmt_elf, coredump: Log the reason of the failed core dumps
Date: Sat, 13 Jul 2024 09:31:43 -0700 [thread overview]
Message-ID: <202407130840.67879B31@keescook> (raw)
In-Reply-To: <20240712215223.605363-2-romank@linux.microsoft.com>
On Fri, Jul 12, 2024 at 02:50:56PM -0700, Roman Kisel wrote:
> Missing, failed, or corrupted core dumps might impede crash
> investigations. To improve reliability of that process and consequently
> the programs themselves, one needs to trace the path from producing
> a core dumpfile to analyzing it. That path starts from the core dump file
> written to the disk by the kernel or to the standard input of a user
> mode helper program to which the kernel streams the coredump contents.
> There are cases where the kernel will interrupt writing the core out or
> produce a truncated/not-well-formed core dump without leaving a note.
>
> Add logging for the core dump collection failure paths to be able to reason
> what has gone wrong when the core dump is malformed or missing.
>
> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> ---
> fs/binfmt_elf.c | 60 ++++++++++++++++-----
> fs/coredump.c | 109 ++++++++++++++++++++++++++++++++-------
> include/linux/coredump.h | 8 ++-
> kernel/signal.c | 22 +++++++-
> 4 files changed, 165 insertions(+), 34 deletions(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index a43897b03ce9..cfe84b9436af 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1994,8 +1994,11 @@ static int elf_core_dump(struct coredump_params *cprm)
> * Collect all the non-memory information about the process for the
> * notes. This also sets up the file header.
> */
> - if (!fill_note_info(&elf, e_phnum, &info, cprm))
> + if (!fill_note_info(&elf, e_phnum, &info, cprm)) {
> + pr_err_ratelimited("Error collecting note info, core dump of %s(PID %d) failed\n",
> + current->comm, current->pid);
A couple things come to mind for me as I scanned through this:
- Do we want to report pid or tgid?
- Do we want to report the global value or the current pid namespace
mapping?
Because I notice that the existing code:
> printk(KERN_WARNING "Pid %d(%s) over core_pipe_limit\n",
> task_tgid_vnr(current), current->comm);
Is reporting tgid for current's pid namespace. We should be consistent.
I think all of this might need cleaning up first before adding new
reports. We should consolidate the reporting into a single function so
this is easier to extend in the future. Right now the proposed patch is
hand-building the report, and putting pid/comm in different places (at
the end, at the beginning, with/without "of", etc), which is really just
boilerplate repetition.
How about creating:
static void coredump_report_failure(const char *msg)
{
char comm[TASK_COMM_LEN];
task_get_comm(current, comm);
pr_warn_ratelimited("coredump: %d(%*pE): %s\n",
task_tgid_vnr(current), strlen(comm), comm, msg);
}
Then in a new first patch, convert all the existing stuff:
printk(KERN_WARNING ...)
pr_info(...)
etc
Since even the existing warnings are inconsistent and don't escape
newlines, etc. :)
Then in patch 2 use this to add the new warnings?
--
Kees Cook
next prev parent reply other threads:[~2024-07-13 16:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 21:50 [PATCH v2 0/1] binfmt_elf, coredump: Log the reason of the failed core dumps Roman Kisel
2024-07-12 21:50 ` [PATCH v2 1/1] " Roman Kisel
2024-07-13 5:29 ` kernel test robot
2024-07-13 16:31 ` Kees Cook [this message]
2024-07-14 14:33 ` Roman Kisel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202407130840.67879B31@keescook \
--to=kees@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apais@linux.microsoft.com \
--cc=apais@microsoft.com \
--cc=ardb@kernel.org \
--cc=benhill@microsoft.com \
--cc=bigeasy@linutronix.de \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nagvijay@microsoft.com \
--cc=oleg@redhat.com \
--cc=romank@linux.microsoft.com \
--cc=ssengar@microsoft.com \
--cc=sunilmut@microsoft.com \
--cc=tandersen@netflix.com \
--cc=vdso@hexbites.dev \
--cc=vincent.whitchurch@axis.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).