|
From: KOSAKI M. <kos...@jp...> - 2009-12-05 07:18:48
|
2009/12/3 Masami Hiramatsu <mhi...@re...>: > Add signal coredump tracepoint which shows signal number, > mm->flags, limits, pointer to file structure and core > file name. > > This tracepoint requirement comes mainly from the viewpoint of > administrators. 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, it will be 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. AFAIK, not-dumped case is important than dump successful case. IOW, admin need to know why the crashed process was not dumped. This tracepoint doesn't cover all failure case. especially binfmt->core_dump() et.al. IOW, this tracepoint seems too specialized piped-coredump feature. What do you think this tracepoint's use case? |