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: <20091124101342.GB5570@elte.hu>
Date:	Tue, 24 Nov 2009 11:13:42 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Li Zefan <lizf@...fujitsu.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jan Kiszka <jan.kiszka@....de>,
	Jiri Slaby <jirislaby@...il.com>, Avi Kivity <avi@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Mike Galbraith <efault@....de>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [GIT PULL v6] hw-breakpoints: Rewrite on top of perf events v6


* K.Prasad <prasad@...ux.vnet.ibm.com> wrote:

> On Sun, Nov 08, 2009 at 04:28:54PM +0100, Frederic Weisbecker wrote:
> > Ingo,
> > 
> > Please pull the tracing/hw-breakpoints branch that can be found at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
> > 	tracing/hw-breakpoints
> >
> 
> Hi Frederic, Ingo,
> 		Here are a few concerns (roughly in decreasing order of
> priority) about the perf-events integrated hw-breakpoint feature.
> 
> - Freeze the breakpoint interfaces: Owing to the many 
> current/potential users of hw-breakpoint feature it is important to 
> provide a stable interface to the end-user. Changes underneath the 
> interface can be done in due course in a manner that does not affect 
> the end-user's behaviour or function signature. The present breakpoint 
> interface requires parameters that are best embedded in a structure 
> for extensibility.

Well we have PERF_TYPE_BREAKPOINT right now. I agree that it should be 
finalized in some sort of extensible ABI real soon - we dont want (and 
dont need to) add all features that might be possible in the future.

> - Proposed migration of register allocation logic to arch-specific 
> files from kernel/hw_breakpoint.c. This is best done early to help 
> easy porting of code to other architectures (we have an active 
> interest in bringing support for PPC64 and S390). If done later, it 
> will entail additional effort in porting for each architecture.

I think the general direction should be towards librarized common 
frameworks.

If an architecture wants to do something special it should either extend 
the core code, or, if it's too weird to be added to the core, override 
it via its own implementation.

> - Fix ptrace bugs that potentially alter the semantics of ptrace.

Is there a specific list of these bugs?

> - Bring either true system_wide support or atleast workaround the 
> side-effects of iterative per-cpu registration using single atomic 
> enablement of all per-cpu breakpoints. This can avoid stray exceptions 
> which would get delivered to the end-user even for failed breakpoint 
> requests.

That can certainly be done when users of such facilities emerge. Right 
now we have perf and ptrace as the two users - are they affected by 
these problems?

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