LKML Archive on
help / color / mirror / Atom feed
From: Andrew Morton <>
To: "Kawai, Hidehiro" <>
Cc: kernel list <>,
	Pavel Machek <>, Robin Holt <>,
	David Howells <>,
	Alan Cox <>,
	Masami Hiramatsu <>,
	sugita <>,
	Satoshi OSHIMA <>,
	Hideo AOKI <>
Subject: Re: [PATCH 0/4] coredump: core dump masking support v4
Date: Thu, 15 Mar 2007 13:37:21 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 02 Mar 2007 13:41:30 +0900
"Kawai, Hidehiro" <> wrote:

> This patch series is version 4 of the core dump masking feature,
> which provides a per-process flag not to dump anonymous shared
> memory segments.

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 


  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.

  parent reply	other threads:[~2007-03-15 20:37 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 ` Andrew Morton [this message]
2007-03-23 13:13   ` [PATCH 0/4] coredump: core dump masking support v4 Kawai, Hidehiro
2007-03-28 12:37     ` Kawai, Hidehiro
2007-03-28 17:32       ` Andrew Morton

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:

* 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).