From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1327 invoked by alias); 9 Dec 2009 16:16:54 -0000 Received: (qmail 1308 invoked by uid 22791); 9 Dec 2009 16:16:53 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Dec 2009 16:16:46 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB9GGjLp031151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Dec 2009 11:16:45 -0500 Received: from [10.16.2.46] (dhcp-100-2-46.bos.redhat.com [10.16.2.46]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nB9GGitq006064; Wed, 9 Dec 2009 11:16:44 -0500 Message-ID: <4B1FCD74.8020302@redhat.com> Date: Wed, 09 Dec 2009 16:16:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: KOSAKI Motohiro CC: Ingo Molnar , Andrew Morton , lkml , systemtap , DLE , Oleg Nesterov , Roland McGrath , Jason Baron Subject: Re: [PATCH v3] [RFC] tracepoint: Add signal coredump tracepoint References: <20091208104324.B589.A69D9226@jp.fujitsu.com> <20091208204007.31287.62096.stgit@dhcp-100-2-132.bos.redhat.com> <20091209142322.F4C8.A69D9226@jp.fujitsu.com> <4B1FCB54.6000105@redhat.com> In-Reply-To: <4B1FCB54.6000105@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00859.txt.bz2 Masami Hiramatsu wrote: > > > KOSAKI Motohiro wrote: >>> + TP_fast_assign( >>> + __entry->sig = (int)cprm->signr; >>> + __entry->limit = cprm->limit; >>> + __entry->flags = cprm->mm_flags; >>> + __entry->retval = retval; >>> + __assign_str(name, core_name); >>> + ), >>> + >>> + TP_printk("sig=%d limit=%lu dumpable=0x%lx dump_filter=0x%lx " >>> + "corename=\"%s\" retval=%d", >>> + __entry->sig, __entry->limit, >>> + __entry->flags& MMF_DUMPABLE_MASK, >>> + (__entry->flags& MMF_DUMP_FILTER_MASK)>> >>> + MMF_DUMP_FILTER_SHIFT, >>> + __get_str(name), __entry->retval) >>> +); >>> #endif /* _TRACE_SIGNAL_H */ >> >> I don't think "limit" is userfriendly name, core_limit or core_size_limit is better? >> plus, we have core_pipe_limit sysctl too. (it's similar but different concept limit). > > Ah, I missed it. OK, so I'll rename core_limit and add core_pipe_limit. Hmm, perhaps, would we need a pair of core_pipe_limit and dump_count? because it limits the number of concurrently dump-to-pipe and the number is stored on dump_count. Or, maybe it is enough to trace current parameters, because if we hit the core_pipe_limit, we can see -EFBIG at retval parameter. > Thank you for pointed it out :-) > >> >> other parts looks good to me. >> >> >> > > Thanks! > -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division e-mail: mhiramat@redhat.com