lkml.org 
[lkml]   [2007]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/4] coredump: core dump masking support v4
    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?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-03-28 19:35    [W:0.026 / U:177.816 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site