From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12886 invoked by alias); 3 Jul 2008 18:48:29 -0000 Received: (qmail 12716 invoked by uid 22791); 3 Jul 2008 18:48:29 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_54,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Jul 2008 18:48:01 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m63IlxuC016794 for ; Thu, 3 Jul 2008 14:47:59 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [10.16.255.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m63Ilwhu009682; Thu, 3 Jul 2008 14:47:58 -0400 Received: from [10.16.3.219] (dhcp-100-3-219.bos.redhat.com [10.16.3.219]) by mail.boston.redhat.com (8.13.1/8.13.1) with ESMTP id m63Ilvrq026353; Thu, 3 Jul 2008 14:47:57 -0400 Message-ID: <486D1E8D.8070503@redhat.com> Date: Thu, 03 Jul 2008 18:48:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Mathieu Desnoyers CC: KOSAKI Motohiro , Takashi Nishiie , "'Alexey Dobriyan'" , "'Peter Zijlstra'" , "'Steven Rostedt'" , "'Frank Ch. Eigler'" , "'Ingo Molnar'" , "'LKML'" , "'systemtap-ml'" , "'Hideo AOKI'" Subject: Re: [RFC PATCH] Kernel Tracepoints (update) References: <007601c8d5ca$18fa0e10$4aee2a30$@css.fujitsu.com> <48611B03.1000003@redhat.com> <20080625011951.D83E.KOSAKI.MOTOHIRO@jp.fujitsu.com> <48612879.5090809@redhat.com> <20080625235214.GA14249@Krystal> <486403F0.4020801@redhat.com> <20080627133622.GA15210@Krystal> <486CEFDB.7070508@redhat.com> <20080703181839.GA10672@Krystal> In-Reply-To: <20080703181839.GA10672@Krystal> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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: 2008-q3/txt/msg00039.txt.bz2 Hi Mathieu, Mathieu Desnoyers wrote: > Hi Masami, > > I am thinking about removing the private_data, because such declaration > won't work : > > DEFINE_TRACE(kernel_irq_exit, > TPPROTO(void), > TPARGS()); > > because the arguments become : > > (void *private_data, void) Oh, you right. since there is no tracepoint user who uses private_data, we can remove it. > Any better idea ? If you need it, I think you can introduce some macros like below. #define TPPROTO(args...) (void *private_data, args) #define __define_trace_register(name, proto) \ /*shared by DEFINE_TRACE/DEFINE_TRACE_NOARG*/ static inline int register_trace_##name(\ void (*probe)proto, \ void *private_data) \ { \ return tracepoint_probe_register(#name ":" #proto, \ (void *)probe, private_data); \ } \ static inline void unregister_trace_##name( \ void (*probe)proto, \ void *private_data) \ { \ tracepoint_probe_unregister(#name ":" #proto, \ (void *)probe, private_data); \ } #define DEFINE_TRACE_NOARG(name) \ static inline void _do_trace_##name(struct tracepoint *tp) \ ... static inline void trace_##name(void) \ ... __define_trace_register(name, (void *private_data)) But I think removing private_data is better... Thank you, > > Mathieu > > * Masami Hiramatsu (mhiramat@redhat.com) wrote: >> Hi Mathieu, >> >> I found a bug. >> Mathieu Desnoyers wrote: >> [...] >> >>> +/* >>> + * Remove the tracepoint from the tracepoint hash table. Must be called with >>> + * mutex_lock held. >>> + */ >>> +static int remove_tracepoint(const char *name) >>> +{ >>> + struct hlist_head *head; >>> + struct hlist_node *node; >>> + struct tracepoint_entry *e; >>> + int found = 0; >>> + size_t len = strlen(name) + 1; >>> + u32 hash = jhash(name, len-1, 0); >>> + >>> + head = &tracepoint_table[hash & ((1 << TRACEPOINT_HASH_BITS)-1)]; >>> + hlist_for_each_entry(e, node, head, hlist) { >>> + if (!strcmp(name, e->name)) { >>> + found = 1; >>> + break; >>> + } >>> + } >>> + if (!found) >>> + return -ENOENT; >> before removing, you have to ensure refcount == 0. So, >> if (e->refcount != 0) >> return -EBUSY; >> >>> + hlist_del(&e->hlist); >>> + /* Make sure the call_rcu has been executed */ >>> + if (e->rcu_pending) >>> + rcu_barrier(); >>> + kfree(e); >>> + return 0; >>> +} >> Thank you, >> >> -- >> Masami Hiramatsu >> >> Software Engineer >> Hitachi Computer Products (America) Inc. >> Software Solutions Division >> >> e-mail: mhiramat@redhat.com >> > -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com