On Wed, Sep 20, 2017 at 11:19 PM, Andy Lutomirski <l...@amacapital.net> wrote: >>> On Wed, Sep 20, 2017 at 08:01:02PM +0200, Dmitry Vyukov wrote: >>>> On Wed, Sep 20, 2017 at 7:46 PM, H. Peter Anvin <h...@zytor.com> wrote: >>>>> On 09/20/17 10:38, Dmitry Vyukov wrote: >>>>> >>>>> I think we need just the frame itself and RSP pointing below this >>>>> frame. If we don't have a frame, CALL instruction will smash whatever >>>>> RSP happens to point to. Compiler doesn't have to setup RSP to point >>>>> below used part of stack in leaf functions. >>>>> >>>> >>>> In the kernel it does. Redzoning is not allowed in the kernel, because >>>> interrupts or exceptions would also smash the redzone. >>> >>> I see... But it's the same for user-space signals, the first thing a >>> signal should do is to skip the redzone. I guess interrupt handlers >>> should switch to interrupt stack which avoids smashing redzone >>> altogether. Do you mean nested interrupts/exceptions in interrupts? >>> In my experience frames in leaf functions can have pretty large >>> performance penalty. Wonder if we have we considered changing >>> interrupt/exception handlers to avoid smashing redzones and disable >>> leaf frames? >> >> Currently, on x86-64, I believe all exceptions have their own dedicated >> stacks in the kernel, but IRQs still come in on the task's kernel stack. >> >> Andy, do you know if there's a reason why IRQs don't use a dedicated IST >> stack? >> > > Because IST is awful due to recursion issues. We immediately switch to an > IRQ stack, though. > > If the kernel wanted a redzone, it would have to use IST for everything, > which would entail a bunch of unpleasant hackery.
Thanks. I guess it must be finite recursion, because we could not handle infinite with finite stack. I thing that solves it is simply: sub $256, %rsp ... do stuff ... add $256, %rsp Don't know if it's applicable to interrupts or not.