Date: Tue, 10 Apr 2018 10:35:38 -0500 From: Josh Poimboeuf <jpoimboe@...hat.com> To: David Laight <David.Laight@...LAB.COM> Cc: "'kpark3469@...il.com'" <kpark3469@...il.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "catalin.marinas@....com" <catalin.marinas@....com>, "keescook@...omium.org" <keescook@...omium.org>, "will.deacon@....com" <will.deacon@....com>, "mark.rutland@....com" <mark.rutland@....com>, "james.morse@....com" <james.morse@....com>, "keun-o.park@...kmatter.ae" <keun-o.park@...kmatter.ae>, "psodagud@...eaurora.org" <psodagud@...eaurora.org>, "mingo@...nel.org" <mingo@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> 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: kpark3469@...il.com > > 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. -- Josh
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.