LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Kawai, Hidehiro" <email@example.com>
To: Andrew Morton <firstname.lastname@example.org>
Cc: kernel list <email@example.com>,
Pavel Machek <firstname.lastname@example.org>, Robin Holt <email@example.com>,
David Howells <firstname.lastname@example.org>,
Alan Cox <email@example.com>,
Masami Hiramatsu <firstname.lastname@example.org>,
Satoshi OSHIMA <email@example.com>,
Hideo AOKI <firstname.lastname@example.org>
Subject: Re: [PATCH 0/4] coredump: core dump masking support v4
Date: Fri, 23 Mar 2007 22:13:37 +0900 [thread overview]
Message-ID: <4603D281.email@example.com> (raw)
Thank you for your kind comments.
I'm still discussing the answer with my senior colleagues, so please
wait a few days. I think I can reply at the beginning of next week.
Hitachi, Ltd., Systems Development Laboratory
Andrew Morton wrote:
> On Fri, 02 Mar 2007 13:41:30 +0900
> "Kawai, Hidehiro" <firstname.lastname@example.org> wrote:
>>This patch series is version 4 of the core dump masking feature,
>>which provides a per-process flag not to dump anonymous shared
> First up, please convince us that this problem cannot be solved in
> userspace. Note that we now support dumping core over a pipe to a
> userspace application which can perform filtering such as this (see
> Assuming that your argument is successful...
> - The unpleasing trylock in proc_coredump_omit_anon_shared_write() is
> there, I believe, to handle the case where a coredump is presently in
> progress. We don't want to change the filtering rule while the dump is
> What I suggest you do instead is to take a copy of
> mm->coredump_omit_anon_shared into a local variable with one single read
> per coredump. Pass that local down into all the callees which need to
> see it. That way, no locking is needed.
> - These games we're playing with the atomicity of the bitfields in the
> mm_struct need to go away.
> First up, please prepare a standalone patch which removes
> mm_struct.dumpable and adds `unsigned long mm_struct.flags'. Include a
> comment telling people that they must use atomic bitops (set_bit, clear_bit) on
> Reimplement the current three-value dumpable silliness using two or
> three separate flags in mm_struct.flags. Of course, this design means
> that there will be tiny timing windows where the value of these two or
> three flags have intermediate, invalid states. Please take care of those
> little windows and document how you did so. I expect a suitable approach
> would be to set and clear the flags in a suitable order, so that if a
> race _does_ happen, the results are benign.
> - Once that is done, you're ready to think about your new functionality.
> Start out with
> #define MM_FLAG_COREDUMP_OMIT_ANON_SHARED (1 << 3)
> or whatever, and it all becomes easy.
> - Finally, the code as you have it here is very specific to your specific
> requirement: don't dump shared memory segments.
> But if we're going to implement in-kernel core-dump filtering of this
> nature, we should design it extensibly, even if we don't actually
> implement those extensions at this time.
> Because other people might (reasonably) wish to omit anonymous memory,
> or private mappings, or file-backed VMAs, or whatever.
> So maybe /proc/pid/coredump_omit_anon_shared should become
> /proc/pid/core_dumpfilter, which is a carefully documented bitmask.
next prev parent reply other threads:[~2007-03-23 13:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-02 4:41 Kawai, Hidehiro
2007-03-02 4:47 ` [PATCH 1/4] coredump: add an interface to control the core dump routine Kawai, Hidehiro
2007-03-02 9:34 ` Pavel Machek
2007-03-26 13:02 ` Kawai, Hidehiro
2007-03-29 10:49 ` Pavel Machek
2007-03-29 19:16 ` David Howells
2007-03-29 21:17 ` Andrew Morton
2007-03-30 10:29 ` Kawai, Hidehiro
2007-03-30 16:10 ` Andrew Morton
2007-03-31 13:03 ` David Howells
2007-03-02 4:49 ` [PATCH 2/4] coredump: ELF: enable to omit anonymous shared memory Kawai, Hidehiro
2007-03-02 4:50 ` [PATCH 3/4] coredump: ELF-FDPIC: " Kawai, Hidehiro
2007-03-02 4:51 ` [PATCH 4/4] coredump: documentation for proc entry Kawai, Hidehiro
2007-03-02 9:35 ` Pavel Machek
2007-03-20 11:11 ` Kawai, Hidehiro
2007-03-15 20:37 ` [PATCH 0/4] coredump: core dump masking support v4 Andrew Morton
2007-03-23 13:13 ` Kawai, Hidehiro [this message]
2007-03-28 12:37 ` Kawai, Hidehiro
2007-03-28 17:32 ` Andrew Morton
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH 0/4] coredump: core dump masking support v4' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).