linux-kernel - Re: [PATCH] tracing: remove unused ret

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200121173549.3de146d5@gandalf.local.home>
Date:   Tue, 21 Jan 2020 17:35:49 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Alex Shi <alex.shi@...ux.alibaba.com>
Cc:     Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tracing: remove unused ret

On Tue, 21 Jan 2020 13:54:43 +0800
Alex Shi <alex.shi@...ux.alibaba.com> wrote:

> No body care the variable 'ret' in function unregister_field_var_hists,
> better to remove it.
> 
> Signed-off-by: Alex Shi <alex.shi@...ux.alibaba.com>
> Cc: Steven Rostedt <rostedt@...dmis.org> 
> Cc: Ingo Molnar <mingo@...hat.com> 
> Cc: linux-kernel@...r.kernel.org 
> ---
>  kernel/trace/trace_events_hist.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
> index f62de5f43e79..0acfac95ca2a 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -5712,12 +5712,11 @@ static void unregister_field_var_hists(struct hist_trigger_data *hist_data)
>  	struct trace_event_file *file;
>  	unsigned int i;
>  	char *cmd;
> -	int ret;
>  
>  	for (i = 0; i < hist_data->n_field_var_hists; i++) {
>  		file = hist_data->field_var_hists[i]->hist_data->event_file;
>  		cmd = hist_data->field_var_hists[i]->cmd;
> -		ret = event_hist_trigger_func(&trigger_hist_cmd, file,
> +		event_hist_trigger_func(&trigger_hist_cmd, file,

I pulled in some of your other patches (removing unused macros), but
these that remove 'ret' I prefer not to take. Yes, we currently do not
use ret here, but the compiler will easily remove its existence. I'm
thinking if anything, we should report an error if they do return
something other than success.

-- Steve



>  					      "!hist", "hist", cmd);
>  	}
>  }