[lkml]   [2007]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/4] coredump: core dump masking support v4
On Wed, 28 Mar 2007 21:37:07 +0900 "Kawai, Hidehiro" <> 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?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-03-28 19:35    [W:0.066 / U:5.280 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site