Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp100122iog; Sun, 12 Jun 2022 20:24:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxm+7tu5XvEWM0eJGIpluLX3kONmZy/XUjS6hU6v6N9F137al9IWHNDbFGU/3ged003INLc X-Received: by 2002:a05:6402:405:b0:433:426d:7d59 with SMTP id q5-20020a056402040500b00433426d7d59mr20580766edv.122.1655090643267; Sun, 12 Jun 2022 20:24:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655090643; cv=none; d=google.com; s=arc-20160816; b=wcy6Uxhy/NnVgLyoTKRMzHm4VizIwDW56Ifv3OXlY5PlACGNRLv0DOFegOA+KNBIWn C1vpamtNgJ084/0kgbephllTgL6TgtfgW8qmv6eJNGlf0OjFoHVwgFD388U0k6sOQngk mJAt31y9Ymxlv2uoiRDn1BdtYfn1LP2RHNxzFmY+5SLe+pjd7zWXiT8DrosHEIni3ADa HvIzglQlUWLUNiJezTZ5VFvAXDv/VaIph8JRdflcrXWLhSAlRyVz5zBpU5x6GKfucU9u qa/6SSH/bN9jqkYWbpsCJyRHiz5iKhrH+SOQ7aXxL8k3+n7tuP274CFWoKtpVoBHIc0M td7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=uyLApAgVLPZTpAs9psU57WiAZIJnNi/Z51eEECIb6f0=; b=i6DPP7XvHR3tOMJQSe7Y2LmAqP8pf5IdPCtTpnsrBJVnr1vpbU5R9y1+5NEEthVWfD Qj5yAX3yKR6d0v//huTMjcIznLEU7H4Qj5SG4CnETVFCiq+Dgg4ztRP+Nb1+Fu/zX1Tr nL1xVwgDLciixvxHqJvLgy9eqDMfgZPnDxPPV0R04VUk9LmMKbyPrV3vI7joIkidhQMR mTIqJDUsTNDQmrBUSpfyTxkSKSNRdp7FL0pkP4O8gHwa9YePUckRzugAKIZaSwCmRsik H+Eo/E53mvYNnwHT3C1xsDHvxoNQys3lqT6I1tE3/Db6n9MKjgb9XkpWB410w1djfQLs h+/Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c27-20020a1709063f1b00b0070758cf771fsi5869633ejj.463.2022.06.12.20.23.39; Sun, 12 Jun 2022 20:24:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237405AbiFLWrJ (ORCPT + 99 others); Sun, 12 Jun 2022 18:47:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232947AbiFLWrI (ORCPT ); Sun, 12 Jun 2022 18:47:08 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1007A15FD2; Sun, 12 Jun 2022 15:47:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9BA60B801BD; Sun, 12 Jun 2022 22:47:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0503C34115; Sun, 12 Jun 2022 22:47:02 +0000 (UTC) Date: Sun, 12 Jun 2022 18:46:59 -0400 From: Steven Rostedt To: Dominique Martinet Cc: Christian Schoenebeck , Tyler Hicks , Eric Van Hensbergen , Latchesar Ionkov , Ingo Molnar , "David S. Miller" , Jakub Kicinski , Paolo Abeni , v9fs-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 05/06] 9p fid refcount: add a 9p_fid_ref tracepoint Message-ID: <20220612184659.6dff5107@rorschach.local.home> In-Reply-To: <20220612085330.1451496-6-asmadeus@codewreck.org> References: <20220612085330.1451496-1-asmadeus@codewreck.org> <20220612085330.1451496-6-asmadeus@codewreck.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 12 Jun 2022 17:53:28 +0900 Dominique Martinet wrote: This needs to have a change log. A tracepoint should never be added without explaining why it is being added and its purpose. > Signed-off-by: Dominique Martinet > --- > > This is the first time I add a tracepoint, so if anyone has time to > check I didn't make something too stupid please have a look. > I've mostly copied from netfs'. > > Also, a question if someone has time: I'd have liked to use the > tracepoint in static inline wrappers for getref/putref, but it's not > good to add the tracepoints to a .h, right? Correct, because it can have unexpected side effects. Thus it is best to call a wrapper function that is defined in a C file that will then call the tracepoint. To avoid the overhead of the function call when tracing is not enabled, you should use (in the header): #include DECLARE_TRACEPOINT(); if (tracepoint_enabled()) do_(...); and in the C file have: void do_(...) { trace_(...); } that calls the tracepoint. The tracepoint_enabled()() is another special function that is created by the TRACE_EVENT() macro to use, that is a static branch and not a real if statement. That is, it is a nop that skips calling the wrapper function when not enabled, and a jmp to call the wrapper function when the tracepoint is enabled. How to do this is described in include/linux/tracepoint-defs.h and there's an example of this use case in include/linux/mmap_lock.h. > Especially with the CREATE_TRACE_POINTS macro... > How do people usually go about that, just bite the bullet and make it > a real function? > > > include/trace/events/9p.h | 48 +++++++++++++++++++++++++++++++++++++++ > net/9p/client.c | 9 +++++++- > 2 files changed, 56 insertions(+), 1 deletion(-) > > diff --git a/include/trace/events/9p.h b/include/trace/events/9p.h > index 78c5608a1648..4dfa6d7f83ba 100644 > --- a/include/trace/events/9p.h > +++ b/include/trace/events/9p.h > @@ -77,6 +77,13 @@ > EM( P9_TWSTAT, "P9_TWSTAT" ) \ > EMe(P9_RWSTAT, "P9_RWSTAT" ) > > + > +#define P9_FID_REFTYPE \ > + EM( P9_FID_REF_CREATE, "create " ) \ > + EM( P9_FID_REF_GET, "get " ) \ > + EM( P9_FID_REF_PUT, "put " ) \ > + EMe(P9_FID_REF_DESTROY, "destroy" ) > + > /* Define EM() to export the enums to userspace via TRACE_DEFINE_ENUM() */ > #undef EM > #undef EMe > @@ -84,6 +91,21 @@ > #define EMe(a, b) TRACE_DEFINE_ENUM(a); > > P9_MSG_T > +P9_FID_REFTYPE > + > +/* And also use EM/EMe to define helper enums -- once */ > +#ifndef __9P_DECLARE_TRACE_ENUMS_ONLY_ONCE > +#define __9P_DECLARE_TRACE_ENUMS_ONLY_ONCE > +#undef EM > +#undef EMe > +#define EM(a, b) a, > +#define EMe(a, b) a > + > +enum p9_fid_reftype { > + P9_FID_REFTYPE > +} __mode(byte); > + > +#endif > > /* > * Now redefine the EM() and EMe() macros to map the enums to the strings > @@ -96,6 +118,8 @@ P9_MSG_T > > #define show_9p_op(type) \ > __print_symbolic(type, P9_MSG_T) > +#define show_9p_fid_reftype(type) \ > + __print_symbolic(type, P9_FID_REFTYPE) > > TRACE_EVENT(9p_client_req, > TP_PROTO(struct p9_client *clnt, int8_t type, int tag), > @@ -168,6 +192,30 @@ TRACE_EVENT(9p_protocol_dump, > __entry->tag, 0, __entry->line, 16, __entry->line + 16) > ); > > + > +TRACE_EVENT(9p_fid_ref, > + TP_PROTO(struct p9_fid *fid, __u8 type), > + > + TP_ARGS(fid, type), > + > + TP_STRUCT__entry( > + __field( int, fid ) > + __field( int, refcount ) > + __field( __u8, type ) > + ), > + > + TP_fast_assign( > + __entry->fid = fid->fid; > + __entry->refcount = refcount_read(&fid->count); > + __entry->type = type; > + ), > + > + TP_printk("%s fid %d, refcount %d", > + show_9p_fid_reftype(__entry->type), > + __entry->fid, __entry->refcount) > +); > + > + > #endif /* _TRACE_9P_H */ > > /* This part must be outside protection */ > diff --git a/net/9p/client.c b/net/9p/client.c > index 5531b31e0fb2..fdeeda0a811d 100644 > --- a/net/9p/client.c > +++ b/net/9p/client.c > @@ -907,8 +907,10 @@ static struct p9_fid *p9_fid_create(struct p9_client *clnt) > GFP_NOWAIT); > spin_unlock_irq(&clnt->lock); > idr_preload_end(); > - if (!ret) > + if (!ret) { > + trace_9p_fid_ref(fid, P9_FID_REF_CREATE); > return fid; > + } > > kfree(fid); > return NULL; > @@ -920,6 +922,7 @@ static void p9_fid_destroy(struct p9_fid *fid) > unsigned long flags; > > p9_debug(P9_DEBUG_FID, "fid %d\n", fid->fid); > + trace_9p_fid_ref(fid, P9_FID_REF_DESTROY); > clnt = fid->clnt; > spin_lock_irqsave(&clnt->lock, flags); > idr_remove(&clnt->fids, fid->fid); > @@ -932,6 +935,8 @@ static void p9_fid_destroy(struct p9_fid *fid) > * because trace_* functions can't be used there easily > */ > struct p9_fid *p9_fid_get(struct p9_fid *fid) { > + trace_9p_fid_ref(fid, P9_FID_REF_GET); > + > refcount_inc(&fid->count); > > return fid; > @@ -941,6 +946,8 @@ int p9_fid_put(struct p9_fid *fid) { > if (!fid || IS_ERR(fid)) > return 0; > > + trace_9p_fid_ref(fid, P9_FID_REF_PUT); > + > if (!refcount_dec_and_test(&fid->count)) > return 0; > Nothing stands out to me that would be wrong with the above. -- Steve