linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH 3/4] SUNRPC: Replace dprintk() call site in xs_data_ready
       [not found]     ` <9FDA46D8-4D6E-49B0-A583-D0FF739111BF@oracle.com>
@ 2022-07-22 20:22       ` Steven Rostedt
  2022-07-25 15:49         ` Arnaldo Carvalho de Melo
  0 siblings, 1 reply; 3+ messages in thread
From: Steven Rostedt @ 2022-07-22 20:22 UTC (permalink / raw)
  To: Chuck Lever III
  Cc: Trond Myklebust, Anna Schumaker, Linux NFS Mailing List, LKML,
	Arnaldo Carvalho de Melo, Ingo Molnar, Jiri Olsa, Namhyung Kim,
	linux-perf-users

[ Added the user space perf folks ]

On Fri, 22 Jul 2022 18:45:30 +0000
Chuck Lever III <chuck.lever@oracle.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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 3/4] SUNRPC: Replace dprintk() call site in xs_data_ready
  2022-07-22 20:22       ` [PATCH 3/4] SUNRPC: Replace dprintk() call site in xs_data_ready Steven Rostedt
@ 2022-07-25 15:49         ` Arnaldo Carvalho de Melo
  2022-07-25 16:06           ` Steven Rostedt
  0 siblings, 1 reply; 3+ messages in thread
From: Arnaldo Carvalho de Melo @ 2022-07-25 15:49 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Chuck Lever III, Trond Myklebust, Anna Schumaker,
	Linux NFS Mailing List, LKML, Ingo Molnar, Jiri Olsa,
	Namhyung Kim, linux-perf-users

Em Fri, Jul 22, 2022 at 04:22:12PM -0400, Steven Rostedt escreveu:
> [ Added the user space perf folks ]
> 
> On Fri, 22 Jul 2022 18:45:30 +0000
> Chuck Lever III <chuck.lever@oracle.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

To use it one has to use:

  make -C tools/perf LIBTRACEEVENT_DYNAMIC=1

Then we get it linked with libtraceevent-devel:

$ ldd ~/bin/perf | grep traceevent
	libtraceevent.so.1 => /lib64/libtraceevent.so.1 (0x00007faa50f93000)
$

Perhaps it'd be better to check if libtracevent-devel is installed and
use it, falling back to tools/lib/traceevent/ and then adding a warning
that the in-tree codebase is being used?

- Arnaldo

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 3/4] SUNRPC: Replace dprintk() call site in xs_data_ready
  2022-07-25 15:49         ` Arnaldo Carvalho de Melo
@ 2022-07-25 16:06           ` Steven Rostedt
  0 siblings, 0 replies; 3+ messages in thread
From: Steven Rostedt @ 2022-07-25 16:06 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo
  Cc: Chuck Lever III, Trond Myklebust, Anna Schumaker,
	Linux NFS Mailing List, LKML, Ingo Molnar, Jiri Olsa,
	Namhyung Kim, linux-perf-users

On Mon, 25 Jul 2022 12:49:20 -0300
Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Perhaps it'd be better to check if libtracevent-devel is installed and
> use it, falling back to tools/lib/traceevent/ and then adding a warning
> that the in-tree codebase is being used?

Yeah, this is the way trace-cmd went. For a few releases, it would just
warn that it couldn't find the system libraries, and then fall back to the
internals, and then it finally just removed the internals and failed with a
message stating where to get the necessary libraries.

-- Steve

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-07-25 16:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <165851065336.361126.17865870911497306083.stgit@morisot.1015granger.net>
     [not found] ` <165851074247.361126.17205394769981595871.stgit@morisot.1015granger.net>
     [not found]   ` <66371b9db4210fe853e98a8ec68b0f780ba886af.camel@hammerspace.com>
     [not found]     ` <9FDA46D8-4D6E-49B0-A583-D0FF739111BF@oracle.com>
2022-07-22 20:22       ` [PATCH 3/4] SUNRPC: Replace dprintk() call site in xs_data_ready Steven Rostedt
2022-07-25 15:49         ` Arnaldo Carvalho de Melo
2022-07-25 16:06           ` Steven Rostedt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).