[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-4.17?] x86/paging: return -EINVAL for paging domctls for dying domains
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Wed, 9 Nov 2022 14:22:26 +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=dnkrBU9otFoxnR1euvBHtCseCIwUb3BaZS4J81TjYdI=; b=ARIPJZ2X3Cr8LLHJi4j0HLeoykmcWtZUOvjKg7r+hpf0VTTHgYys/Jie5FVoqq26kVfwo+kHjiEEkt5pSrPlr9zPCRO3umigCeLj2Aqmzhy7CxLEWEvB5RGnOzN3325O33/5tj0cx/C/tRnKTVzcCbbkFeufDjsPIUuwmCrgniDmkZ38kVtXnvOWZPdmO+MhG3tyu378RrSArebOT6AQ6dwW9SxIy89rz8meQYpWTk8oybQKcdlGdACgineMcOgcNTZLj/cj0jSJ8XUxmRXImY1DC82sOYaH4/Ql6sdDgrRcnmUVuLlYa9BnGU3XR/I4sHvfnhlk2QNvu2zu6LP58Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hBm9VcRqsaqJzQTqW6NSxKkI9ZCTgEy/fCPxMHf2u5yuIbLxtRwED8l9DVqbqxlw8iM01Zr6zFdBGjkt32VF1V3l9MQn9IX0S8ctmDuxN/+QTrUPxECs5CrFmIEc7uAKGxQFYherPyu/UcesosZgaID7TrxxHCBZW36Wdh0W1xXeYn+MHSd+LaTP+tbXl1+7Q9TwIh8/qN0zDR3maKZfv3J2To7+jw4xjhf6YSCLbCELEL24BUXO6hIktvCYpykPeiVrkBcI0mQKh0+A6BiyzZgkqScAh7adGcnHMTdhsFyh7U3bTnjsl4VL6xgBJvJ400WS/pli3JmD3A6s9B8y7g==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Henry.Wang@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Edwin Török <edvin.torok@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Wed, 09 Nov 2022 13:23:10 +0000
- Ironport-data: A9a23:46WYlq+PsbmvR3GNprsvDrUDsH+TJUtcMsCJ2f8bNWPcYEJGY0x3y TAdW2HSb/qMNDbxc9gnPYy28E5Sup/Syt5kT1Zo+Sk8E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjUAOG6UKucYHsZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ire7kIx1BjOkGlA5AZnPKga5AW2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDkkV8 uM/CTcmfiuchvyv8JCARqpU2pkKeZyD0IM34hmMzBn/JNN/G9XmfP+P4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTaNilAguFTuGIO9ltiiX8Jak1zev mvb12/4HgsbJJqUzj/tHneE1rSSwXyhCd96+LuQ9t80p2a25FEvKgAKfgHg/MWYqWSzVIcKQ 6AT0m90xUQoz2SpRNTgWxyzoFafowURHdFXFoUSyAyL0LuS3A+fCUANVDsHY9sj3OcpQRQ62 1nPmMnmbRR/vbvQRX+D+7O8qTKpJTNTPWIEfTUDTwYO/5/kuo5bs/7UZtNqEarwi8KvHzj1m mqOtHJm2+RVitMX3aKm+1yBmyirupXCUg8y4EPQQ36h6QR6IoWiYuRE9GTm0BqJF67BJnHpg ZTOs5H2ADwmZX1VqBGwfQ==
- Ironport-hdrordr: A9a23:RtpJJ6oT+RIUoG6wgP73m2kaV5uwL9V00zEX/kB9WHVpm5Oj+v xGzc5w6farsl0ssREb9uxo9pPwJE800aQFmbX5Wo3SJzUO2VHYVb2KiLGP/9SOIU3DH4JmpM Rdmu1FeafN5DtB/LnHCWuDYrEdKbC8mcjH5Ns2jU0dKz2CA5sQkzuRYTzrdnGeKjM2Z6bQQ/ Gnl7d6TnebCAIqR/X+IkNAc/nIptXNmp6jSRkaByQ/4A3LqT+z8rb1HzWRwx9bClp0sP8f2F mAtza8yrSosvm9xBOZ/2jP765OkN+k7tdYHsSDhuUcNz2poAe1Y4ZKXaGEoVkO0aiSwWdvtO OJjwYrPsx15X+UVmapoSH10w2l6zoq42+K8y7svVLT5ejCAB4qActIgoxUNjHD7VA7gd162K VXm0qEqpt+F3r77WjAzumNcysvulu/oHIkn+JWpWdYS5EiZLhYqpFa1F9JEa0HADnx5OkcYa RT5fnnlbhrmG6hHjHkVjEF+q3tYp1zJGbNfqE6gL3b79AM90oJjHfxx6Qk7wU9HdwGOtt5Dt //Q9RVfYF1P7ErhJ1GdZY8qOuMexjwqEH3QRWvCGWiMp07EFTwjLOyyIkJxYiRCe81Jd0J6d /8bG8=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Nov 09, 2022 at 01:02:28PM +0100, Jan Beulich wrote:
> On 09.11.2022 12:36, Roger Pau Monné wrote:
> > Since I don't see replies to my other comments, do you agree on
> > returning an error then?
>
> No, my view there hasn't changed. I wouldn't block a change to go in
> early for 4.18, but I also wouldn't ack such.
>
> Perhaps just one remark on your other earlier comments: While you're
> right about XEN_DOMCTL_SHADOW_OP_{CLEAN,PEEK}, (effectively) random
> data in the bitmap may cause a caller to do extra work, but wouldn't
> look to be otherwise harmful: Considering pages dirty which aren't
> is never a functional problem, while considering pages clean which
> aren't is (imo) not a problem for a dying domain.
Can't that lead to failures elsewhere when attempts to fetch those
pages find they might have been removed from the p2m?
We are exchanging one failure path for another, but it would make more
sense to return an error here instead of uninitialized data, so that
the tools don't attempt to perform actions based on such invalid
bitmaps.
Thanks, Roger.
|
