linux-kernel - Re: [PATCH -v5 15/17] ftrace: Rework event_create

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: <20191114090755.7d6d4a31@gandalf.local.home>
Date:   Thu, 14 Nov 2019 09:07:55 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, mhiramat@...nel.org,
        bristot@...hat.com, jbaron@...mai.com,
        torvalds@...ux-foundation.org, tglx@...utronix.de,
        mingo@...nel.org, namit@...are.com, hpa@...or.com, luto@...nel.org,
        ard.biesheuvel@...aro.org, jpoimboe@...hat.com, jeyu@...nel.org,
        alexei.starovoitov@...il.com
Subject: Re: [PATCH -v5 15/17] ftrace: Rework event_create_dir()

On Mon, 11 Nov 2019 14:13:07 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> Rework event_create_dir() to use an array of static data instead of
> function pointers where possible.
> 
> The problem is that it would call the function pointer on module load
> before parse_args(), possibly even before jump_labels were initialized.
> Luckily the generated functions don't use jump_labels but it still seems
> fragile. It also gets in the way of changing when we make the module map
> executable.
> 
> The generated function are basically calling trace_define_field() with a
> bunch of static arguments. So instead of a function, capture these
> arguments in a static array, avoiding the function call.
> 
> Now there are a number of cases where the fields are dynamic (syscall
> arguments, kprobes and uprobes), in which case a static array does not
> work, for these we preserve the function call. Luckily all these cases
> are not related to modules and so we can retain the function call for
> them.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> Cc: Steven Rostedt <rostedt@...dmis.org>

Reviewed-by: Steven Rostedt (VMware) <rostedt@...dmis.org>

-- Steve

> ---
>  drivers/infiniband/hw/hfi1/trace_tid.h  |    8 +-
>  drivers/infiniband/hw/hfi1/trace_tx.h   |    2 
>  drivers/lightnvm/pblk-trace.h           |    8 +-
>  drivers/net/fjes/fjes_trace.h           |    2 
>  drivers/net/wireless/ath/ath10k/trace.h |    6 -
>  fs/xfs/scrub/trace.h                    |    6 -
>  fs/xfs/xfs_trace.h                      |    4 -
>  include/linux/trace_events.h            |   18 +++++
>  include/trace/events/filemap.h          |    2 
>  include/trace/events/rpcrdma.h          |    2 
>  include/trace/trace_events.h            |   64 ++++++-------------
>  kernel/trace/trace.h                    |   31 ++++-----
>  kernel/trace/trace_entries.h            |   66 +++++--------------
>  kernel/trace/trace_events.c             |   20 +++++-
>  kernel/trace/trace_events_hist.c        |    8 ++
>  kernel/trace/trace_export.c             |  106 +++++++++++---------------------
>  kernel/trace/trace_kprobe.c             |   16 ++++
>  kernel/trace/trace_syscalls.c           |   50 ++++++---------
>  kernel/trace/trace_uprobe.c             |    9 ++
>  net/mac80211/trace.h                    |   28 ++++----
>  net/wireless/trace.h                    |    6 -
>  21 files changed, 213 insertions(+), 249 deletions(-)
> 
>