linux-kernel - Re: [PATCH -tip 5/7] perf probe: Query basic types from debuginfo

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: <20100329205143.GQ3625@ghostprotocols.net>
Date:	Mon, 29 Mar 2010 17:51:43 -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 5/7] perf probe: Query basic types from debuginfo

Em Mon, Mar 29, 2010 at 04:38:29PM -0400, Masami Hiramatsu escreveu:
> +static void convert_variable_type(Dwarf_Die *vr_die,
> +				  struct kprobe_trace_arg *targ)
> +{
> +	Dwarf_Die type;
> +	char buf[16];
> +	int ret;
> +
> +	if (die_get_real_type(vr_die, &type) == NULL)
> +		die("Failed to get a type information of %s.",
> +		    dwarf_diename(vr_die));
> +
> +	ret = die_get_byte_size(&type) * 8;
> +	if (ret) {
> +		/* Check the bitwidth */
> +		if (ret > MAX_BASIC_TYPE_BITS) {
> +			pr_warning("  Warning: %s exceeds max-bitwidth."
> +				   " Cut down to %d bits.\n",
> +				   dwarf_diename(&type), MAX_BASIC_TYPE_BITS);
> +			ret = MAX_BASIC_TYPE_BITS;
> +		}
> +
> +		ret = snprintf(buf, 16, "%c%d",
> +			       die_is_signed_type(&type) ? 's' : 'u', ret);
> +		if (ret < 0 || ret >= 16)
> +			die("Failed to convert variable type.");
> +		targ->type = xstrdup(buf);

Question, should we use the equivalent to panic'ing the kernel in the
userspace bits in tools/?

I tend to see all code there as potentially part of a library, i.e. to
be callable by some unantecipated new tool or library that would rather
receive a return value telling it that the operation can't be performed
for some reason so that it can inform the user instead of having the
whole tool exit to the command line.

It may well be that some specific operation needs lots of resources but
many other don't, panic'c because the one that requires lots of
resources can't be performed, bringing down a gui/tui is really nasty.

Perhaps the answer will be the same as for when people added panic calls
in the kernel in the past, "you're screwed up anyway if that happens",
but it just feels wrong :-\

In the DWARF bits it has even the added twist namespace collapse with
DIE 8-)

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