[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] sysctl: XSM hook should not cause XEN_SYSCTL_getdomaininfolist to (appear to) fail
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Tue, 2 May 2023 10:27:39 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=riX/EATnG8fjIwzTkKAbOEAU7FIgdSiaCVyzPoBYrYI=; b=bpDd6HgEGwVkXT09d0zvxUYmMktK/s48ccWi9cFQenZyaNk9421fOLdpxwKVnWxixA7jAHD4N47IlbWI4GLjAwsOFWQnXlpQwEXATy31UC93iJHOtljrYTSxbw3OErhsMZxr0mWGE9LOrRSzdEofHk68oM4/2gOUriT/BKdwszNqTq3Lc1PaW2R7w34ytMlZPh/yk8Co4OwWal4FJdbT01gTrA1dgiet6UUsH1SwDk22+WhxGLCMJjrMuXdNCzJ3Ripx5ozdmnkRq9pFLlWfDxo6hYPeC7+ooYc8N334c/P5tRocmpnQwbIN9Az4fdRY432RSBX7jAA3Pxxj+2WirQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q3fd5wyjhZpZtnTaw8zyv1w9IYxEXpbBA1F7qVmT2VphG69kl2ZpcbcQ2IHV9K1RFeuUltrDBDxA6QXzVqzbk3ekKekrP3zvY/x2ipVWfMwL7IZCL7i7LJ/lXkfH8dwLEMXgtvUNzCTa0nF36NLMIdosFbLmps0GuD6qD0C4Wxi8qdGvh7LF+vitvPR3SSRvrV8pu3pR3zOVUJvTBl56rFbTRRcrCBfjC70OclCOadziPTmD1Yy2py2cpdANllhhOhNzFXdnzQ4m9QcdglyHyk4vwLaCilqFpcoDJBRD0LBwfrDlIkOXWIh5ih0u36Zm59zPsERfS/rqyyOkU/ysuw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>, Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>, Jason Andryuk <jandryuk@xxxxxxxxx>
- Delivery-date: Tue, 02 May 2023 09:28:08 +0000
- Ironport-data: A9a23:dvnP2qivJMuHsnZ+3QUtyDLPX161+xEKZh0ujC45NGQN5FlHY01je htvCG7QOKyDZGL9cotzO4njoBhTuseAxoBnSFRlqSxnHi8b9cadCdqndUqhZCn6wu8v7q5Ex 55HNoSfdpBcolv0/ErF3m3J9CEkvU2wbuOgTrWCYmYpHlUMpB4J0XpLg/Q+jpNjne+3CgaMv cKai8DEMRqu1iUc3lg8sspvkzsy+qWj0N8klgZmP6sT4QeEzyB94K83fsldEVOpGuG4IcbiL wrz5OnR1n/U+R4rFuSknt7TGqHdauePVeQmoiM+t5mK2nCulARrukoIHKN0hXNsoyeIh7hMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL1yDwyjaMKVBktubD12i+ tQJB2wDMSjbg9m354yqQdFLm8lkCNPSadZ3VnFIlVk1DN4AaLWbGeDmwIQd2z09wMdTAfzZe swVLyJ1awjNaAFOPVFRD48imOCvhT/0dDgwRFC9/PJrpTSMilEvluS9WDbWUoXiqcF9t0CUv G/ZuU/+BQkXLoe3wjuZ6HO8wOTImEsXXapLTOLpq6Ay2gD7Kmo7CwMudV/q+OKDhHG+fIldK x0T5jFphP1nnKCsZpynN/Gim1aGtBMBX9tbE8Uh9RqAjKHT5m6xFmUCCzJMdtEinMs3XiAxk E+EmcvzAj5iu6HTTmiSnp+WsDezNC49PWIEIygeQmMt+ML/qYs+ihbOSNdLE6OviNDxXzbqz FiisywWl7gVy8kR2M2T8UjchjOwprDAVgMv+hjMRWWh8x94Y4i+IYev7DDz5PJNLo+fQkOG+ mYNn8yT7ucmBpWKiSDLS+IIdJmr7vCJKizBgnZgGpAg83Km/HvLQGxLyDR3JUMsPsNffzbsO BXXoVkJuM8VO2a2Z6hqZY73E94t0aXrCdXiULbTc8ZKZZ9yMgSA+UmCeHKt4owkq2B0+YlXB HtRWZ/E4aoyYUi/8AeLeg==
- Ironport-hdrordr: A9a23:QkKfhqg/PDQayhHe/l/tuaPn2nBQX1B13DAbv31ZSRFFG/FwyP rCoB1L73XJYWgqM03IwerwQJVoMkmsjqKdgLNhdYtKOTOLhILGFvAH0WKP+Vzd8mjFh5dgPM RbAuND4b/LfD9HZK/BiWHWferIguP3lpxA7t2urEuFODsaDp2ImD0JaDpzfHcXeCB2Qb4CUL aM7MtOoDStPV4NaN6gO3UDV+/f4/XWiZPPe3c9dlMawTjLqQntxK/xEhCe0BtbeShI260e/W /MlBG8zrm/ssu81gTX2wbonthrcZrau5R+7f63+4kowwbX+0aVjUNaKv6/VQUO0a+SAZAR4Z vxSlkbToFOAjjqDxuISFPWqnTdOXAVmjXfIBaj8ATeScCVfkNHN+NRwY1eaRfX8EwmoZV117 9KxXuQs95NAQrHhzmV3am+a/hGrDvAnZMZq59ms1VPFY8FLLNBp40W+01YVJ8GASLh8YgiVO 1jFtvV6vpaeU6TKymxhBgn/PW8GnAoWhuWSEkLvcKYlzBQgXBi1kMdgMgShG0J+p4xQ4RNo+ 7ELqNrnrdTSdJ+V9MKOM4RBc+sTmDdSxPFN2yfZVzhCaEcInrI74X65b0kjdvaCqDgDKFC66 gpfGkoxVLaIXied/Fm9Kc7gyzwfA==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 02/05/2023 8:17 am, Jan Beulich wrote:
> The hook being able to deny access to data for certain domains means
> that no caller can assume to have a system-wide picture when holding the
> results.
>
> Wouldn't it make sense to permit the function to merely "count" domains?
> While racy in general (including in its present, "normal" mode of
> operation), within a tool stack this could be used as long as creation
> of new domains is suppressed between obtaining the count and then using
> it.
This would not be the first example of the XSM hooks being tantamount to
useless. I doubt it will be the last either.
With the rest of Alejandro's series in place, all requests for a single
domid's worth of info use the domctl, and all requests for all domains
use the systctl.
As a result, we can retrofit some sanity and change the meaning of the
XSM hook here for the sysctl, to mean "can see a systemwide view" (or
not). This moves the check out of the loop, and fixes the behaviour.
~Andrew
|
