Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 10 Apr 2018 10:35:38 -0500
From: Josh Poimboeuf <>
To: David Laight <David.Laight@...LAB.COM>
Cc: "''" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>
Subject: Re: [PATCH v3 3/3] x86: usercopy: reimplement
 arch_within_stack_frames with unwinder

On Mon, Apr 09, 2018 at 01:14:58PM +0000, David Laight wrote:
> From:
> > Sent: 09 April 2018 12:59
> >
> > The old arch_within_stack_frames which used the frame pointer is
> > now reimplemented to use frame pointer unwinder apis. So the main
> > functionality is same as before.
> How much slower does this make the code?
> Following stack frames using %bp is reasonably quick.
> I can't imagine some of the other unwinder APIs being any where
> near that fast.
> While fine for fault tracebacks, using them during usercopy
> is likely to have measurable performance impact.

Agreed, using the unwind interface is going to be quite a bit slower
than the current manual approach.  So this patch has only drawbacks and
no benefits.

The only benefit would be if you used the unwind API in a generic
manner, such that it also worked for the ORC unwinder.  But even then I
think we'd need to see performance numbers, with both FP and ORC, to see
how bad the impact is on usercopy.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.