From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9336 invoked by alias); 8 Dec 2009 01:51:27 -0000 Received: (qmail 9261 invoked by uid 22791); 8 Dec 2009 01:51:26 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from fgwmail7.fujitsu.co.jp (HELO fgwmail7.fujitsu.co.jp) (192.51.44.37) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Dec 2009 01:51:20 +0000 Received: from m1.gw.fujitsu.co.jp ([10.0.50.71]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id nB81pHfJ007103 for (envelope-from kosaki.motohiro@jp.fujitsu.com); Tue, 8 Dec 2009 10:51:17 +0900 Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 90F0545DE4E for ; Tue, 8 Dec 2009 10:51:17 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 6861645DE4D for ; Tue, 8 Dec 2009 10:51:17 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 5357B1DB803F for ; Tue, 8 Dec 2009 10:51:17 +0900 (JST) Received: from m105.s.css.fujitsu.com (m105.s.css.fujitsu.com [10.249.87.105]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 012BA1DB803A for ; Tue, 8 Dec 2009 10:51:17 +0900 (JST) Received: from m105.css.fujitsu.com (m105 [127.0.0.1]) by m105.s.css.fujitsu.com (Postfix) with ESMTP id C504A5D8006; Tue, 8 Dec 2009 10:51:16 +0900 (JST) Received: from [127.0.0.1] (unknown [10.124.100.179]) by m105.s.css.fujitsu.com (Postfix) with ESMTP id 4A7025D8002; Tue, 8 Dec 2009 10:51:16 +0900 (JST) X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Received: from KOSANOTE2[10.124.100.179] by KOSANOTE2 (FujitsuOutboundMailChecker v1.3.1/9992[10.124.100.179]); Tue, 08 Dec 2009 10:51:20 +0900 (JST) From: KOSAKI Motohiro To: Masami Hiramatsu Subject: Re: [PATCH v2] [RFC] tracepoint: Add signal coredump tracepoint Cc: kosaki.motohiro@jp.fujitsu.com, Ingo Molnar , Andrew Morton , lkml , systemtap , DLE , Oleg Nesterov , Roland McGrath , Jason Baron In-Reply-To: <4B1D1E7C.8000806@redhat.com> References: <2f11576a0912042318u4c9c90cetb4ce136e977c2596@mail.gmail.com> <4B1D1E7C.8000806@redhat.com> Message-Id: <20091208104324.B589.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 08 Dec 2009 01:51:00 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00831.txt.bz2 > KOSAKI Motohiro wrote: > > 2009/12/3 Masami Hiramatsu: > >> 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. > > Certainly, failure cases are important, but also, the cases > that dumped-core doesn't or does include some sections > are also important. correct. > > This tracepoint doesn't cover all failure case. especially > > binfmt->core_dump() et.al. > > IOW, this tracepoint seems too specialized piped-coredump feature. > > Hmm, so would you mean that after calling binfmt->core_dump() > is better place? I think your following use-case desired so. if you have unwritten reason, please correct me. For example, a process didn't generated core, coredump doesn't have some sections, etc. > > What do you think this tracepoint's use case? > > Frankly to say, our first attempt was tracing mm->flags because > it can be changed by users without asking, and they sometimes > ask why core is not perfect or why core file is so big. > > Perhaps, covering all of those failure cases and succeed cases, > gives better information for them. In that case, we might better > tweak execution(goto) path to leave some error code on retval. This is enough acceptable to me. > > e.g. > if (IS_ERR(file)) > goto fail_dropcount; > + retval = -EBADF; > inode = file->f_path.dentry->d_inode; > if (inode->i_nlink > 1) > goto close_fail; /* multiple links - don't dump */ > if (!ispipe && d_unhashed(file->f_path.dentry)) > goto close_fail; > > /* AK: actually i see no reason to not allow this for named pipes etc., > but keep the previous behaviour for now. */ > if (!ispipe && !S_ISREG(inode->i_mode)) > goto close_fail; > /* > * Dont allow local users get cute and trick others to coredump > * into their pre-created files: > */ > + retval = -EPERM; > if (inode->i_uid != current_fsuid()) > goto close_fail; > + retval = -EINVAL; > if (!file->f_op) > goto close_fail; > if (!file->f_op->write) > goto close_fail; > + retval = -EEXIST; > if (!ispipe && do_truncate(file->f_path.dentry, 0, 0, file) != 0) > goto close_fail; > > > Thank you, > > -- > Masami Hiramatsu > > Software Engineer > Hitachi Computer Products (America), Inc. > Software Solutions Division > > e-mail: mhiramat@redhat.com >