linux-kernel - Re: [PATCH 3/3 v2] perf tool: give user better message if precise is not supported

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: <20120914201138.GA17024@gmail.com>
Date:	Fri, 14 Sep 2012 22:11:38 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	David Ahern <dsahern@...il.com>, linux-kernel@...r.kernel.org,
	Robert Richter <robert.richter@....com>
Subject: Re: [PATCH 3/3 v2] perf tool: give user better message if precise is
 not supported


* Ingo Molnar <mingo@...nel.org> wrote:

> * Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > On Fri, 2012-09-14 at 11:00 -0700, Arnaldo Carvalho de Melo wrote:
> > > > Understood and there have been suggestions on how to definitely state
> > > > what the kernel side did not like. I like Peter's last suggestion --
> > > > something along the lines of clearing attr on a failure except the
> > > > offending setting.
> > > 
> > > I think ws need to use a new bit 
> > 
> > Quite so, for all the reasons you list. But you like the 
> > general idea? I wasn't sure I did, but it was the only thing I 
> > could come up with that would sort of do what we need it to.
> > 
> > The fact that you destroy the user input is awkward, I don't 
> > think there's another syscall that behaves in this fashion.
> 
> Destroying/clearing stuff looks really hacky.
> 
> Why not use a single error status field, set via a long list 
> of enum error constants, a 'perf errnos'?
> 
> The only real problem with the kernel's syscall error code is 
> that it's not wide enough for historic reasons, so we cannot 
> just create our own errnos. But we can create our errors in 
> the attr just fine and make them finegrained enough so that 
> tooling can figure out what happened exactly when it gets a 
> syscall error.
> 
> Yes, that's old-fashioned technology, but it works. With time 
> we could put some structure into the list of error IDs, to 
> make it easily extensible yet grouped in some fashion, etc.

And we could start this small: just covering the problem at hand 
or so, with proper tooling side support - and then extend it as 
needed. I.e. have something in place that we could ask people 
adding new kernel side error paths to use - and with time old 
code could be enriched with better error codes as well.

perf could in fact internally standardize on a 32-bit wide error 
code, and translate it to -EINVAL at the syscall return level. 
That way we could keep all the simple error paths as they are 
today, with a very little syscall level logic (triggered in 
error cases only, so no overhead in the regular case).

I.e.:

  return -EPERF_CPU_PRECISE_EV_NOTSUPP;

would result in that error code being available to new, improved 
tooling that knows about the new attr field. Old tooling would 
still work as well, it would only see the -EINVAL of the 
syscall.

Or something like this - simple and using existing patterns and 
practices. Anything else will likely fail due to non-use.

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/