linux-kernel - Re: [PATCH v3 09/10] tracing/probes: Add fprobe events for tracing function entry and exit.

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: <20230329081454.05133571@rorschach.local.home>
Date:   Wed, 29 Mar 2023 08:14:54 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
Cc:     linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Florent Revest <revest@...omium.org>,
        Mark Rutland <mark.rutland@....com>,
        Will Deacon <will@...nel.org>
Subject: Re: [PATCH v3 09/10] tracing/probes: Add fprobe events for tracing
 function entry and exit.

On Thu,  2 Feb 2023 00:57:13 +0900
"Masami Hiramatsu (Google)" <mhiramat@...nel.org> wrote:

> From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
> 
> Add fprobe events for tracing function entry and exit instead of kprobe
> events. With this change, we can continue to trace function entry/exit
> even if the CONFIG_KPROBES_ON_FTRACE is not available. Since
> CONFIG_KPROBES_ON_FTRACE requires the CONFIG_DYNAMIC_FTRACE_WITH_REGS,
> it is not available if the architecture only supports
> CONFIG_DYNAMIC_FTRACE_WITH_ARGS. And that means kprobe events can not
> probe function entry/exit effectively on such architecture.
> But this can be solved if the dynamic events supports fprobe events.
> 
> The fprobe event is a new dynamic events which is only for the function
> (symbol) entry and exit. This event accepts non register fetch arguments
> so that user can trace the function arguments and return values.
> 

Hi Masami,

After applying this patch I get a bunch of these:

/work/git/linux-trace.git/kernel/trace/trace_fprobe.c:117:1: error: redefinition of ‘fetch_store_strlen_user’
  117 | fetch_store_strlen_user(unsigned long addr)
      | ^~~~~~~~~~~~~~~~~~~~~~~
In file included from /work/git/linux-trace.git/kernel/trace/trace_fprobe.c:16:
/work/git/linux-trace.git/kernel/trace/trace_probe_kernel.h:15:1: note: previous definition of ‘fetch_store_strlen_user’ with type ‘int(long unsigned int)’
   15 | fetch_store_strlen_user(unsigned long addr)
      | ^~~~~~~~~~~~~~~~~~~~~~~
/work/git/linux-trace.git/kernel/trace/trace_fprobe.c: In function ‘fetch_store_strlen_user’:
/work/git/linux-trace.git/kernel/trace/trace_fprobe.c:119:16: error: implicit declaration of function ‘kern_fetch_store_strlen_user’; did you mean ‘fetch_store_strlen_user’? [-Werror=implicit-function-declaration]
  119 |         return kern_fetch_store_strlen_user(addr);
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                fetch_store_strlen_user
/work/git/linux-trace.git/kernel/trace/trace_fprobe.c: At top level:
/work/git/linux-trace.git/kernel/trace/trace_fprobe.c:124:1: error: redefinition of ‘fetch_store_strlen’
  124 | fetch_store_strlen(unsigned long addr)
      | ^~~~~~~~~~~~~~~~~~
/work/git/linux-trace.git/kernel/trace/trace_probe_kernel.h:32:1: note: previous definition of ‘fetch_store_strlen’ with type ‘int(long unsigned int)’
   32 | fetch_store_strlen(unsigned long addr)
      | ^~~~~~~~~~~~~~~~~~
/work/git/linux-trace.git/kernel/trace/trace_fprobe.c: In function ‘fetch_store_strlen’:
/work/git/linux-trace.git/kernel/trace/trace_fprobe.c:126:16: error: implicit declaration of function ‘kern_fetch_store_strlen’; did you mean ‘fetch_store_strlen’? [-Werror=implicit-function-declaration]
  126 |         return kern_fetch_store_strlen(addr);
      |                ^~~~~~~~~~~~~~~~~~~~~~~
      |                fetch_store_strlen


Can you rebase it on the latest changes (on top of trace/for-next)?

BTW, I've applied patches 1-8 and I'm currently running them through my
tests. So if you do rebase, just send patches 9 and 10. I'm hoping to
post a for-next series later today, that will include those other
patches.

-- Steve