From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 912FDC3DA45 for ; Sat, 13 Jul 2024 16:31:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B0C86B0089; Sat, 13 Jul 2024 12:31:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0618E6B008A; Sat, 13 Jul 2024 12:31:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E69CA6B008C; Sat, 13 Jul 2024 12:31:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C86B36B0089 for ; Sat, 13 Jul 2024 12:31:47 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4728F40D52 for ; Sat, 13 Jul 2024 16:31:47 +0000 (UTC) X-FDA: 82335270654.19.13F0CED Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id 73311C0023 for ; Sat, 13 Jul 2024 16:31:45 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ph7Pb9kr; spf=pass (imf22.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720888269; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4cc7kfc5FSu5/5cvN43338/2j4fxThrzL6zlCJWBhmE=; b=6PlQL42lOJsWuVgUyjUpbpJqMlRJX/EEZupefegsymIUk0Ri+vTmeIkZu/VQdMxldNi+ln eRuyXSlR/frvH2AoUummOkkO0mhMiqiSTeqRseUSMRZPlMD77f2arAZfQVlPGAfEw/R+pi R6RjSdbahEBpuf8Tw3a8yDnbND0Py8I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720888269; a=rsa-sha256; cv=none; b=KFnyk7x1W/R+4hqM385YjbpUDIT4uix2brnZ7kAn2PcM9zEr7QdjDH3Ue45/5O5yncvewA G7OUYo9mzpr2RIOjRJ3TJ1JCDiQtP7uyUhGKr3TfUYB8FpcBU5cnV+2Qjyg51oCp9tI3J4 hoffzHSbcCTI/1gW4N0xeQgeIiHhrDA= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ph7Pb9kr; spf=pass (imf22.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 26F0C6059E; Sat, 13 Jul 2024 16:31:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6931C32781; Sat, 13 Jul 2024 16:31:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720888303; bh=K1p6MLOeYFJkkB/mYrJY/2L1UK9sdhYQYCjNk1tJ2UM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ph7Pb9krgqwoAsG5PA6szWbkaFzoGg+oL3GgEJUD+4AAJwVaFNSGH/hHfY2x3k7qI lhAAjPPlNt8TjN0oqp2O42H4KA+09ZlUWBg2ZrdP2PHxdJVWP1k5nls8BzIOREJ7Qt LLHWsRez3JYvbOJuxbTef2EPza8ByFzQwa00eJvud1QyigVASg8NvD2XypS5+fXgp2 6wnkDJsOD/I4LOOmYuWUi8IyxXPqdUfCWV14x0y3kZtNyIv9Gvz0T2WLhfq8Y7KtZ+ Bb+d458tlV+ugAOxPNDswoX/5U7QaG3LR2ubnweduOWfx3Fkjgkc+IGPtB3RnKkLbZ /7K+x6LnIsYCg== Date: Sat, 13 Jul 2024 09:31:43 -0700 From: Kees Cook To: Roman Kisel 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 Message-ID: <202407130840.67879B31@keescook> References: <20240712215223.605363-1-romank@linux.microsoft.com> <20240712215223.605363-2-romank@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240712215223.605363-2-romank@linux.microsoft.com> X-Stat-Signature: 6yuw4bxpghsmh3dxu787g5t1qk7sxyao X-Rspamd-Queue-Id: 73311C0023 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1720888305-338621 X-HE-Meta: U2FsdGVkX1+SaY5/CP0vsP7iJoNQ6U4OF8wlikms6X5aYo2Kui5rg1pIeg5jEInDdUSHb/a1IsN/VAMQbua/bycNu43eE8fi876fV1dXDH1dDYUS5cO6ATvhdN4qxk0dhQik2ZKL59v2dmWnIIEzb27lEog+ypZawkrp0kbYB6gPw89K8EnUcm0R9JtLdXfGlO4FUx8FTT70bbM5KNTZdCG0sqmuB2DBhZozuaJ33JLP+C27GWp4kNZA6vyCEGQqBTrIs6q2oOTapKLmA0NJgA6UCM/Yg2jezNWFWRiyfAqsP/sNCXoOsxkQJUgC3AbUQR37Pm296pCn+Qi/2YgRXkXgJqNCLV8hRCWXEba357nWCgN7BYnKjMeqglX7W68Jvc3SsCx0TjrA4i82B6ToznBUPDg/9GM39uBvJB+ZT5Ih4P4sPgfdjYoBTzprrVgx1IbWilCzBMn3Iy4U1QxAhIovT3bD5iFD6QglkkNR5KWoIo2taXHZP4Yab6ZnCdA/d4NeGFJnkxmtAVxh4ZJR7dW/gThLGVe3zNxRUu6cO6YGLBqSMQk3thckGbPzESivNFh43hxMPa894WgW/omQ8f4b237IGxBhihvQKbvSAUo5WNO4Vhl+AI2dbZcnI4wcMMkO7F2Vp9eNlDsi8Z5cbXuF36oVS9J9BFAsPflg3cpl5YJfBe1vJjsDwCrflf4R/Q9fFN4Cm/96dyuxHZhJToht9IkOa/sV04edV7GJvyb0FDG3v86814mnd8qtFOX8R4x3tBrSs4z0+nZjO3MD5BEyGXN3RFmpXlKGC5GnKyaSp5N9OH8aLvDrq0MuhiW+BxwUZYIlYY8qZFijsn7Q9eLRSpsFntaxaBHdgmM7eLlDe3shRGXZddS7kJ8NQkEAOjeQpmVlU9uXqqXPGzKcLFNjlLLr6SlgIGgQmykCLN+V6tCVaoxSS99trknRLMRGY+w4DPnX/GALBE0BJXJ M8OIA9o2 v3YaQYXtvcVLCtk1Io8dUvpkDDfBs0FDOgX9ExmsLEg+vNsIS9ZDB4Sjnr1GDqXLxs7RZQ1iw1McF82JGedDoZPnDSUqbqf/r9R3+tEpwh7SKa3rhgh6UhK6EJuvD4SQXSKx3KbNgE5Yv/TnSTXVhIRLPiwO7P21hHuuSEcxgG2DNitW6hCQLGzpliL9eVtBbqc/cZRIUpbAKs2klnST8p4H/g5lKZIdS7OPXhMhy3VArfjx7QlAoQzbaTl7sHgLEzdl2AuoHwE1fLrQY4gTUwENWQJYgQhOp9SzgjfRbiJ1FwwE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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 > --- > 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