[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220722162212.3d080c23@gandalf.local.home>
Date: Fri, 22 Jul 2022 16:22:12 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Chuck Lever III <chuck.lever@...cle.com>
Cc: Trond Myklebust <trondmy@...merspace.com>,
Anna Schumaker <anna.schumaker@...app.com>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 3/4] SUNRPC: Replace dprintk() call site in
xs_data_ready
[ Added the user space perf folks ]
On Fri, 22 Jul 2022 18:45:30 +0000
Chuck Lever III <chuck.lever@...cle.com> wrote:
> >> +TRACE_EVENT(xs_data_ready,
> >> + TP_PROTO(
> >> + const struct rpc_xprt *xprt
> >> + ),
> >> +
> >> + TP_ARGS(xprt),
> >> +
> >> + TP_STRUCT__entry(
> >> + __sockaddr(addr, xprt->addrlen)
> >> + ),
> >> +
> >> + TP_fast_assign(
> >> + __assign_sockaddr(addr, &xprt->addr, xprt->addrlen);
> >> + ),
> >> +
> >> + TP_printk("peer=%pISpc", __get_sockaddr(addr))
> >
> > NACK. Please resolve and store the string up front instead of storing
> > the sockaddr. Most versions of perf can't resolve those kernel-specific
> > %p printks and just end up barfing on them.
>
> Interesting. We added get_sockaddr() to avoid this issue in
> trace-cmd. Sounds like perf needs to be fixed up too, or
> maybe this is another case of having an old libtraceevent?
>
> Meanwhile, I can revert this back to the old way of handling
> presentation addresses.
>
Hmm, I thought that perf now uses the external libtraceevent.
Perhaps it hasn't been updated to the latest release that has the ability
to parse this.
Maybe just install
git://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git
?
-- Steve
Powered by blists - more mailing lists