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 CAD8BC3DA4A for ; Mon, 5 Aug 2024 19:10:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38C756B0085; Mon, 5 Aug 2024 15:10:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33B9F6B0088; Mon, 5 Aug 2024 15:10:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B5096B0089; Mon, 5 Aug 2024 15:10:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id F18756B0085 for ; Mon, 5 Aug 2024 15:10:33 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 97D111A1BE9 for ; Mon, 5 Aug 2024 19:10:33 +0000 (UTC) X-FDA: 82419133146.05.FFEB766 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf08.hostedemail.com (Postfix) with ESMTP id 014AD160015 for ; Mon, 5 Aug 2024 19:10:30 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="G3u/VSrF"; spf=pass (imf08.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722885024; 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=UA5U+6t/BL3dNn6z4KME0ljFM05r+burKxZg1qrP5MU=; b=yQDtujmfaBLdOM6DBnGBXAHjTI6zXb84a1lGQMzVaKJCC9CACvr/2QzPz96ZcHv2DbheUW B7DAU0R+dOkPff7Ij6Krq8e43z2Vx62RHaun6gNtRUE40TGZrsD3xTgu4EP28iLOUBZBvN xkjWoGMuU8Z0MjRWkqIirckpxOi4Hcc= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="G3u/VSrF"; spf=pass (imf08.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722885024; a=rsa-sha256; cv=none; b=xhv6rDtK/2YQJpL2wtm4hyFYttX4aILy95KTPDaBfBfVq/O5S+lIjgu1lP2Ei+qJ8721Gl 7tMEuFgy6jE78gJpHbyjPhlPTYNc2cd2Enh2dPIJkcsHMUdpf9P24ccAQKGCZyuYdFyZtC Tg4LiqI3ILRYJERN8QKvGZEovNRGTTs= Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-5af326eddb2so9461975a12.1 for ; Mon, 05 Aug 2024 12:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1722885029; x=1723489829; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UA5U+6t/BL3dNn6z4KME0ljFM05r+burKxZg1qrP5MU=; b=G3u/VSrFVJN0S3tc5Au329Q7qMnFIJiUymREzC/LM+1tQ8qHJZr4T52eMsbM2V37Wn aagRQ8dqaLe2bA/+xsfGKhy7Rhcg5I8o3CkNpX+566xG5eAR9Us9W9tCvld0B059+G8Q nGxSCyC4w4lUCENX6WGJ3VG8DXP/dSBi1Dg/A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722885029; x=1723489829; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UA5U+6t/BL3dNn6z4KME0ljFM05r+burKxZg1qrP5MU=; b=PIftX+N3jm9wh81fW8y5tHBGxNnt9M1hFQprowHVEuZ/DhmDk3NasUQIMtcpAgQRIF 0i5LgP4rJLN0F86bar7LndpWE4VJFqfE1wA3KHFpP2gRpr47jRMmyc3jsl1V/f6gZlnN cjoaA3qU1i8HdwKA0aoYdbHZJ/A4dJdLL/+JjAfr3zfFnTfmv12Kz36zb25ntQsUn1rP IA0LQPKgSLgQxJpO2XtdknbRIDYxGuamPz7PNdwv7N/HGSDj6Qs/WeVOFYpM9MTog7+a COpDXoiMck/k1gh+Z+eBDoo8LAVWMnoxE5Gam2ifuUTJt1DAWo3sgpG8rQx+IYsPqNgY 2LIg== X-Forwarded-Encrypted: i=1; AJvYcCV0BbD5zxc8e5azhzXvVsG3Wl7Z20qWyTQZpYoUnGGUjaEfVQRF0cNn5pL0ZMpNfHIEE9pwYVj4D/aMIDr/JCpLo3M= X-Gm-Message-State: AOJu0Yxof+wkwR+mT1IifYbxJv3HoMkbUN9/r5IoGBZ1cKhg7+6sqWAu OWVWCT3OBPbYfs5FbIM1dY9lrDZEYe3B2OvxNdX+r/m5Yc89fP0S42tf9022VU2S21OrXxeu9Ld OZo4sbg== X-Google-Smtp-Source: AGHT+IH8usVlVeL0cV/0ylkzHosJJzRIMCqRRQSpRTzVxaL2/oTX/MWsWR6BlpUBoE3LAIZFo7DeFw== X-Received: by 2002:a17:907:9406:b0:a7a:952b:95cf with SMTP id a640c23a62f3a-a7dbe66cc25mr1109818966b.32.1722885028977; Mon, 05 Aug 2024 12:10:28 -0700 (PDT) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9ec886esm480669666b.203.2024.08.05.12.10.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Aug 2024 12:10:28 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5a79df5af51so10171040a12.0 for ; Mon, 05 Aug 2024 12:10:28 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUT/9qZgWmnd/5FWSfHcp4pWgFrZD/86NuVjSF/Nun90aHPjTN5m9mUTYPmSBq6l7+HH6FI26QqOq7Ee/bN+WzOqzA= X-Received: by 2002:a17:906:cae5:b0:a77:ce4c:8c9c with SMTP id a640c23a62f3a-a7dbcbd4ecamr1191867766b.8.1722885027737; Mon, 05 Aug 2024 12:10:27 -0700 (PDT) MIME-Version: 1.0 References: <20240804152327.GA27866@redhat.com> In-Reply-To: From: Linus Torvalds Date: Mon, 5 Aug 2024 12:10:10 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] piped/ptraced coredump (was: Dump smaller VMAs first in ELF cores) To: Brian Mak Cc: Oleg Nesterov , "Eric W. Biederman" , Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Stat-Signature: b7h4wgnxia9nmnk14p1u9htxntc3w6yw X-Rspamd-Queue-Id: 014AD160015 X-Rspamd-Server: rspam11 X-HE-Tag: 1722885030-243118 X-HE-Meta: U2FsdGVkX18rlEWM2aDkCM6qVhwi38BTCX8zxz2APOnNmxp++Dg9BeN8JkWc9i0r6kR6qczx5jN0H/LcHks8O13MZpqJBU9fcBEao2t9wYSOChDbWTsQPm3GqjJD/TAzjKpojrj6COEPB0nrmCDNIKF8ZmicWuI+uMijU8PQ+0N4p+ewevKrfZezB4xApZXnyv09CF9omUveUhJathPeqiRK2dLhIgpvEY9ARGL3Z5EoOOo3+3XHyMplVCu9kR0QLQGCb7VVZjmcgceSa9OnG4HcSK+CWCKcPiMHJ4nAwNcjLWabQcZYOsMUCeZn490HUU1ELBWvZXFDQ4jZfCit2mjvHZED9HueFW9CzHdBV8tDxGpsQIq9PdEcLLEnMF5SHKyWIP4jIsualfi8HW2dTDfV5njWA3+SAiwtOyVfgHvktJpaZwzXbUdoGuwPpWtXk4dyEaX83RAAw+nyJ8CwgT8kMVLINSWR8d/nq/63VjQa3nUeG9hpHCiyM1LFQsOcXycbEeatGCAFapshif1ccEcpGGHbNAzq1+Z3GqO8gb3/dGiONMwWjxpC4wd6XNXMSX1SOGSD0a2H/JA3D+EE6GSVfB5YPDmLiNnOga9w1TTehJ8FLcXQVIyE/mcEsISppPIn3Qa9oe/F2HSiKlB1HCuZmlLJudvJgjnYR/AvDAHBU2b+FCL8pk6zc3NZygaXtqyQadCjwGOcs454adsFtL5R7bnfcYzb/2JlG7qQ8FAsS7ZBaZHYxeOW2JDvmetsymnIvZeqSJfvVbhIRL9gLE0MCHksYMeEpIbPpfYS8tHiT0l/vPPHaUwh9ze+ZqUyffp0Jyykka6Y243kkyR6SgaOaQ/B3C6swxA35VwShyUBagMDu55DU4uGcXD8pY4PBrdSnq3aCGSyk+97QiUTQVDjiVwzfMK5N9ciyvYFhJIWuEiWYJD8GRkDeDwqMbzYOU6WYl8bXr1VOfgFbbL c0vEsupI k4jxLi3axAOWUHjfKtb8xG6xYbhDTfNOOyp8EgRTROfyTSPtOtsfxSiR0GsTsWCvAZWRXzqNP8aRgC1mBfOlneXWhbsStvhkISr2uBuSHfcu4FuDFRhDl9LSO3OTURQySEzt8CRzStBIawSTEYsdeUvwhbXlgTwauzbGnFkIZN9slMNA0Hs56fB/9WISuxjidl4oANL30QbaZpxOjVkv6Ga3YiwgXnM0bQr2/sXq8CgWyIFyag6mQiM/bNnic/lKXwpTN2sXdznCZVPndnY9Lxw8Gu3Juleg1IukDN4Gc+a3rH9M7XOnPkmLss7WBJ27NaJ7AxkVJM8KgzXpz/mz4X/OzfsHZvHSHtH5tervENr9K5mMIe7PP1O16wjXMRGZfNBsMCA0EjpkWN8VdKbYxcifTtoJ1N/CNc1lvc9wZz27GvFZewtvv3xzXOrh4FQJ4/ahcpt3POx1GaT8dsE7OHqFd558MZ68JxCcens8lP9+PrCxR7XasE8dzYhoYde0nWfRnwA7NzUuUGsCLsL1yi0RxPTRp4Fjj1Pgqow6psjQ/7lQ35ugvUleYXN+Me2gWSUF5hq/bYir1KsY= 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 Mon, 5 Aug 2024 at 10:56, Brian Mak wrote: > > Do you mean support truncating VMAs in addition to sorting or as a > replacement to sorting? If you mean in addition, then I agree, there may > be some VMAs that are known to not contain information critical to > debugging, but may aid, and therefore have less priority. I'd consider it a completely separate issue, so it would be independent of the sorting. We have "ulimit -c" to limit core sizes, but I think it might be interesting to have a separate "limit individual mapping sizes" logic. We already have that as a concept: vma_dump_size() could easily limit the vma dump size, but currently only picks "all or nothing", except for executable mappings that contain actual ELF headers (then it will dump the first page only). And honestly, *particularly* if you have a limit on the core size, I suspect you'd be better off dumping some of all vma's rather than dumping all of some vma's. Now, your sorting approach obviously means that large vma's no longer stop smaller ones from dumping, so it does take care of that part of it. But I do wonder if we should just in general not dump crazy big vmas if the dump size has been limited. Linus