[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj+buZ5Efw4so9FbaJ5Q=xLr0+bcYDafouehVG93Msd7w@mail.gmail.com>
Date: Fri, 9 Aug 2024 08:13:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Brian Mak <makb@...iper.net>, Kees Cook <kees@...nel.org>,
Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH v3] binfmt_elf: Dump smaller VMAs first in ELF cores
On Fri, 9 Aug 2024 at 07:40, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> I asked him to perform this at snapshot time. Plus it is obvious at
> snapshot time that you can change the allocated array, while it is
> not so obvious in the ->core_dump methods.
Fair enough. The days when we supported a.out dumps are obviously long
long gone, and aren't coming back.
So I am not adamant that it has to be done in the dumper, and I
probably just have that historical "we have multiple different dumpers
with different rules" mindset that isn't really relevant any more.
> I would argue that the long term maintainable thing to do is to
> merge elf_core_dump and elf_fdpic_core_dump and put all of the code
> in fs/coredump.c
I wouldn't object. It's not like there's any foreseeable new core dump
format that we'd expect, and the indirection makes the code flow
harder to follow.
Not that most people look at this code a lot.
Linus
Powered by blists - more mailing lists