[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xen/wait: Describe RSB safety
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 5 Aug 2022 12:51:30 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ocQwyIDVrCzLEs4NdDWQT1Voiibm6xPg9LD3hDeZZjk=; b=mVTuZlcplhYUgTc0wdGDn5v7XPw4zLjFk1cBg2z7Z+wGovO62nMXG/tgjmctJ3+chlx8o0Hs+5zAoWuCHzJJ80+0YDzIXqLlMzAs/c6H8z2GoKcldo7pu0S60uAArKUwkH56worpGDVZ+lvBNfeQJEAx+8FyFmtke364Aclgjz5cyQjmKRHxhcxirJskPQ0mWMCt1yFZO13bEGOyicAL/eYkwLo1peh3e+mxwAu3fAkfN5qaQXiU/7TwfA1XgWoi+IpPd6Ez8qWJ0tdg9Q6l1mhy1mfFo5K/gjzSod0yLAapVb0i8uqmiXsd8mb930TpWfLw5jSoXDfGn1gvZJpaag==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K/zM3OuBo6CNDapcU2hHiqpfiTjfNxDs/K11ik8qWcrQgvnbrrLnvqab7GojL2YHxv8h7onNjPIYdSHZySSadB/cPfTWLY4Xgq2ABs/4UP/dTDmo1nise34G8PDAVN1G9WCGPtPzIJIvYOP8/uhqTiQu/fO+T46vUyBk9lc5f4vclHsFnpGnBSvZ0pZPw/91GO8ltmYW6x7YfqgMCjoAiFBeRIfHdQ+59thxQLfOHwOnvmFRkeh500gQVqDzl4mbuvEMQRvX/sufqMMnVHJi9rI6YgTzgRHcx0CRLSerIhDB90xZfM5gk+7ET/18fKEX26oPEYxGHTP41NRQUtBO8Q==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 05 Aug 2022 10:51:37 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 05.08.2022 12:38, Andrew Cooper wrote:
> It turns out that we do in fact have RSB safety here, but not for obvious
> reasons.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
preferably with ...
> --- a/xen/common/wait.c
> +++ b/xen/common/wait.c
> @@ -210,6 +210,26 @@ void check_wakeup_from_wait(void)
> }
>
> /*
> + * 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 IPBP which flushes the RSB,
> or
... IBPB used here and ...
> + * 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 though the scheduler will execute more CALL
> than
... (nit) "through" used here.
> + * RET instructions, making the RSB unbalanced in the safe
> direction.
> + *
> + * Therefore, no actions are necessary here to maintain RSB safety.
> + */
> +
> + /*
> * Hand-rolled longjmp().
> *
> * check_wakeup_from_wait() is always called with a shallow stack,
|
