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 D2BD5C4345F for ; Fri, 3 May 2024 23:43:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F27B6B0092; Fri, 3 May 2024 19:43:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A3406B0093; Fri, 3 May 2024 19:43:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58F596B0095; Fri, 3 May 2024 19:43:42 -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 3CE036B0092 for ; Fri, 3 May 2024 19:43:42 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E3747801E8 for ; Fri, 3 May 2024 23:43:41 +0000 (UTC) X-FDA: 82078714242.06.425295B Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf05.hostedemail.com (Postfix) with ESMTP id 005CE10000A for ; Fri, 3 May 2024 23:43:39 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=OXAhnF1m; spf=pass (imf05.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.180 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714779820; 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=hP+dUWCvJXqFCm1BZPWTzdhC4tLQMbPhbpvfeYsuGgg=; b=GH6XufXbGkI6LTkG57ytnApF1VVdzzAdPCO51FbXGuYuA138ZdHFITmpMgOT/X7V/00xn5 xxYxEMzjq6PG1nF6IOANQWx7iu4ENejXuVVoauLSOr9D1c48PHYKW2QH9LNCpHeegixlh+ ruEXmMUmc33gWydVG7SuLOaSW/a66kM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=OXAhnF1m; spf=pass (imf05.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.180 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714779820; a=rsa-sha256; cv=none; b=y8TDe2Xmysa6pGe5eibAu61H95O8FL7o6hJnvYPqB87+6Oa6Cte9fmMURbeEW67kzyAk6m fvTxhTWphxLYQemFg8dg/kG3aS2TZbyV6qY2t7zyAd4rtzqfJfY9/t/KOwk53AoX/9C919 +kA6rNHzHRYkieFzq6OYOB/648ZGhkY= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1ec5387aed9so1662225ad.3 for ; Fri, 03 May 2024 16:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1714779819; x=1715384619; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hP+dUWCvJXqFCm1BZPWTzdhC4tLQMbPhbpvfeYsuGgg=; b=OXAhnF1mM5MVg++XlczTtjImqFYLaIUl08/dQLWYGdGOeoILsRmeYYVnKvVwljf2Uj p4fipI/I6b1yPVft7xGoS20uaHUDSQevFfgsQTzcXHjtKn2G4ycQSkGgOiViGBWgrk3B Xks8QYAzjTKXr3zjtoO1+Z55ILBNYxROX7C9E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714779819; x=1715384619; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hP+dUWCvJXqFCm1BZPWTzdhC4tLQMbPhbpvfeYsuGgg=; b=Ma85xwvZ7ZKeA64l5IgUPe/moPGSEgDVS+MCgHvUEm0HD6e1K43fpsCthVFClIcump ZN2fRrmcHtEdujKK5Bl+HDtrm0+DHM2Gat3SWWhqFKrrVjyMIKiEK+5zw9gByoZq4tA3 pewCmz67j8tVJRFWgfqk+CDxZZJxTcOv2Qwb4TzLeFXPUDHwS0xjmxPQXPVqlJ1Vty57 SH523aZ9Wt5BvmpWIJhNzUg4QP2i10fjqtg38LBHhj0dhwAYUFxjNuSeLkPfYkkiNMku m8P99ql0s5zF7NNmRyZfPkGuxa72n+CUuwuNM3QVL2KSC5rLT2UGZpEhXULLIEhZvqp8 1WnQ== X-Forwarded-Encrypted: i=1; AJvYcCULv35iabuj8tnIq53Nl6+JUaaQWYow9JXOvj1bmhuPnOizVEvtlVfxzvCSm2mpUyQBWF6VhiliW4QEW7rB9LXouts= X-Gm-Message-State: AOJu0YzzrNp/u8DC5SLn6m8FdB/SkGbC35ekG9Ys3/KlM/9iS2/FKwF0 zxKrJnuPggjBEzixDwR2btevC7Tz5amJnx+wHhK4UbUB1tVgqXgx9HTEl7+yWg== X-Google-Smtp-Source: AGHT+IEygCbwCpI7xjb71AoumHXdf2ry+30qYYFJd6deEDKA0dH5g8yyZFHZPXGPeG6dZEA2I8WycA== X-Received: by 2002:a17:902:c948:b0:1eb:61a4:a2bc with SMTP id i8-20020a170902c94800b001eb61a4a2bcmr5466122pla.43.1714779818868; Fri, 03 May 2024 16:43:38 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id c8-20020a170903234800b001e2b4f513e1sm3819248plh.106.2024.05.03.16.43.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 May 2024 16:43:38 -0700 (PDT) Date: Fri, 3 May 2024 16:43:37 -0700 From: Kees Cook To: Luis Chamberlain Cc: Allen Pais , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, ebiederm@xmission.com, j.granados@samsung.com, allen.lkml@gmail.com Subject: Re: [PATCH v3] fs/coredump: Enable dynamic configuration of max file note size Message-ID: <202405031634.77B223D8@keescook> References: <20240502235603.19290-1-apais@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: myjudd7anahog4aftnb5f1nyx94eh7xd X-Rspam-User: X-Rspamd-Queue-Id: 005CE10000A X-Rspamd-Server: rspam05 X-HE-Tag: 1714779819-917888 X-HE-Meta: U2FsdGVkX1/jcSoYQCzH1TJtJmde3xwKKr7e02f9M5hGH+LqHWzhKg83i7U2wz6GGEh7KE/UJcAX8HLzkAUMZhc4psd9KgEI8xoarPPzePPgZgEjh1kMzBb2kPjBMKg+WP/btDMIGEFYyWZvyk7NtMB4oykjgkovplNLKn737Fi6vbUKLOtza+0QsrfmJfR9ckEr24Of0l1Vjx0s+v+xARrIrnEb/ijjYx7TcRYkq4BjXjSmEFKDDRk7HlfRCko029XA7j00ufTQLAKWU8sKQT3q3+ftBwn7Lm4YvSXSTbRjR70NOrV9qSpZelk5BIL+ah9T8DDIKPDIkCGGqyljPXnqu9gYjrYvYL26ALRVKvj+HlOmJm/gSS+DhPeZugl6MxhQE2xJUpjTY/ydmTCyPuk2YGj6de/Gjdss901szFUgBcgpfosKlmUAi39grNvuM/FpuOYGuvH/t43pQ1KwkZvzPlUvu3UGR8eLCwOeM1Rw2Z0L+TwWWih+tBGPmEkMBYeB3JmCCzMRnynfzxPCjUDpl6fhXfJWmB8sr/XwTOAHyo9lAhMIqoCMFaeWeV9yymHox4k0uUdECccH4s3LEI83hPuP9Ndf68nFajFyP8LnuhlgRJiaoEcFYbIvDZUHkIPUPoJnqY2aDD/VPT818aa2kAHgGh+9U+5x1isCENp64/2l2x0q+esezkeNYgRdNHBfXB+RBT4rAgDLBo/i7bK996CqeeOSq53aRdivUbceBVfGx4i8Bv96MM4cBl/p6GpATDLh7oVgJKQo67WLR+VSRD/uWshuuXMLT6P1sr74WPcFREMQCuSiMpgXnEiZFjCMi3naWG5yAT5dPPjPaXFvQpZo7gvHURVeuvkoiHiTwlgHoLLX3mQfsd6a+Uh2odpchlc14zUu/McFz9Oybr1019DkFkSsRWOydyf+c3r6xnTFCLOnPw0m/IQ+wYhX2RsvucLbGpoyd/EUKt3 pToVa5q0 dTWi18+j+VwMjYhrTdoCWQvTic1Fi8EjVcJ/4J4GvrAks3AxDO3djHvRgShcQhd28CoAALoFlb/yiG2B7A4kn+Cw2MtYQbgoU2yYdFHBik31LQ+ExE5XeNDjCotxkS5/GlbSD0KSO5jFFt1upOUQXYr3ZNDC0Vv3uCJ94pQO4E0eRcIhWJm/iHxaw8jSVpj8vuB7jbRCoq2fFbIpIgspmrJU0BK3UyV/Zx2DKC+tXCgDAKAH8Bqe3ziVc3IvcyJ8aF58gazogLmQvRoF1M6LFxbdA2xaxJrq9WPaRvM+SWwD+MIQNyz+Hv1HMn2njG91UqHDHSrh7XyJgle/2T8u2hw/bAdTTSPq4OS0r05qRq1h48jEFJhVRZBhYkAIJhakcB7g/AE7nzY4Y1Bgqo531r8g9ouZqNDd3Jr4lfec8ZvP/eMU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.026545, 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, May 03, 2024 at 12:51:00PM -0700, Luis Chamberlain wrote: > Thanks for the cleanups, this is certainly now in the right direction. > Generic long term growth questions below. > > On Thu, May 02, 2024 at 11:56:03PM +0000, Allen Pais wrote: > > Why is this being done? > > We have observed that during a crash when there are more than 65k mmaps > > in memory, the existing fixed limit on the size of the ELF notes section > > becomes a bottleneck. The notes section quickly reaches its capacity, > > I'm not well versed here on how core dumps associate mmaps to ELF notes > section, can you elaborate? Does each new mmap potentially peg > information on ELF notes section? Where do we standardize on this? Does > it also change depending on any criteria of the mmap? This is all in fs/binfmt_elf.c, fill_note_info(). There's a dump for each thread's info, and then fill_files_note() (which is what this code is adjusting) which writes out every filename for any file-map VMAs. The format of NT_FILE record is documented above fill_files_note(). So, it all depends on the count of VMAs and length of filenames. > Depending on the above, we might want to be proactive to get a sense of > when we want to go beyond the new 16 MiB max cap on new mmaps for instance. > How many mmaps can we have anyway too? INT_MAX :) I'm fine with the new 16MiB max for the coredump. If we really need to go beyond this, we might need to avoid building the entire thing in memory, and instead move it all into write_note_info() directly, but I'm not interested in that refactor unless we have an overwhelmingly good reason to do so. -- Kees Cook