On Tue, Jul 25, 2017 at 10:58 AM, Josh Poimboeuf wrote:
> [ Adding Kees to CC for the hardened usercopy discussion. ]
>
> Kees, FYI: frame pointers may be disabled by default on x86 relatively
> soon (presumably weeks or months) in favor of the ORC unwinder. So the
> hardened usercopy stack walk
[ Adding Kees to CC for the hardened usercopy discussion. ]
Kees, FYI: frame pointers may be disabled by default on x86 relatively
soon (presumably weeks or months) in favor of the ORC unwinder. So the
hardened usercopy stack walk will no longer work as advertised.
Using the ORC unwinder for har
* Josh Poimboeuf wrote:
> On Wed, Jul 12, 2017 at 09:27:50PM +0200, Ingo Molnar wrote:
> > Maybe we could offer a menu of unwinders - i.e. make the whole Kconfig
> > interface a
> > bit nicer:
> >
> > CONFIG_UNWINDER_FRAME_POINTER
> > CONFIG_UNWINDER_ORC
> > CONFIG_UNWINDER_GUESS
> >
>
On Wed, Jul 12, 2017 at 09:27:50PM +0200, Ingo Molnar wrote:
> Maybe we could offer a menu of unwinders - i.e. make the whole Kconfig
> interface a
> bit nicer:
>
> CONFIG_UNWINDER_FRAME_POINTER
> CONFIG_UNWINDER_ORC
> CONFIG_UNWINDER_GUESS
>
> ... or so?
So far I haven't been able to fi
* Josh Poimboeuf wrote:
> > > The results wouldn't be 100% accurate, but they could end up being useful
> > > over time.
> >
> > And to expound further on the bad idea, maybe the "bad" addresses could be
> > filtered out somehow in post-processing (insert lots of hand waving).
>
> And some d
* Josh Poimboeuf wrote:
> For user space stack unwinding, the kernel could emulate what the kernel
> 'guess' unwinder does by scanning the user space stack and returning all
> the text addresses it finds.
User-space stacks tend to be much larger than kernel stacks, the cost of doing
such a ful
On Wed, Jul 12, 2017 at 09:29:17PM -0700, Andi Kleen wrote:
> On Wed, Jul 12, 2017 at 05:47:59PM -0500, Josh Poimboeuf wrote:
> > On Wed, Jul 12, 2017 at 03:30:31PM -0700, Andi Kleen wrote:
> > > Josh Poimboeuf writes:
> > > >
> > > > The ORC data format does have a few downsides compared to DWARF
On Thu, Jul 13, 2017 at 07:21:15AM -0500, Josh Poimboeuf wrote:
> On Thu, Jul 13, 2017 at 07:17:55AM -0500, Josh Poimboeuf wrote:
> > BTW, while we're throwing out ideas for this, here's another idea,
> > though it's almost certainly not a good one :-)
> >
> > For user space stack unwinding, the k
On Thu, Jul 13, 2017 at 07:17:55AM -0500, Josh Poimboeuf wrote:
> BTW, while we're throwing out ideas for this, here's another idea,
> though it's almost certainly not a good one :-)
>
> For user space stack unwinding, the kernel could emulate what the kernel
> 'guess' unwinder does by scanning th
On Thu, Jul 13, 2017 at 11:19:11AM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > > One gloriously ugly hack would be to delay the userspace unwind to
> > > return-to-userspace, at which point we have a schedulable context and can
> > > take
> > > faults.
>
> I don't think it's
On Wed, 12 Jul 2017, Andi Kleen wrote:
> It's somewhat surprising. It would be good to under stand why that
> happens. Is it icache misses, data cache misses for the stack, or simply
> more instructions executed, or worse tail calls?
http://lkml.kernel.org/r/20170602104048.jkkzssljsompj...@suse
* Josh Poimboeuf wrote:
> On Wed, Jul 12, 2017 at 03:30:31PM -0700, Andi Kleen wrote:
> > Josh Poimboeuf writes:
> > >
> > > The ORC data format does have a few downsides compared to DWARF. The
> > > ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables.
> > >
> > Can we have a
* Peter Zijlstra wrote:
> > One gloriously ugly hack would be to delay the userspace unwind to
> > return-to-userspace, at which point we have a schedulable context and can
> > take
> > faults.
I don't think it's ugly, and it has various advantages:
> > Of course, then you have to somehow i
On Thu, Jul 13, 2017 at 10:50:15AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 13, 2017 at 09:12:53AM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 12, 2017 at 05:32:25PM -0500, Josh Poimboeuf wrote:
> > > If you want perf to be able to use ORC instead of DWARF for user space
> > > binaries, that's n
On Thu, Jul 13, 2017 at 09:12:53AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 12, 2017 at 05:32:25PM -0500, Josh Poimboeuf wrote:
> > If you want perf to be able to use ORC instead of DWARF for user space
> > binaries, that's not currently possible, though I don't see any
> > technical blockers for
On Wed, Jul 12, 2017 at 05:32:25PM -0500, Josh Poimboeuf wrote:
> If you want perf to be able to use ORC instead of DWARF for user space
> binaries, that's not currently possible, though I don't see any
> technical blockers for doing so. Perf would need to be taught to read
> ORC data.
So the pro
On Wed, 2017-07-12 at 21:40 -0700, Andi Kleen wrote:
> On Thu, Jul 13, 2017 at 06:28:43AM +0200, Mike Galbraith wrote:
> > On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote:
> > > On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote:
> > > > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen
On Thu, Jul 13, 2017 at 06:28:43AM +0200, Mike Galbraith wrote:
> On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote:
> > On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote:
> > > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote:
> > > > Josh Poimboeuf writes:
> > > > >
> > > > > T
On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote:
> On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote:
> > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote:
> > > Josh Poimboeuf writes:
> > > >
> > > > The ORC data format does have a few downsides compared to DWARF. The
> > > >
On Wed, Jul 12, 2017 at 05:47:59PM -0500, Josh Poimboeuf wrote:
> On Wed, Jul 12, 2017 at 03:30:31PM -0700, Andi Kleen wrote:
> > Josh Poimboeuf writes:
> > >
> > > The ORC data format does have a few downsides compared to DWARF. The
> > > ORC unwind tables take up ~1MB more memory than DWARF eh_
On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote:
> On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote:
> > Josh Poimboeuf writes:
> > >
> > > The ORC data format does have a few downsides compared to DWARF. The
> > > ORC unwind tables take up ~1MB more memory than DWARF eh_frame t
On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote:
> Josh Poimboeuf writes:
> >
> > The ORC data format does have a few downsides compared to DWARF. The
> > ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables.
> >
> Can we have an option to just use dwarf instead? For people
>
On Wed, Jul 12, 2017 at 3:30 PM, Andi Kleen wrote:
> Josh Poimboeuf writes:
>>
>> The ORC data format does have a few downsides compared to DWARF. The
>> ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables.
>>
> Can we have an option to just use dwarf instead? For people
> who
On 2017-07-12 17:40:45 -0500, Josh Poimboeuf wrote:
> On Wed, Jul 12, 2017 at 03:36:05PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2017-07-12 17:32:25 -0500, Josh Poimboeuf wrote:
> > > If you want perf to be able to use ORC instead of DWARF for user space
> > > binaries, that's not currently
On Wed, Jul 12, 2017 at 03:30:31PM -0700, Andi Kleen wrote:
> Josh Poimboeuf writes:
> >
> > The ORC data format does have a few downsides compared to DWARF. The
> > ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables.
> >
> Can we have an option to just use dwarf instead? For p
On Wed, Jul 12, 2017 at 03:36:05PM -0700, Andres Freund wrote:
> Hi,
>
> On 2017-07-12 17:32:25 -0500, Josh Poimboeuf wrote:
> > If you want perf to be able to use ORC instead of DWARF for user space
> > binaries, that's not currently possible, though I don't see any
> > technical blockers for doi
Hi,
On 2017-07-12 17:32:25 -0500, Josh Poimboeuf wrote:
> If you want perf to be able to use ORC instead of DWARF for user space
> binaries, that's not currently possible, though I don't see any
> technical blockers for doing so. Perf would need to be taught to read
> ORC data.
Right, that's wha
On Wed, Jul 12, 2017 at 02:49:20PM -0700, Andres Freund wrote:
> Hi,
>
> On 2017-07-11 10:33:37 -0500, Josh Poimboeuf wrote:
> > The simpler debuginfo format also enables the unwinder to be much faster
> > than DWARF, which is important for perf and lockdep.
>
> Is this going to be usable for use
Josh Poimboeuf writes:
>
> The ORC data format does have a few downsides compared to DWARF. The
> ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables.
>
Can we have an option to just use dwarf instead? For people
who don't want to waste a MB+ to solve a problem that doesn't
exis
Hi,
On 2017-07-11 10:33:37 -0500, Josh Poimboeuf wrote:
> The simpler debuginfo format also enables the unwinder to be much faster
> than DWARF, which is important for perf and lockdep.
Is this going to be usable for userland call-graphs as well? If one
converts dwarf to that, I mean? Because rig
* Josh Poimboeuf wrote:
> On Wed, Jul 12, 2017 at 10:27:10AM +0200, Ingo Molnar wrote:
> > > Create a new "ORC" unwinder, enabled by CONFIG_ORC_UNWINDER, and plug it
> > > into the x86 unwinder framework. Objtool is used to generate the ORC
> > > debuginfo. The ORC debuginfo format is basicall
On Wed, Jul 12, 2017 at 10:27:10AM +0200, Ingo Molnar wrote:
> > Create a new "ORC" unwinder, enabled by CONFIG_ORC_UNWINDER, and plug it
> > into the x86 unwinder framework. Objtool is used to generate the ORC
> > debuginfo. The ORC debuginfo format is basically a simplified version
> > of DWARF
* Josh Poimboeuf wrote:
> The biggest change is that undwarf was renamed to ORC. Here's the
> relevant explanation from the docs:
>
> Etymology
> -
>
> Orcs, fearsome creatures of medieval folklore, are the Dwarves' natural
> enemies. Similarly, the ORC unwinder was created
The biggest change is that undwarf was renamed to ORC. Here's the
relevant explanation from the docs:
Etymology
-
Orcs, fearsome creatures of medieval folklore, are the Dwarves' natural
enemies. Similarly, the ORC unwinder was created in opposition to the
complexity and slow
34 matches
Mail list logo
