From: Andrew Cooper Date: Tue, 14 Jun 2022 15:18:36 +0000 (+0100) Subject: xen/wait: Describe RSB safety X-Git-Tag: archive/raspbian/4.17.0-1+rpi1^2~33^2~342 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=da74c951e4e58080583daaad373b0d38a3f8bc83;p=xen.git 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 Reviewed-by: Jan Beulich --- diff --git a/xen/common/wait.c b/xen/common/wait.c index e45345ede7..86d3b15419 100644 --- a/xen/common/wait.c +++ b/xen/common/wait.c @@ -209,6 +209,27 @@ void check_wakeup_from_wait(void) 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(). *