[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100410142700.GN3908@ghostprotocols.net>
Date: Sat, 10 Apr 2010 11:27:00 -0300
From: Arnaldo Carvalho de Melo <acme@...radead.org>
To: Masami Hiramatsu <mhiramat@...hat.com>
Cc: Ingo Molnar <mingo@...e.hu>, lkml <linux-kernel@...r.kernel.org>,
systemtap <systemtap@...rces.redhat.com>,
DLE <dle-develop@...ts.sourceforge.net>,
Paul Mackerras <paulus@...ba.org>,
Peter Zijlstra <peterz@...radead.org>,
Mike Galbraith <efault@....de>,
Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH -tip v2 7/8] perf probe: Remove die() from probe-finder
code
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists