linux-kernel - Re: [RFD] perf syscall error handling

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: <alpine.DEB.2.10.1411010130170.6256@pianoman.cluster.toy>
Date:	Sat, 1 Nov 2014 01:30:39 -0400 (EDT)
From:	Vince Weaver <vince@...ter.net>
To:	Stephane Eranian <eranian@...gle.com>
cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFD] perf syscall error handling

On Fri, 31 Oct 2014, Stephane Eranian wrote:

> On Fri, Oct 31, 2014 at 1:28 PM, Matt Fleming <matt@...sole-pimps.org> wrote:
> >
> > I guess we'd run into a problem if userspace doesn't want to just print
> > the kernel string but instead wants to parse it in some fashion.

If the string interface went in it would be a help when debugging 
perf_event_open().

Support would probably get added to PAPI, but PAPI has its own error 
reporting issues and it's not always easy to pass a string the whole way 
back to the user.

Also with PAPI many of the users reporting obscure perf_event_open() 
problems are often running 2.6.32-vendor-patched kernels, so sadly it will 
be years before any improved error handling filters down to many of the 
users.

This proposal also doesn't help with other weird failure modes in the 
interface, the most annoying of which is the watchdog stealing a counter 
so event groups perf_event_open() and start just fine but fail at read 
time.

> > That may or may not be a problem in practice, Vince can probably comment
> > on that. I'm just thinking along the lines of making the perf syscall
> > interface as useful as possible for tools other than tools/perf.
> >
> Maybe I missed something in the earlier thread, but I am trying to understand
> why perf_event_open() would need such extended error retrieval system when
> no other syscall does.

well perf_event_open() is so complex, with it's 40+ different parameters.  
Having a wrong value in any one of those (or one of the combinations of 
those) can trigger EINVAL and it's not clear where the issue is.  
I think other system calls tend to have slighly more straightforward 
interfaces.

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