linux-kernel - [Question] Are the trace APIs declared by "TRACE_EVENT(irq_handler

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-next>] [day] [month] [year] [list]

Message-ID: <5B987525.9070300@huawei.com>
Date:   Wed, 12 Sep 2018 10:08:37 +0800
From:   "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
To:     Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:     Kunxun Xie <xiekunxun@...wei.com>
Subject: [Question] Are the trace APIs declared by
 "TRACE_EVENT(irq_handler_entry" allowed to be used in Ko?

After patch 7e066fb870fc ("tracepoints: add DECLARE_TRACE() and DEFINE_TRACE()"),
the trace APIs declared by "TRACE_EVENT(irq_handler_entry" can not be directly used
by ko, because it's not explicitly exported by EXPORT_TRACEPOINT_SYMBOL_GPL or
EXPORT_TRACEPOINT_SYMBOL.

Did we miss it? or it's not recommended to be used in ko?


-------------

commit 7e066fb870fcd1025ec3ba7bbde5d541094f4ce1
Author: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Date:   Fri Nov 14 17:47:47 2008 -0500

    tracepoints: add DECLARE_TRACE() and DEFINE_TRACE()

    Impact: API *CHANGE*. Must update all tracepoint users.

    Add DEFINE_TRACE() to tracepoints to let them declare the tracepoint
    structure in a single spot for all the kernel. It helps reducing memory
    consumption, especially when declaring a lot of tracepoints, e.g. for
    kmalloc tracing.

    *API CHANGE WARNING*: now, DECLARE_TRACE() must be used in headers for
    tracepoint declarations rather than DEFINE_TRACE(). This is the sane way
    to do it. The name previously used was misleading.

    Updates scheduler instrumentation to follow this API change.


-- 
Thanks!
BestRegards