linux-kernel - Re: [RFC 0/3] Basic support for LWP

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:	Tue, 5 Oct 2010 21:05:01 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Hans Rosenfeld <hans.rosenfeld@....com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	"Richter, Robert" <robert.richter@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Herrmann3, Andreas" <Andreas.Herrmann3@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [RFC 0/3] Basic support for LWP

* Hans Rosenfeld <hans.rosenfeld@....com> wrote:

> But thats not required to use LWP instructions. Maybe Robert will add 
> it to perf some day, or maybe not. It is completely optional, and how 
> it is implemented at some point in the future is completely irrelevant 
> to the basic support of LWP.

It isnt irrelevant. If the concept is implemented in a crappy way, if 
there are random user-space libraries that do not properly expose these 
capabilities and do not allow them to extend existing perf functionality 
in a natural way then we might be better off not adding overhead to the 
scheduler and not enabling it at all.

So thoughts need to be made what the point of it all is and how it 
integrates into perf. If it doesnt integrate, if the whole plan is to 
just get it to user-space where it can be messed up freely in some CPU 
specific way then color me thoroughly uninterested. We have a generic 
instrumentation framework for a reason.

We very much want to know the structure of that area and want to make 
use of it not just on a per task basis. We also want to expose it all in 
a more generalized form.

I cannot believe something like this was committed into silicon without 
at minimum talking to people who have a clue about where it will (and 
should) all go ...

	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/