LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andrew Morton <firstname.lastname@example.org>
To: "Kawai, Hidehiro" <email@example.com>
Cc: kernel list <firstname.lastname@example.org>,
Pavel Machek <email@example.com>, Robin Holt <firstname.lastname@example.org>,
David Howells <email@example.com>,
Alan Cox <firstname.lastname@example.org>,
Masami Hiramatsu <email@example.com>,
Satoshi OSHIMA <firstname.lastname@example.org>,
Hideo AOKI <email@example.com>
Subject: Re: [PATCH 0/4] coredump: core dump masking support v4
Date: Wed, 28 Mar 2007 10:32:23 -0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Wed, 28 Mar 2007 21:37:07 +0900 "Kawai, Hidehiro" <email@example.com> wrote:
> > 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.
> There are people who wish to dump VMAs which are not dumped by default.
> Taking this into account, some bits of core_dumpfilter will be set by
> default. This means users have to be aware of the default bitmask
> when they change the bitmask. Perhaps changing the bitmask requires
> 3 steps:
> 1. read the default bitmask
> 2. change bits of the mask
> 3. write it to the proc entry
> So I think it is better if we provide /proc/pid/core_flags (default:
> all bits are 0) instead of core_dumpfilter. With this interface,
> users who use only one bit of the bitmask (this will be a common case)
> just have to write 2^n to the proc entry. It takes only one step:
> 1. write a value to the proc entry
> If we can implement at the same cost, core_flags will be better
> because it is useful for users. What would you think about that?
It sounds unnecessarily complex, and unnecessarily different from our
normal expectations of /proc files. And the value we read differs from the
value we wrote... I think having a non-zero default will be fine.
> By the way, Robin Holt wrote as follows:
> > Can you make this a little more transparent? Having a magic bitmask does
> > not seem like the best way to do stuff. Could you maybe make a core_flags
> > directory with a seperate file for each flag. It could still map to a
> > single field in the mm, but be broken out for the proc filesystem.
> Do you think Robin's suggestion is acceptable?
Marginal, I think. This is not likely to be a field which a lot of people
modify a lot of times. Those few people who need to work with this can
afford to look the values up in the documentation while writing their
And it requires a distressingly large amount of code to implement a /proc
file. Perhaps in this situation the code can be shared.
otoh, why is it a /proc thing at all?
unsigned long sys_set_corefile_filter(unsigned long enable_mask);
unsigned long sys_clear_corefile_filter(unsigned long enable_mask);
would be better?
prev parent reply other threads:[~2007-03-28 17:32 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
2007-03-28 12:37 ` Kawai, Hidehiro
2007-03-28 17:32 ` Andrew Morton [this message]
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).