From: Andrew Morton <akpm@linux-foundation.org>
To: Daisuke HATAYAMA <d.hatayama@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
mhiramat@redhat.com, xiyou.wangcong@gmail.com,
andi@firstfloor.org, jdike@addtoit.com, tony.luck@intel.com
Subject: Re: [RESEND][mmotm][PATCH v2, 0/5] elf coredump: Add extended numbering support
Date: Thu, 7 Jan 2010 16:29:28 -0800 [thread overview]
Message-ID: <20100107162928.1d6eba76.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100104.100607.189714443.d.hatayama@jp.fujitsu.com>
On Mon, 04 Jan 2010 10:06:07 +0900 (JST)
Daisuke HATAYAMA <d.hatayama@jp.fujitsu.com> wrote:
> The current ELF dumper can produce broken corefiles if program headers
> exceed 65535. In particular, the program in 64-bit environment often
> demands more than 65535 mmaps. If you google max_map_count, then you
> can find many users facing this problem.
>
> Solaris has already dealt with this issue, and other OSes have also
> adopted the same method as in Solaris. Currently, Sun's document and
> AMD 64 ABI include the description for the extension, where they call
> the extension Extended Numbering. See Reference for further information.
>
> I believe that linux kernel should adopt the same way as they did, so
> I've written this patch.
>
> I am also preparing for patches of GDB and binutils.
That's a beautifully presented patchset. Thanks for doing all that
work - it helps.
UML maintenance appears to have ceased in recent times, so if we wish
to have these changes runtime tested (we should) then I think it would
be best if you could find someone to do that please.
And no akpm code-review would be complete without: dump_seek() is
waaaay to large to be inlined. Is there some common .c file to where
we could move it?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Daisuke HATAYAMA <d.hatayama@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
mhiramat@redhat.com, xiyou.wangcong@gmail.com,
andi@firstfloor.org, jdike@addtoit.com, tony.luck@intel.com
Subject: Re: [RESEND][mmotm][PATCH v2, 0/5] elf coredump: Add extended numbering support
Date: Thu, 7 Jan 2010 16:29:28 -0800 [thread overview]
Message-ID: <20100107162928.1d6eba76.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100104.100607.189714443.d.hatayama@jp.fujitsu.com>
On Mon, 04 Jan 2010 10:06:07 +0900 (JST)
Daisuke HATAYAMA <d.hatayama@jp.fujitsu.com> wrote:
> The current ELF dumper can produce broken corefiles if program headers
> exceed 65535. In particular, the program in 64-bit environment often
> demands more than 65535 mmaps. If you google max_map_count, then you
> can find many users facing this problem.
>
> Solaris has already dealt with this issue, and other OSes have also
> adopted the same method as in Solaris. Currently, Sun's document and
> AMD 64 ABI include the description for the extension, where they call
> the extension Extended Numbering. See Reference for further information.
>
> I believe that linux kernel should adopt the same way as they did, so
> I've written this patch.
>
> I am also preparing for patches of GDB and binutils.
That's a beautifully presented patchset. Thanks for doing all that
work - it helps.
UML maintenance appears to have ceased in recent times, so if we wish
to have these changes runtime tested (we should) then I think it would
be best if you could find someone to do that please.
And no akpm code-review would be complete without: dump_seek() is
waaaay to large to be inlined. Is there some common .c file to where
we could move it?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-01-08 0:30 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-04 1:06 [RESEND][mmotm][PATCH v2, 0/5] elf coredump: Add extended numbering support Daisuke HATAYAMA
2010-01-04 1:06 ` Daisuke HATAYAMA
2010-01-04 1:20 ` [RESEND][mmotm][PATCH v2, 1/5] Unify dump_seek() implementations for each binfmt_*.c Daisuke HATAYAMA
2010-01-04 1:20 ` Daisuke HATAYAMA
2010-01-04 1:20 ` [RESEND][mmotm][PATCH v2, 2/5] Move dump_write() and dump_seek() into a header file Daisuke HATAYAMA
2010-01-04 1:20 ` Daisuke HATAYAMA
2010-01-04 1:20 ` [RESEND][mmotm][PATCH v2, 3/5] elf coredump: replace ELF_CORE_EXTRA_* macros by functions Daisuke HATAYAMA
2010-01-04 1:20 ` Daisuke HATAYAMA
2010-01-04 1:20 ` [RESEND][mmotm][PATCH v2, 4/5] elf coredump: make offset calculation process and writing process explicit Daisuke HATAYAMA
2010-01-04 1:20 ` Daisuke HATAYAMA
2010-01-04 1:20 ` [RESEND][mmotm][PATCH v2, 5/5] elf coredump: Add extended numbering support Daisuke HATAYAMA
2010-01-04 1:20 ` Daisuke HATAYAMA
2010-01-08 0:29 ` Andrew Morton [this message]
2010-01-08 0:29 ` [RESEND][mmotm][PATCH v2, 0/5] " Andrew Morton
2010-01-08 0:32 ` Andrew Morton
2010-01-08 0:32 ` Andrew Morton
2010-01-08 2:14 ` Masami Hiramatsu
2010-01-08 2:14 ` Masami Hiramatsu
2010-01-12 3:12 ` Daisuke HATAYAMA
2010-01-12 3:12 ` Daisuke HATAYAMA
2010-01-12 3:24 ` Andrew Morton
2010-01-12 3:24 ` Andrew Morton
2010-01-12 8:05 ` Daisuke HATAYAMA
2010-01-12 8:05 ` Daisuke HATAYAMA
2010-01-12 8:16 ` Andrew Morton
2010-01-12 8:16 ` Andrew Morton
2010-01-13 8:57 ` Daisuke HATAYAMA
2010-01-13 8:57 ` Daisuke HATAYAMA
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=20100107162928.1d6eba76.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=d.hatayama@jp.fujitsu.com \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhiramat@redhat.com \
--cc=tony.luck@intel.com \
--cc=xiyou.wangcong@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.