linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Allen Pais <apais@linux.microsoft.com>
Cc: 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, keescook@chromium.org,
	j.granados@samsung.com, allen.lkml@gmail.com
Subject: Re: [PATCH v3] fs/coredump: Enable dynamic configuration of max file note size
Date: Fri, 3 May 2024 12:51:00 -0700	[thread overview]
Message-ID: <ZjVAJOsC-EtlIXd6@bombadil.infradead.org> (raw)
In-Reply-To: <20240502235603.19290-1-apais@linux.microsoft.com>

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?

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?

> leading to incomplete memory segment information in the resulting coredump.
> This truncation compromises the utility of the coredumps, as crucial
> information about the memory state at the time of the crash might be
> omitted.

  Luis


  parent reply	other threads:[~2024-05-03 19:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-02 23:56 Allen Pais
     [not found] ` <202405021743.D06C96516@keescook>
2024-05-03  1:10   ` Allen
2024-05-03  1:40     ` Allen
2024-05-03 23:31       ` Kees Cook
2024-05-03 19:51 ` Luis Chamberlain [this message]
2024-05-03 23:43   ` Kees Cook
2024-05-04  1:30 ` kernel test robot

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=ZjVAJOsC-EtlIXd6@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=allen.lkml@gmail.com \
    --cc=apais@linux.microsoft.com \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=j.granados@samsung.com \
    --cc=jack@suse.cz \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox