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: <20150825084828.GA21511@gmail.com>
Date:	Tue, 25 Aug 2015 10:48:28 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	adrian.hunter@...el.com,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Vince Weaver <vince@...ter.net>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH RFC v1 0/4] perf: Introduce extended syscall error
 reporting


* Alexander Shishkin <alexander.shishkin@...ux.intel.com> wrote:

> Ingo Molnar <mingo@...nel.org> writes:
> 
> > * Peter Zijlstra <peterz@...radead.org> wrote:
> >
> >> On Fri, Jul 24, 2015 at 02:45:55PM +0300, Alexander Shishkin wrote:
> >> > Hi Peter and Ingo and everybody,
> >> > 
> >> > Here's my second stab at improving perf's error reporting by attaching
> >> > arbitrary strings to the integer error codes. This is largely based
> >> > off of the previous email thread [1].
> >> > 
> >> > This time around, I employed a linker trick to convert the structures
> >> > containing extended error information into integers, which are then
> >> > made to look just like normal error codes so that IS_ERR_VALUE() and
> >> > friends would still work correctly on them. So no extra pointers in
> >> > the struct perf_event or anywhere else; the extended error codes are
> >> > passed around like normal error codes. They only need to be converted
> >> > in syscalls' topmost return statements. This is done in 1/4.
> >> > 
> >> > Then, 2/4 illustrates how error sites can be extended to include more
> >> > information such as file names and line numbers [1].
> >> > 
> >> > The other two patches add perf_err() annotation to a few semi-randomly
> >> > picked places in perf core (3/4) and x86 bits (4/4).
> >> 
> >> Looks generally ok to me. Thanks for doing this.
> >
> > I like this too.
> >
> > Alexander, mind sending a finalized, signed off version?
> 
> Sure, I have everything ready, except for what about 2/4 (using 
> CONFIG_DEBUG_KERNEL to extend output with file name and line number)? Should I 
> leave it out or can we pick a more specific kconfig option or add a new one?

I'd make it unconditional. We'll see whether we compress the debug info some more 
if the number of callsites increases dramatically. Tooling can decide whether it 
wants to display it by default, or print it only if some verbosity option is 
activated.

Also, mind structuring it in a bit more generic way that makes it possible for 
other kernel subsystems to use this facility too? I.e. add a new header for it 
instead of embedding it in perf, etc. Nothing complex, just some common-sense 
generalization for a useful looking facility.

For example the scheduler could start using it in struct sched_attr and feed back 
the 15+ of failure causes in sys_sched_setattr() / __sched_setscheduler() in a bit 
more usable fashion.

Thanks,

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