All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: "Jiri Olsa" <jolsa@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"David Ahern" <dsahern@gmail.com>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Raphaël Beamonte" <raphael.beamonte@gmail.com>
Subject: Re: [PATCH 4/5] perf tools: Propagate error info from tp_format
Date: Thu, 10 Sep 2015 11:16:28 -0300	[thread overview]
Message-ID: <20150910141628.GB23511@kernel.org> (raw)
In-Reply-To: <20150910082452.GC19014@krava.brq.redhat.com>

Em Thu, Sep 10, 2015 at 10:24:52AM +0200, Jiri Olsa escreveu:
> On Wed, Sep 09, 2015 at 05:58:13PM -0300, Arnaldo Carvalho de Melo wrote:
> 
> SNIP
> 
> > This kind of stuff is ok, as evsel is a local variable and you kept the
> > interface for perf_evsel__syscall_newtp(), i.e. it returns NULL if a new
> > evsel can't be instantiated.
> > 
> > Ok, but that is a different interface than the one used by
> > perf_evsel__newtp(), that also instantiates a new evsel.
> > 
> > So when one thinks about "foo__new()" we now need to check which one of
> > the two interfaces it uses, if err.h or if the old NULL based failure
> > reporting one.
> > 
> > Double tricky if it is foo__new() and foo__new_variant(), as
> > perf_evsel__syscall_newtp() and perf_evsel__newtp(), i.e. both will
> > return a "struct perf_evsel" instance, but one using err.h, the other
> > use NULL.
> > 
> > Ok, you marked the ones using a comment, wonder if we couldn't use
> > 'sparse' somehow here, is it used to check IS_ERR() usage in the kernel?
> 
> hum, not sure.. will check ;-)
> 
> at least we could mark related functions with __must_check
> to force the return value check

Right, that helps a bit, but not when the test _is already there_,
against NULL.

That is why I thought about sparse, if it was used in the kernel somehow
to check for this, guess either it would notice ERR_PTR using routines
and then auto-mark them for checking if they are being tested using
IS_ERR() or plain NULL, will check, later...

- Arnaldo
 
> > 
> > Ah, but what about this in trace__event_handler() in builtin-trace.c?
> >  
> >         if (evsel->tp_format) {
> >                 event_format__fprintf(evsel->tp_format, sample->cpu,
> >                                       sample->raw_data, sample->raw_size,
> >                                       trace->output);
> >         }
> > 
> > 
> > Don't we have to use IS_ERR() here? Ok, no, because if setting up
> > evsel->tp_format fails, then that evsel will be destroyed and
> > perf_evsel__newtp() will return ERR_PTR(), so it is ok not no use
> > ERR_PTR(evsel->tp_format) because it will only be != NULL when it was
> > successfully set up.
> > 
> > But then, in perf_evsel__newtp_idx if zalloc() fails we will not return
> > ERR_PTR(), but instead NULL, a-ha, this one seems to be a real bug, no?
> 
> hate those allocations in declarations.. never do any good ;-)
> 
> yep, NULL is not an error, so it's real bug, attached patch should fix it
> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index 08c20ee4e27d..162973bec713 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -256,7 +256,7 @@ struct perf_evsel *perf_evsel__newtp_idx(const char *sys, const char *name, int
>  		perf_evsel__init(evsel, &attr, idx);
>  	}
>  
> -	return evsel;
> +	return evsel ?: ERR_PTR(err);
>  
>  out_free:
>  	zfree(&evsel->name);

  reply	other threads:[~2015-09-10 14:16 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-07  8:38 [PATCHv2 0/5] perf tools: Enhance parsing events tracepoint error output Jiri Olsa
2015-09-07  8:38 ` [PATCH 1/5] tools: Add err.h with ERR_PTR PTR_ERR interface Jiri Olsa
2015-09-08 20:22   ` Raphaël Beamonte
2015-09-08 20:24     ` Raphaël Beamonte
2015-09-08 21:06     ` Arnaldo Carvalho de Melo
2015-09-08 21:28       ` Raphaël Beamonte
2015-09-08 21:29   ` Raphaël Beamonte
2015-09-16  7:28   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-09-21 23:41     ` Vinson Lee
2015-09-29  6:35       ` Vinson Lee
2015-09-29  7:14         ` Jiri Olsa
2015-09-29  7:20           ` Jiri Olsa
2015-09-29  7:52             ` He Kuang
2015-09-29  7:57               ` Jiri Olsa
2015-09-29  8:15                 ` He Kuang
2015-09-29 10:41                   ` Jiri Olsa
2015-09-29 14:52                     ` Arnaldo Carvalho de Melo
2015-09-29 15:05                       ` [PATCH] perf tool: Fix shadowed declaration in parse-events.c Jiri Olsa
2015-10-01  7:10                         ` [tip:perf/core] perf tools: " tip-bot for Jiri Olsa
2015-09-07  8:38 ` [PATCH 2/5] perf tools: Add tools/include into tags directories Jiri Olsa
2015-09-15  7:02   ` [tip:perf/core] perf tools: Add tools/ include " tip-bot for Jiri Olsa
2015-09-07  8:38 ` [PATCH 3/5] perf tools: Propagate error info for the tracepoint parsing Jiri Olsa
2015-09-08 21:42   ` Raphaël Beamonte
2015-09-09  7:50     ` Jiri Olsa
2015-09-12 10:54   ` Matt Fleming
2015-09-16  7:29   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-09-07  8:38 ` [PATCH 4/5] perf tools: Propagate error info from tp_format Jiri Olsa
2015-09-09 20:58   ` Arnaldo Carvalho de Melo
2015-09-10  8:24     ` Jiri Olsa
2015-09-10 14:16       ` Arnaldo Carvalho de Melo [this message]
2015-09-14 20:53       ` Arnaldo Carvalho de Melo
2015-09-14 20:59         ` Raphaël Beamonte
2015-09-14 21:36           ` Arnaldo Carvalho de Melo
2015-09-14 22:05             ` Raphaël Beamonte
2015-09-15  2:35               ` Arnaldo Carvalho de Melo
2015-09-14 21:02         ` Arnaldo Carvalho de Melo
2015-09-16  7:29   ` [tip:perf/core] perf evsel: " tip-bot for Jiri Olsa
2015-09-07  8:38 ` [PATCH 5/5] perf tools: Enhance parsing events tracepoint error output Jiri Olsa
2015-09-10  7:00   ` Namhyung Kim
2015-09-10  8:05     ` Jiri Olsa
2015-09-11 16:09       ` Namhyung Kim
2015-09-11 16:16         ` Jiri Olsa
2015-09-11 17:50           ` Raphaël Beamonte
2015-09-11 18:55             ` Arnaldo Carvalho de Melo
2015-09-11 19:56               ` Raphaël Beamonte
2015-09-11 20:22                 ` Arnaldo Carvalho de Melo
2015-09-11 22:01                   ` Raphaël Beamonte
2015-09-14 20:59       ` Arnaldo Carvalho de Melo
2015-09-16  7:29   ` [tip:perf/core] " tip-bot for Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150910141628.GB23511@kernel.org \
    --to=acme@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dsahern@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=raphael.beamonte@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.