linux-kernel - Re: [PATCH] tracing: Remove redundant variable 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sat, 29 May 2021 14:47:25 +0900
From:   Hyeonggon Yoo <42.hyeyoo@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        Tom Zanussi <zanussi@...nel.org>
Subject: Re: [PATCH] tracing: Remove redundant variable ret

On Fri, May 28, 2021 at 10:22:57PM -0400, Steven Rostedt wrote:
> On Fri, 28 May 2021 02:14:49 +0900
> Hyeonggon Yoo <42.hyeyoo@...il.com> wrote:
> 
> > This variable saves return value of event_hist_trigger_func,
> > but it's never read. So it's redundant.
> > 
> > Signed-off-by: Hyeonggon Yoo <42.hyeyoo@...il.com>
> > ---
> >  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 c1abd63f1d6c..414f2727d7a7 100644
> > --- a/kernel/trace/trace_events_hist.c
> > +++ b/kernel/trace/trace_events_hist.c
> > @@ -5225,12 +5225,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,
> >  					      "!hist", "hist", cmd);
>
> I wonder if instead we should add:
>
> 		WARN_ON_ONCE(ret < 0);
>

Oh, Seems better to warn, not ignoring.