Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 23 May 2016 18:42:49 -0700 | 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@kernel.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
| |