[Suspend2-devel] Bad EIP value

[Johannes Berg]

Bernard Blackham said:
> In do_suspend2_lowlevel() we have:
>   1 move_stack_to_nonconflicing_area();
>   2 suspend2_copyback_low(); /* 0 = use logical addresses */
>   3 suspend2_restore_processor_context();
>   4 suspend2_flush_caches();
>   5 suspend2_copyback_high();
>   6 suspend2_flush_caches();
>   7 suspend2_post_copyback();
>   8 (restore loop and) suspend2_resume_2();
>
> We really only need suspend2_restore_processor_context to be
> inlined, as this is what restores our stack pointer so we return
> back into save_image().
>
> So if we make copyback_low noinline, and we pass everything else
> from 4-8 into a separate function that is declared noinline, then we
> can be certain that it won't touch the old stack, and we only need
> to worry about restore_processor_context().
>
> The critical point in restore_processor_context() is after restoring
> stack and frame pointer regs (then we can use our stack without
> fear), and the arch-specific code for this can simply take care not
> to touch the stack (eg, for i386 we just make fix_processor_context
> and do_fpu_end out-of-line).
>
> It feels cleaner than altering register that look like stack
> addresses.
>
> Am I making any sense this morning? =)

Sort of. Sorry for the overquote, but I couldn't find anything to strip.

After restore_processor_context() we have the old stack and old frame
pointers, so how can accesses to %ebp(x) work for any x? Actually, this is
one thing I've been wondering about for quite a while. We restore the
stack from within save_image but who guarantees that after
restore_processor_context() we have any usable amount of local stack
space? I think all the functions that we call after that should really be
noinline as well.
OTOH, if that is not a problem, then it doesn't matter and we can have
just copyback_low() noinline and that's all...

Not sure. I need to draw some diagrams to understand this.

johannes