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 1947BC52D7F for ; Sat, 10 Aug 2024 12:30:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E50606B008A; Sat, 10 Aug 2024 08:30:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E01D26B0092; Sat, 10 Aug 2024 08:30:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA0E56B0095; Sat, 10 Aug 2024 08:30:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AC3CC6B008A for ; Sat, 10 Aug 2024 08:30:05 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 22A73C18FA for ; Sat, 10 Aug 2024 12:30:05 +0000 (UTC) X-FDA: 82436267970.12.31FBD9D Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf22.hostedemail.com (Postfix) with ESMTP id D1AC3C000D for ; Sat, 10 Aug 2024 12:30:02 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723292992; 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; bh=muaPylOC6diPfv1BO3FxmId7Djf5EXt7nrprqioj8Aw=; b=Ue20wl+UYOYyAXhBqqQNpz0v36eOBjDaNe5yQzKmypRoXsjGna3OHLR1Unpq9vYsjbAAm6 QdLSBdrHWxI2x6sB/IURnC+bQIS1sDH21C3V1f0pDtjUJjICx1d0YxGIt63tsFlcVmAB9x hx60qW616Cv6CkLCA3UZ8Y1QyiojSz0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723292992; a=rsa-sha256; cv=none; b=PSth7euv2O9Poe1fJb+yht3fZPmSlwMHRQKmkTdK9RdBGwnOdzznNv28FO5a2BPmF/f0jJ 3iAfd7qrb9/ZqgvGWpVdhX67DFITO1hN2RY7GVGYCN640KJ/Xu2pkDLk9PuPs0V9j0wRu4 PaRyf0mOQ8EIRMfj6CmQl/ZrPqz0ceo= Received: from in01.mta.xmission.com ([166.70.13.51]:40214) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1sclEN-009WSV-KQ; Sat, 10 Aug 2024 06:30:00 -0600 Received: from ip68-227-165-127.om.om.cox.net ([68.227.165.127]:33268 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1sclEM-00GlCe-80; Sat, 10 Aug 2024 06:29:59 -0600 From: "Eric W. Biederman" To: Brian Mak Cc: Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Oleg Nesterov , Linus Torvalds References: <036CD6AE-C560-4FC7-9B02-ADD08E380DC9@juniper.net> Date: Sat, 10 Aug 2024 07:28:44 -0500 In-Reply-To: <036CD6AE-C560-4FC7-9B02-ADD08E380DC9@juniper.net> (Brian Mak's message of "Tue, 6 Aug 2024 18:16:02 +0000") Message-ID: <87ttfs1s03.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1sclEM-00GlCe-80;;;mid=<87ttfs1s03.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.165.127;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX1/rrQC2FQR/9/Kgl9SrfSvI8sFe1P4ilOg= X-SA-Exim-Connect-IP: 68.227.165.127 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v3] binfmt_elf: Dump smaller VMAs first in ELF cores X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) X-Rspam-User: X-Stat-Signature: jgecacgrdiknrz67ykqttt5nyh17wyq9 X-Rspamd-Queue-Id: D1AC3C000D X-Rspamd-Server: rspam11 X-HE-Tag: 1723293002-37865 X-HE-Meta: U2FsdGVkX19NJNCapfWcPS5Qn1sdwRVUkH2qgtKcLJ4cnccssx6DJd4ArJVfcrBw7kNFd3Ep/4oaptNgnhDkEPOl22d96KnbvI+fePf8NkKGGH4M1eOXAqRs/zeq60pIityc6HV8VAYNWZxKT4RQRHDSp+DDR8T+7cH9kis2qN3hYavc32pkHtVeJ0NILliuAG/XtKDYWR95MfYlqYmMWA8cEDrHkcDpHTNu0KUAIpNzoV9Qh7zJ4avBix9lXNoh5+X3fHg/g47q7ufSmqh8WWk0B8BckiXvU/z2m/iIjUtXDGIoC6+Vznlk//ZO/Oq0k6sbRorfHgUxT8mkYGVRgUCld5WxgVk0TEP8psUgqi/uH7q+xOuT871WfJKqB/ifQRvid7eJC73QSunFHqv4TBA20ShReyfqfzlNbZ9O51ozMR0VUWXGthnCCRcAURZwwiKriq3+NiGx1fHuH4SUtCSCfxLHdRGzAQPXpUrcPfIiXq23Igkz+VGOZdTihetiNutLOFKSD4X24qoLbZdcABRdhHHRQRW+UuRGNjj+Y5mFFfxY5fBuxes+2dEYux03cgBnSDAugbS2jFCWQr4emRPeYf303ujHqcGgKPTvzmRKLO1ldkNoR+yvyMdvc/P4gpknD1JTF7Wvk7I+duDGc9xp0GsvvXy9QoiELrBPk8yu8Zqfb5Ory2cij+RWmUQnzviH8mqHyf2t5CotTrbbNtMR/vva0OBwMHvxOEKeOnqB4Ih0b+fn2P752oZmappRpdLPRVGP+Nnvk8PQ/DEf8KNad52YfsTDjLqDBpokl7WN7IULjAc5pmsQEc5lsO2x1mcG74Bi0Pj2hwKvHQ9XNLyRiTggGUuonXnQM0U+OXsPLgRnWzobPSuv/w62nUw/EKsazjv86xtmek/U+31LgYGjSpwVTJWnOpCLwRGrl91rAFPrefMDTYSwLX7te6OGTXzRdmeeOT0QIGfUSfm A8hN+Sg2 8sKvViPM0cZbwZ+LYQIOANYTjD9kfCJUUNmZkiH0X6WSlGo6klcpfNysEq+DQln4j4ffaWE9vKtiD2IArkatz6d9YQfHKeaUqg3rgF/LB2Jk/+OmcTHCuVppQWF4apg0qA/XLowbumBJWEac6dIgd2AbiINKkwbVklqRyV6cwqua+FnLX+xq6C3FpHRtzAIAAGJrFytL495ofhWguRfCq2uwI76yj7vs+P4JjEMxJJ5SdZGBpEJSaeJj1PPwOmiZAh1Lh3Nnh1sfH7010DK4OHD2vC8Z3G6/dHr1q 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: Brian Mak writes: > Large cores may be truncated in some scenarios, such as with daemons > with stop timeouts that are not large enough or lack of disk space. This > impacts debuggability with large core dumps since critical information > necessary to form a usable backtrace, such as stacks and shared library > information, are omitted. > > We attempted to figure out which VMAs are needed to create a useful > backtrace, and it turned out to be a non-trivial problem. Instead, we > try simply sorting the VMAs by size, which has the intended effect. > > By sorting VMAs by dump size and dumping in that order, we have a > simple, yet effective heuristic. To make finding the history easier I would include: v1: https://lkml.kernel.org/r/CB8195AE-518D-44C9-9841-B2694A5C4002@juniper.net v2: https://lkml.kernel.org/r/C21B229F-D1E6-4E44-B506-A5ED4019A9DE@juniper.net Acked-by: "Eric W. Biederman" As Kees has already picked this up this is quite possibly silly. But *shrug* that was when I was out. > Signed-off-by: Brian Mak > --- > > Hi all, > > Still need to run rr tests on this, per Kees Cook's suggestion, will > update back once done. GDB and readelf show that this patch works > without issue though. > > Thanks, > Brian Mak > > v3: Edited commit message to better convey alternative solution as > non-trivial > > Moved sorting logic to fs/coredump.c to make it in place > > Above edits suggested by Eric Biederman > > v2: Edited commit message to include more reasoning for sorting VMAs > > Removed conditional VMA sorting with debugfs knob > > Above edits suggested by Eric Biederman > > fs/coredump.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/fs/coredump.c b/fs/coredump.c > index 7f12ff6ad1d3..33c5ac53ab31 100644 > --- a/fs/coredump.c > +++ b/fs/coredump.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1191,6 +1192,18 @@ static void free_vma_snapshot(struct coredump_params *cprm) > } > } > > +static int cmp_vma_size(const void *vma_meta_lhs_ptr, const void *vma_meta_rhs_ptr) > +{ > + const struct core_vma_metadata *vma_meta_lhs = vma_meta_lhs_ptr; > + const struct core_vma_metadata *vma_meta_rhs = vma_meta_rhs_ptr; > + > + if (vma_meta_lhs->dump_size < vma_meta_rhs->dump_size) > + return -1; > + if (vma_meta_lhs->dump_size > vma_meta_rhs->dump_size) > + return 1; > + return 0; > +} > + > /* > * Under the mmap_lock, take a snapshot of relevant information about the task's > * VMAs. > @@ -1253,5 +1266,8 @@ static bool dump_vma_snapshot(struct coredump_params *cprm) > cprm->vma_data_size += m->dump_size; > } > > + sort(cprm->vma_meta, cprm->vma_count, sizeof(*cprm->vma_meta), > + cmp_vma_size, NULL); > + > return true; > } > > base-commit: eb5e56d1491297e0881c95824e2050b7c205f0d4