linux-kernel - Re: [PATCH v11 02/11] 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: <20230608165234.0c00c146@gandalf.local.home>
Date:   Thu, 8 Jun 2023 16:52:34 -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>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Martin KaFai Lau <martin.lau@...ux.dev>, bpf@...r.kernel.org
Subject: Re: [PATCH v11 02/11] tracing/probes: Add fprobe events for tracing
 function entry and exit.

On Wed, 17 May 2023 19:59:04 +0900
"Masami Hiramatsu (Google)" <mhiramat@...nel.org> wrote:

> 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.
> 
> The fprobe events syntax is here;
> 
>  f[:[GRP/][EVENT]] FUNCTION [FETCHARGS]
>  f[MAXACTIVE][:[GRP/][EVENT]] FUNCTION%return [FETCHARGS]

I finally got around to look at these (I know you already queued them), but
looking at the above, the "%return" is redundant.

> 
> E.g.
> 
>  # echo 'f vfs_read $arg1'  >> dynamic_events
>  # echo 'f vfs_read%return $retval'  >> dynamic_events
>  # cat dynamic_events
>  f:fprobes/vfs_read__entry vfs_read arg1=$arg1
>  f:fprobes/vfs_read__exit vfs_read%return arg1=$retval

Can't we just have:

  f:fprobes/vfs_read__entry vfs_read arg1=$arg1
  f:fprobes/vfs_read__exit vfs_read arg1=$retval

Where if "$retval" is specified, it automatically becomes a return? If
anything else is specified, it errors out. That is, if $retval is
specified, it becomes a return probe, as a return probe can only have
$retval. If anything else is specified, it errors out if $retval is also
specified.

Now if it's a void function, and you just want to make it a return then we
can have your:

  f:fprobes/vfs_read__exit vfs_read%return

Thoughts?

-- Steve