Re: [PATCH 0/4] coredump: core dump masking support v4

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 28 Mar 2007 21:37:07 +0900 "Kawai, Hidehiro" <hidehiro.kawai.ez@hitachi.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
script.

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?