linux-kernel - Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the uprobe cmd string

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170124082225.GC8667@gmail.com>
Date:   Tue, 24 Jan 2017 09:22:25 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com>
Cc:     Alexis Berlemont <alexis.berlemont@...il.com>,
        linux-kernel@...r.kernel.org, peterz@...radead.org,
        mingo@...hat.com, acme@...nel.org,
        alexander.shishkin@...ux.intel.com, Jiri Olsa <jolsa@...hat.com>
Subject: Re: [PATCH v5 0/2] perf probe: add sdt probes arguments into the
 uprobe cmd string


* Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com> wrote:

> 
> 
> On Wednesday 14 December 2016 01:06 PM, Ingo Molnar wrote:
> > * Alexis Berlemont <alexis.berlemont@...il.com> wrote:
> >
> >> Hi Masami,
> >>
> >> Many thanks for your mail.
> >>
> >> Here is another patch set which tries to fix the points you mentioned:
> >>
> >> * Skip the arguments containing a constant ($123); 
> >> * Review the code in charge of the register renaming (search for '%'
> >>   and parse it);
> >> * Minor changes (print the argument in case of error, skipping, check
> >>   the sdt arg type index);
> >>
> >> Many thanks,
> >>
> >> Alexis.
> >>
> >> Alexis Berlemont (2):
> >>   perf sdt: add scanning of sdt probles arguments
> >>   perf probe: add sdt probes arguments into the uprobe cmd string
> > I'd like to hijack this thread to report an SDT oddity - one of my boxen reports 
> > lots of SDT tracepoints in 'perf list':
> >
> >   mem:<addr>[/len][:access]                          [Hardware breakpoint]
> >
> >   sdt_libc:lll_lock_wait_private                     [SDT event]
> >   sdt_libc:longjmp                                   [SDT event]
> >   sdt_libc:longjmp_target                            [SDT event]
> >   sdt_libc:memory_arena_new                          [SDT event]
> >   sdt_libc:memory_arena_retry                        [SDT event]
> >   sdt_libc:memory_arena_reuse                        [SDT event]
> >   sdt_libc:memory_arena_reuse_free_list              [SDT event]
> >   sdt_libc:memory_arena_reuse_wait                   [SDT event]
> >   sdt_libc:memory_calloc_retry                       [SDT event]
> >   sdt_libc:memory_heap_free                          [SDT event]
> >   ...
> >
> > But none of them work:
> >
> >   Error:  No permissions to read /sys/kernel/debug/tracing/events/sdt_libc/longjmp
> >   Hint:   Try 'sudo mount -o remount,mode=755 /sys/kernel/debug/tracing'
> >
> >   ...
> >
> >   Error:  File /sys/kernel/debug/tracing/events/sdt_libc/longjmp not found.
> >   Hint:   Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
> >
> > What kind of patches are required for SDT probes to work?
> 
> Hi Ingo,
> 
> I suppose you are trying to record SDT events without probing it.
> In that case, first put a probe on an event and then try to record
> it. For example,


Well, I was mainly complaining about the misleading messages and flow of the 
tooling here. Could you please improve the messages so that if I use it like the 
way I reported it results in me trying the right approach?

Thanks,

	Ingo