linux-kernel - Re: [PATCH 1/3] perf: add context field to perf

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: <20110629162725.GH15521@e102144-lin.cambridge.arm.com>
Date:	Wed, 29 Jun 2011 17:27:25 +0100
From:	Will Deacon <will.deacon@....com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Avi Kivity <avi@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
	"acme@...stprotocols.net" <acme@...stprotocols.net>,
	Jason Wessel <jason.wessel@...driver.com>
Subject: Re: [PATCH 1/3] perf: add context field to perf_event

Hi Frederic,

Thanks for including me on CC.

On Wed, Jun 29, 2011 at 05:08:45PM +0100, Frederic Weisbecker wrote:
> On Wed, Jun 29, 2011 at 06:42:35PM +0300, Avi Kivity wrote:
> > The perf_event overflow handler does not receive any caller-derived
> > argument, so many callers need to resort to looking up the perf_event
> > in their local data structure.  This is ugly and doesn't scale if a
> > single callback services many perf_events.
> >
> > Fix by adding a context parameter to perf_event_create_kernel_counter()
> > (and derived hardware breakpoints APIs) and storing it in the perf_event.
> > The field can be accessed from the callback as event->overflow_handler_context.
> > All callers are updated.
> >
> > Signed-off-by: Avi Kivity <avi@...hat.com>
> 
> I believe it can micro-optimize ptrace through register_user_hw_breakpoint() because
> we could store the index of the breakpoint that way, instead of iterating through 4 slots.
> 
> Perhaps it can help in arm too, adding Will in Cc.

Yes, we could store the breakpoint index in there and it would save us
walking over the breakpoints when one fires. Not sure this helps us for
anything else though. My main gripe with the ptrace interface to
hw_breakpoints is that we have to convert all the breakpoint information
from ARM_BREAKPOINT_* to HW_BREAKPOINT_* and then convert it all back again
in the hw_breakpoint code. Yuck!

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