netdev - Re: [PATCH v10 perf, bpf-next 1/9] perf, bpf: Introduce PERF_RECORD

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: <A411D89E-0B62-4DE7-9D70-CD57672FD20A@fb.com>
Date:   Thu, 17 Jan 2019 14:49:10 +0000
From:   Song Liu <songliubraving@...com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     lkml <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        "acme@...nel.org" <acme@...nel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        Kernel Team <Kernel-team@...com>,
        "dsahern@...il.com" <dsahern@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v10 perf, bpf-next 1/9] perf, bpf: Introduce
 PERF_RECORD_KSYMBOL



> On Jan 17, 2019, at 4:56 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> 
> On Wed, Jan 16, 2019 at 08:29:23AM -0800, Song Liu wrote:
>> For better performance analysis of dynamically JITed and loaded kernel
>> functions, such as BPF programs, this patch introduces
>> PERF_RECORD_KSYMBOL, a new perf_event_type that exposes kernel symbol
>> register/unregister information to user space.
>> 
>> The following data structure is used for PERF_RECORD_KSYMBOL.
>> 
>>    /*
>>     * struct {
>>     *      struct perf_event_header        header;
>>     *      u64                             addr;
>>     *      u32                             len;
>>     *      u16                             ksym_type;
>>     *      u16                             flags;
>>     *      char                            name[];
>>     *      struct sample_id                sample_id;
>>     * };
>>     */
> 
> So I've cobbled together the attached patches to see how it would work
> out..
> 
> I didn't convert ftrace trampolines; because ftrace code has this
> uncanny ability to make my head hurt. But I don't think it should be
> hard, once one figures out the right structure to stick that
> kallsym_node thing in (ftrace_ops ?!).
> 
> It is compiled only, so no testing what so ever (also, no changelogs).
> 
> I didn't wire up the KSYM_TYPE thing; I'm wondering if we really need
> that, OTOH it really doesn't hurt having it either.
> 
> One weird thing I noticed, wth does bpf_prog_kallsyms_add() check
> CAP_ADMIN ?! Surely even a non-priv JIT'ed program generates symbols,
> why hide those?
> 
> Anyway; with the one nit about the get_names() thing sorted:
> 
> Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> 
> (thanks for sticking with this)
> <peterz-latch-next.patch><peterz-kallsym.patch><peterz-kallsym-bpf.patch>

Aha, now I get the point on perf_event_ksymbol(). Yeah this approach is 
definitely better. 

While I run more tests with these patches, could we get current in 
perf/core? This will enable the development of user space tools like
bcc. 

Also, I current base this set on bpf-next tree, as tip/perf/core is 
4 week old. Shall I rebase the set on Linus' tree? Or shall I wait for
tip/perf/core?

Thanks again!
Song