linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kawai, Hidehiro" <hidehiro.kawai.ez@hitachi.com>
To: akpm@osdl.org, pavel@suse.cz, linux-kernel@vger.kernel.org
Cc: dhowells@redhat.com, alan@lxorguk.ukuu.org.uk
Subject: [PATCH 0/4] coredump: core dump masking support v2
Date: Fri, 26 Jan 2007 23:05:07 +0900	[thread overview]
Message-ID: <45BA0A93.30004@hitachi.com> (raw)

Hi,

This patch series is version 2 of the core dump masking feature,
which enables you to specify the memory segment types you don't
want to dump into a core file. 

In this version, the setting for which memory segment types are
dumped is stored as a bit field and placed next to `dumpable'
bit field in mm_struct.  Writing to these two bit fields can cause
race condition, so I use a global spin lock to protect them from
write-write race.
In consideration of security, I adds a sysctl parameter to
enable/disable this feature.

This patch series can be applied against 2.6.20-rc4-mm1.
The supported core file formats are ELF and ELF-FDPIC. ELF has been
tested, but ELF-FDPIC has not been build and tested because I don't
have the test environment.


Description:
You can specify memory segment types you don't want to dump via
/proc/<pid>/core_flags file, which is provided per process.
This file represents a set of flags, but currently, only bit 0 is
available. If bit 0 is set, the kernel core dump routine doesn't
dump anonymous shared memory segments, which includes IPC shared
memory and some of mmap(2)'ed memory.

System administrator can enable/disable these flags one by one via
/proc/sys/kernel/core_flags_enable file. The default value is 1.
This means that bit 0 in core_flags is effective.


Background:
Some software programs share huge memory among hundreds of
processes. If a failure occurs on one of these processes, they can
be signaled by a monitoring process to generate core files and
restart the service. However, it can develop into a system-wide
failure such as system slow down for a long time and disk space
shortage because the total size of the core files is very huge!

To avoid the above situation we can limit the core file size by
setrlimit(2) or ulimit(1). But this method can lose important data
such as stack because core dumping is terminated halfway.
So I suggest keeping shared memory segments from being dumped for
particular processes. Because the shared memory attached to processes
is common in them, we don't need to dump the shared memory every time.


Usage:
If you don't want to dump all shared memory segments attached to
pid 1234, set the bit 0 of the process's core_flags to 1:

  $ echo 1 > /proc/1234/core_flags

Additionally, you can check its hexadecimal value by reading the file:

  $ cat /proc/1234/core_flags
  00000001

When a new process is created, the process inherits the core_flags
setting from its parent. It is useful to set the core_flags before
the program runs. For example:

  $ echo 1 > /proc/self/core_flags
  $ ./some_program


ChangeLog:
v2:
  - rename `coremask' to `core_flags'
  - change `core_flags' member in mm_struct to a bit field
    next to `dumpable'
  - introduce a global spin lock to protect adjacent two bit fields
    (core_flags and dumpable) from race condition
  - fix a bug that the generated core file can be corrupted when
    core dumping and updating core_flags occur concurrently
  - add kernel.core_flags_enable sysctl parameter to enable/disable
    flags in /proc/<pid>/core_flags
  - support ELF-FDPIC binary format, but not tested

v1:
http://lkml.org/lkml/2006/12/13/17

-- 
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory



             reply	other threads:[~2007-01-26 14:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-26 14:05 Kawai, Hidehiro [this message]
2007-01-26 14:12 ` [PATCH 1/4] coredump: add an interface to specify omitted memory segment types Kawai, Hidehiro
2007-01-26 14:13 ` [PATCH 2/4] coredump: enable to omit anonymous shared memory Kawai, Hidehiro
2007-01-26 14:14 ` [PATCH 3/4] coredump: add a sysctl parameter to disable the core dump omitting feature Kawai, Hidehiro
2007-01-26 16:56   ` Pavel Machek
2007-01-26 14:15 ` [PATCH 4/4] coredump: documentation for proc and sysctl Kawai, Hidehiro
2007-01-26 15:29 ` [PATCH 0/4] coredump: core dump masking support v2 Robin Holt
2007-01-30  7:36   ` Kawai, Hidehiro
2007-01-30 12:44     ` Robin Holt
2007-01-31 12:40       ` Kawai, Hidehiro
2007-02-03 12:48         ` Pavel Machek
2007-02-14 13:26           ` Kawai, Hidehiro
2007-02-14 13:30             ` Pavel Machek

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=45BA0A93.30004@hitachi.com \
    --to=hidehiro.kawai.ez@hitachi.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    /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).