From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jann Horn <jannh@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
"Eric W . Biederman" <ebiederm@xmission.com>,
Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH v4 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_lock properly in there
Date: Wed, 26 Aug 2020 10:15:42 -0700 [thread overview]
Message-ID: <CAHk-=wgedMxgfNPccK9Fgm0JQ=UX91HCndOnO1qAiUOoCOJi5w@mail.gmail.com> (raw)
In-Reply-To: <20200826151448.3404695-1-jannh@google.com>
On Wed, Aug 26, 2020 at 8:15 AM Jann Horn <jannh@google.com> wrote:
>
> After this series has landed, we should be able to rip out
> mmget_still_valid().
I think you should just add that to the series, since it's kind of the
point of it all.
But ack on this, it now looks saner than what we used to have regardless.
I do wonder if we should possibly just limit the number of vma's we
dump based on core size ulimit too, but that, I think, might be a
"further improvement" rather than base cleanup.
Linus
prev parent reply other threads:[~2020-08-26 17:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-26 15:14 [PATCH v4 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_lock properly in there Jann Horn
2020-08-26 15:14 ` [PATCH v4 1/5] binfmt_elf_fdpic: Stop using dump_emit() on user pointers on !MMU Jann Horn
2020-08-26 15:14 ` [PATCH v4 2/5] coredump: Let dump_emit() bail out on short writes Jann Horn
2020-08-26 15:14 ` [PATCH v4 3/5] coredump: Refactor page range dumping into common helper Jann Horn
2020-08-26 15:14 ` [PATCH v4 4/5] binfmt_elf, binfmt_elf_fdpic: Use a VMA list snapshot Jann Horn
2020-08-26 17:14 ` Linus Torvalds
2020-08-26 15:14 ` [PATCH v4 5/5] mm/gup: Take mmap_lock in get_dump_page() Jann Horn
2020-08-26 17:15 ` Linus Torvalds [this message]
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='CAHk-=wgedMxgfNPccK9Fgm0JQ=UX91HCndOnO1qAiUOoCOJi5w@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hch@lst.de \
--cc=jannh@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oleg@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).