On Mon, May 23, 2016 at 4:02 PM, Jiri Kosina <jikos@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
