All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.