linux-kernel - Re: [PATCH 2/5] ftrace: Comment __ftrace_hash_rec_update() and make filter

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]

Date: Wed, 5 Jun 2024 11:15:38 +0100
From: Mark Rutland <mark.rutland@....com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/5] ftrace: Comment __ftrace_hash_rec_update() and make
 filter_hash bool

On Tue, Jun 04, 2024 at 05:28:19PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)" <rostedt@...dmis.org>
> 
> The function __ftrace_hash_rec_update() parameter "filter_hash" is only
> used for true or false (boolean), but is of type int. It already has an
> "inc" parameter that is boolean. This is confusing, make "filter_hash"
> boolean as well.
> 
> While at it, add some documentation to that function especially since it
> holds the guts of the filtering logic of ftrace.
> 
> Signed-off-by: Steven Rostedt (Google) <rostedt@...dmis.org>
> ---
>  kernel/trace/ftrace.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 9dcdefe9d1aa..93c7c5fd4249 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -1701,8 +1701,20 @@ static bool skip_record(struct dyn_ftrace *rec)
>  		!(rec->flags & FTRACE_FL_ENABLED);
>  }
>  
> +/*
> + * This is the main engine to the ftrace updates.
> + *
> + * It will iterate through all the available ftrace functions
> + * (the ones that ftrace can have callbacks to) and set the flags
> + * to the associated dyn_ftrace records.

I beleive s/to/in/ here, to make this one of:

	set the flags in the associated dyn_ftrace records.

... rather than:

	set the flags to the associated dyn_ftrace records.

> + *
> + * @filter_hash: True if for the filter hash is udpated, false for the
> + *               notrace hash

Typo: s/udpated/updated/

... though I couldn't parse this regardless; maybe:

	@filter_hash: true to update the filter hash, false to update
		      the notrace hash

Mark.

> + * @inc: True to add this hash, false to remove it (increment the
> + *       recorder counters or decrement them).
> + */
>  static bool __ftrace_hash_rec_update(struct ftrace_ops *ops,
> -				     int filter_hash,
> +				     bool filter_hash,
>  				     bool inc)
>  {
>  	struct ftrace_hash *hash;
> -- 
> 2.43.0
> 
>