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: <20210529054725.GA99161@hyeyoo>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ