[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/paging: Delete update_cr3()'s do_locking parameter
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 21 Sep 2023 14:38:57 +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=re3sTetQCopVB3sggpRZXgo3/Dc/Naj2hY1hygO3it4=; b=doLJnrljyVjhRHM2miOAiEEqIeLgwAhNB23Be3dbgzuMr6T0CQJ1QHswCdZ5p4kSAc89uoEegWBC9PXCLqVP8iGvq5z9ZyxwEdIWzIEV59igu+MAlxAAp00nZI4n0EvzpsR0G+/X7vxDmMkzdHpNFpLw4OPqokVoqEsW4/xAVHs2urzoxdOJtwKCDswyiyt2lL226YnGGZ9Sy0u5+BygbOjgHwYgUaSgXFPuGKLTLJscSnCYaZrRDdx8kZHSsshZWfwM90xs/rbS4W1Syn+f7sGrPzslxztUtC4xUtP9sSro2lXSi4pyDWHHPAS6969INpMpC72nNHA9aBJ5DEgxYw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YsG/LkzaiCDn1pWzVBdTN05CPi90BYhAXFjLdQ+lpMEcfIxp1IjHzJ+BJ8gxKwlY3edSpitvlRnN7pyYyjoh6AaDESVFdKDqOJ7LyycTvhSDpy08AiaJa6biBRXzJdCoezS51QY2N8QYpk+xlNcjmmAhhn/XL7Rprj4z9kZkgGcGdig6gt03xCnf7YEV/dcyLKRxXl6IYG/tkafMiRmnuqeY6wfDTK9nHr3MzVcMIGYKgw6mk1WY/+9rkNcjH6Z0cgze8naxCFhk9NsPF4XG6on+vaije4akQhpXi1toE//jcEZ32cIcBFkgiPNeLYe/JJ71ierUgEgydbykN6cUHg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 21 Sep 2023 12:39:33 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 20.09.2023 21:21, Andrew Cooper wrote:
> Nicola reports that the XSA-438 fix introduced new MISRA violations because of
> some incidental tidying it tried to do. The parameter is useless, so resolve
> the MISRA regression by removing it.
>
> hap_update_cr3() discards the parameter entirely, while sh_update_cr3() uses
> it to distinguish internal and external callers and therefore whether the
> paging lock should be taken.
>
> However, we have paging_lock_recursive() for this purpose, which also avoids
> the ability for the shadow internal callers to accidentally not hold the lock.
>
> Fixes: fb0ff49fe9f7 ("x86/shadow: defer releasing of PV's top-level shadow
> reference")
> Reported-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> CC: Wei Liu <wl@xxxxxxx>
> CC: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> CC: Tim Deegan <tim@xxxxxxx>
> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> CC: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
>
> Slightly RFC. Only compile tested so far.
With shadow/none.c also suitably edited
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
I'm a little surprised you introduce new uses of the (kind of odd) recursive
lock,
when previously you voiced your dislike for our use of such. ("Kind of odd"
because
unlike spin_lock_recursive(), only the potentially inner caller needs to use the
recursive form of the acquire.)
Jan
|
