https://git.reactos.org/?p=reactos.git;a=commitdiff;h=fc9bc9390d1b6548acc219...
commit fc9bc9390d1b6548acc21922546711042483e5b8 Author: Thomas Faber thomas.faber@reactos.org AuthorDate: Fri Apr 13 08:48:57 2018 +0200 Commit: Thomas Faber thomas.faber@reactos.org CommitDate: Fri Apr 13 09:04:52 2018 +0200
[HAL] Reset the stack pointer to the stack frame when calling second-entry interrupt handlers. CORE-14449
Because we can encounter pending interrupts repeatedly, HalpEndSoftwareInterrupt and HalEndSystemInterrupt already clean up the stack space for their arguments (done for CORE-11123/CORE-14076). However these functions are called from C functions such as KiInterruptDispatch and HalpDispatchInterrupt2[ndEntry]. These callers also use up stack space, and it is unknown how much. To fix this, we simply reset the stack pointer to the location of the trap frame, which is where it points during a first-level dispatch. This cleans up the stack usage of any callers higher up, and is okay because a return will happen through the trap frame anyway.
Dedicated to Pierre. --- hal/halx86/up/pic.S | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/hal/halx86/up/pic.S b/hal/halx86/up/pic.S index a5addcdf8c..3f65a5545d 100644 --- a/hal/halx86/up/pic.S +++ b/hal/halx86/up/pic.S @@ -39,11 +39,14 @@ PUBLIC _&WrapperName&@8 ret 8
WrapperName&_CallIntHandler: - /* We got a pointer to call. Since it won't return, free up our stack - space. Otherwise we could end up with some nasty deep recursion. + /* We got a pointer to call. Since it won't return, reset the stack to + the location of the stack frame. This frees up our own stack as well + as that of the functions above us, and avoids an overflow due to + excessive recursion. The next function takes the trap frame as its (fastcall) argument. */ mov ecx, [esp+8] - add esp, 12 + mov esp, ecx + mov ebp, esp jmp eax .ENDP ENDM