xen/wait: Describe RSB safety

It turns out that we do in fact have RSB safety here, but not for obvious
reasons.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This commit is contained in:
Andrew Cooper committed 2022-08-05 12:16:59 +01:00
1 parent e570e8d520
commit da74c951e4
1 file changed
+21
+21
View File
@@ -209,6 +209,27 @@ void check_wakeup_from_wait(void)
do_softirq(); do_softirq();
} }
/*
* We are about to jump into a deeper call tree. In principle, this risks
* executing more RET than CALL instructions, and underflowing the RSB.
*
* However, we are pinned to the same CPU as previously. Therefore,
* either:
*
* 1) We've scheduled another vCPU in the meantime, and the context
* switch path has (by default) issued IBPB which flushes the RSB, or
*
* 2) We're still in the same context. Returning back to the deeper
* call tree is resuming the execution path we left, and remains
* balanced as far as that logic is concerned.
*
* In fact, the path through the scheduler will execute more CALL
* than RET instructions, making the RSB unbalanced in the safe
* direction.
*
* Therefore, no actions are necessary here to maintain RSB safety.
*/
/* /*
* Hand-rolled longjmp(). * Hand-rolled longjmp().
* *
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.