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, 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ