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
| ||
|
Message-ID: <CALCETrX=c4BeUA7MzWcg6fLsTggUOaC4mDVDVxYOYDBCe0F2oQ@mail.gmail.com> Date: Mon, 23 May 2016 18:42:49 -0700 From: Andy Lutomirski <luto@...capital.net> To: Jiri Kosina <jikos@...nel.org> Cc: Josh Poimboeuf <jpoimboe@...hat.com>, Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>, Heiko Carstens <heiko.carstens@...ibm.com>, "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>, live-patching@...r.kernel.org, Michael Ellerman <mpe@...erman.id.au>, Chris J Arges <chris.j.arges@...onical.com>, linuxppc-dev@...ts.ozlabs.org, Jessica Yu <jeyu@...hat.com>, Petr Mladek <pmladek@...e.com>, Jiri Slaby <jslaby@...e.cz>, Vojtech Pavlik <vojtech@...e.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Miroslav Benes <mbenes@...e.cz>, Peter Zijlstra <peterz@...radead.org> Subject: Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking On Mon, May 23, 2016 at 4:02 PM, Jiri Kosina <jikos@...nel.org> wrote: > On Fri, 20 May 2016, Andy Lutomirski wrote: > >> I think it would be negligible, at least for interrupts, since >> interrupts are already extremely expensive. But I don't love adding >> assembly code that makes them even slower. The real thing I dislike >> about this approach is that it's not a normal stack frame, so you need >> code in the unwinder to unwind through it correctly, which makes me >> think that you're not saving much complexity by adding the pushes. > > I fail to see what is so special about the stack frame; it's in fact > pretty normal. > > It has added semantic value for "those who know", but the others will > (pretty much correctly) consider it to be a stackframe from a function > call, and be done with it. > > What am I missing? In Josh's code, the stack looks like: ... interrupted frame pt_regs pointer to pt_regs address of pt_regs dummy function rbp handler frame A naive unwinder won't unwind this correctly, as there's no link back to the interrupted frame's RIP. If the layout changed to: ... interrupted frame pt_regs interrupted RIP rbp handler frame then I think it would unwind correctly, but the pt_regs would be invisible, which is IMO a bit unfortunate. It could also be (I think): ... interrupted frame pt_regs interrupted rbp interrupted RIP pointer to pt_regs address of pt_regs dummy function pointer to "interrupted RIP" stack slot handler frame but now this is *five* pushes for the dummy frame, which I think is getting a bit out of hand. --Andy
Powered by blists - more mailing lists