public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@infradead.org>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>, lkml <linux-kernel@vger.kernel.org>,
	systemtap <systemtap@sources.redhat.com>,
	DLE <dle-develop@lists.sourceforge.net>,
	Paul Mackerras <paulus@samba.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Mike Galbraith <efault@gmx.de>,
	Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH -tip v2 7/8] perf probe: Remove die() from probe-finder code
Date: Sat, 10 Apr 2010 11:27:00 -0300	[thread overview]
Message-ID: <20100410142700.GN3908@ghostprotocols.net> (raw)
In-Reply-To: <4BBFFC86.4020201@redhat.com>

Em Sat, Apr 10, 2010 at 12:20:22AM -0400, Masami Hiramatsu escreveu:
> Arnaldo Carvalho de Melo wrote:
> > Em Fri, Apr 09, 2010 at 07:18:38PM -0400, Masami Hiramatsu escreveu:
> >> Hi Arnaldo,
> >>
> >> Has this code done what you suggested? :)
> >> I'd like to have your comment.
> > 
> > It improves the current situation, yes, but there are still cases there
> > where die() is called, I assume that is left for later, right?
> 
> With the next (8/8) patch, all die()s are removed at least from 
> probe-{event,finder}.c, except for all x*() wrappers.

Ok
 
> > 
> > Like here, the TUI/GUI can try to add a probe but if it fails it can
> > still continue providing things like a "perf top" window, analysing
> > perf.data files, doing 'perf diffs', etc.
> 
> Sure, this die() is removed by next (8/8) patch. Sorry, I've split it because
> of easy to review...

Ok
 
> >>>  	tvar->value = xstrdup(regs);
> >>>  	if (ref) {
> >>>  		tvar->ref = xzalloc(sizeof(struct kprobe_trace_arg_ref));
> > 
> > We have to kill those xzcalloc, etc, too they are die() in disguise :-)
> 
> Hmm, I think that will cost high, because only failing to allocate memory,
> which theoretically means we can't continue to operate it. In that case,
> we'd better just use backtrace() and die().

Consider a situation where we are trying to allocate lots of objects
allocated for some big operation (adding probes for all functions in all
threads, whatever), we can just say to the user "hey, you don't have
memory to do this" but other operations are possible, so calling
panic(), oops, die() is not the right thing to do.

- Arnaldo

  reply	other threads:[~2010-04-10 15:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-06 22:05 [PATCH -tip v2 0/8] perf-probe updates - data-structure support improvements, etc Masami Hiramatsu
2010-04-06 22:05 ` [PATCH -tip v2 1/8] perf probe: Support argument name Masami Hiramatsu
2010-04-06 22:05 ` [PATCH -tip v2 2/8] perf probe: Use the last field name as the " Masami Hiramatsu
2010-04-06 22:06 ` [PATCH -tip v2 3/8] tracing/kprobes: Support basic types on dynamic events Masami Hiramatsu
2010-04-06 22:06 ` [PATCH -tip v2 4/8] perf probe: Query basic types from debuginfo Masami Hiramatsu
2010-04-06 22:06 ` [PATCH -tip v2 5/8] perf probe: Support basic type casting Masami Hiramatsu
2010-04-06 22:06 ` [PATCH -tip v2 6/8] perf probe: Support DW_OP_call_frame_cfa in debuginfo Masami Hiramatsu
2010-04-06 22:06 ` [PATCH -tip v2 7/8] perf probe: Remove die() from probe-finder code Masami Hiramatsu
2010-04-09 23:18   ` Masami Hiramatsu
2010-04-10  1:28     ` Arnaldo Carvalho de Melo
2010-04-10  4:20       ` Masami Hiramatsu
2010-04-10 14:27         ` Arnaldo Carvalho de Melo [this message]
2010-04-10 16:48           ` Masami Hiramatsu
2010-04-10 18:10             ` Arnaldo Carvalho de Melo
2010-04-06 22:06 ` [PATCH -tip v2 8/8] perf probe: Remove die() from probe-event code Masami Hiramatsu

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=20100410142700.GN3908@ghostprotocols.net \
    --to=acme@infradead.org \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=efault@gmx.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=systemtap@sources.redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox