linux-kernel - Re: [PATCH v2] mm: Introduce coredump parameter structure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B16ACD6.3030402@redhat.com>
Date:	Wed, 02 Dec 2009 13:07:18 -0500
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	linux-kernel@...r.kernel.org, dhowells@...hat.com,
	hidehiro.kawai.ez@...achi.com, lethal@...ux-sh.org,
	roland@...hat.com, vapier@...too.org,
	Takahiro Yasui <tyasui@...hat.com>
Subject: Re: [PATCH v2] mm: Introduce coredump parameter structure

Ingo Molnar wrote:
> * Masami Hiramatsu<mhiramat@...hat.com>  wrote:
>
>> Andrew Morton wrote:
>>> On Sat, 28 Nov 2009 23:41:19 -0500
>>> Masami Hiramatsu<mhiramat@...hat.com>   wrote:
>>>
>>>> Introduce coredump parameter data structure (struct coredump_params)
>>>> for simplifying binfmt->core_dump() arguments.
>>>>
>>>> Changes in v2:
>>>>     - Don't remove DUMP_WRITE() macro.
>>>
>>> What is the reason for this change?
>>>
>>> Please always include both the "what" and the "why" in changelog text.
>>
>> I see.
>
> I think Andrew wanted to see a longer explanation about precisely what
> we need for these tracepoints and what the various specific usecases are
> to utilize it.

Ah, OK.

>
> I.e. a basic cost/benefit analysis is needed. By looking at the patch we
> can see the cost - but you have to counter-balance that with enough
> stuff in the 'benefits' column of the equation.

Hmm, actually, this tracepoint requirement comes from the viewpoint of
administrators (not developers). Since now we have introduced many
coredump configurations (e.g. dumpable, coredump_filter, core_pattern, etc)
and some of them can be modified by users, we assume it is hard to know
what was actually dumped (or not dumped) after some problem happened on the
system. For example, a process didn't generated core, coredump doesn't have
some sections, etc. In those cases, the coredump tracepoint can help us to
know why the core file is so big or small, or not generated, by recording
all configurations for all processes on the system. That will reduce
system-administration cost.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@...hat.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/