[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100304110429.GC21977@elte.hu>
Date: Thu, 4 Mar 2010 12:04:29 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
linux-kernel@...r.kernel.org, paulus@...ba.org, eranian@...gle.com,
robert.richter@....com
Subject: Re: [RFC][PATCH 07/11] perf: Provide PERF_SAMPLE_REGS
* Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, 2010-03-03 at 23:02 +0100, Frederic Weisbecker wrote:
> > On Wed, Mar 03, 2010 at 05:39:43PM +0100, Peter Zijlstra wrote:
> > > Simply copy out the provided pt_regs in a u64 aligned fashion.
> > >
> > > XXX: do task_pt_regs() and get_irq_regs() always clear everything or
> > > are we now leaking data?
> >
> >
> > It looks like there is a leak in case of non trace syscalls.
> > where we don't appear to save r12-15.
> >
> > Then task_pt_regs() may leak the top of a process stack...?
>
> Right, I was afraid of that. I've put this PERF_SAMPLE_REGS thing in the
> freezer for now as people seem unsure how to deal with it.
Also, we dont want to expose PEBS nor LBR on an ABI level without there being
a user-space component making good use of it.
For example tools/perf/ support would qualify. Raw libraries alone dont really
count as they generally lag plus there's no guarantee for a full feedback loop
either.
Adding ABI details is always a tricky business and we only want to do it if
there's direct, immediate, close involvement with the user-space side, and
real, immediate benefits to users.
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