linux-kernel - RE: [PATCH v3 4/4] mshv: Handle insufficient root memory hypervisor statuses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <SN6PR02MB4157F28C4F4CEFB886CF949ED466A@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Fri, 6 Feb 2026 18:54:55 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>,
	"kys@...rosoft.com" <kys@...rosoft.com>, "haiyangz@...rosoft.com"
	<haiyangz@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>,
	"decui@...rosoft.com" <decui@...rosoft.com>, "longli@...rosoft.com"
	<longli@...rosoft.com>
CC: "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 4/4] mshv: Handle insufficient root memory hypervisor
 statuses

From: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com> Sent: Thursday, February 5, 2026 10:42 AM
> To: kys@...rosoft.com; haiyangz@...rosoft.com; wei.liu@...nel.org;
> decui@...rosoft.com; longli@...rosoft.com
> Cc: linux-hyperv@...r.kernel.org; linux-kernel@...r.kernel.org
> Subject: [PATCH v3 4/4] mshv: Handle insufficient root memory hypervisor statuses
> 
> When creating guest partition objects, the hypervisor may fail to
> allocate root partition pages and return an insufficient memory status.
> In this case, deposit memory using the root partition ID instead.
> 
> Note: This error should never occur in a guest of L1VH partition context.
> 
> Signed-off-by: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>
> ---
>  drivers/hv/hv_common.c      |    2 +
>  drivers/hv/hv_proc.c        |   14 ++++++++++
>  include/hyperv/hvgdk_mini.h |   58 ++++++++++++++++++++++---------------------
>  3 files changed, 46 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index f20596276662..6b67ac616789 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -794,6 +794,8 @@ static const struct hv_status_info hv_status_infos[] = {
>  	_STATUS_INFO(HV_STATUS_PROPERTY_VALUE_OUT_OF_RANGE,	-EIO),
>  	_STATUS_INFO(HV_STATUS_INSUFFICIENT_MEMORY,		-ENOMEM),
>  	_STATUS_INFO(HV_STATUS_INSUFFICIENT_CONTIGUOUS_MEMORY,	-ENOMEM),
> +	_STATUS_INFO(HV_STATUS_INSUFFICIENT_ROOT_MEMORY,	-ENOMEM),
> +	_STATUS_INFO(HV_STATUS_INSUFFICIENT_CONTIGUOUS_ROOT_MEMORY, 	-ENOMEM),
>  	_STATUS_INFO(HV_STATUS_INVALID_PARTITION_ID,		-EINVAL),
>  	_STATUS_INFO(HV_STATUS_INVALID_VP_INDEX,		-EINVAL),
>  	_STATUS_INFO(HV_STATUS_NOT_FOUND,			-EIO),
> diff --git a/drivers/hv/hv_proc.c b/drivers/hv/hv_proc.c
> index 181f6d02bce3..5f4fd9c3231c 100644
> --- a/drivers/hv/hv_proc.c
> +++ b/drivers/hv/hv_proc.c
> @@ -121,6 +121,18 @@ int hv_deposit_memory_node(int node, u64 partition_id,
>  	case HV_STATUS_INSUFFICIENT_CONTIGUOUS_MEMORY:
>  		num_pages = HV_MAX_CONTIGUOUS_ALLOCATION_PAGES;
>  		break;
> +
> +	case HV_STATUS_INSUFFICIENT_CONTIGUOUS_ROOT_MEMORY:
> +		num_pages = HV_MAX_CONTIGUOUS_ALLOCATION_PAGES;
> +		fallthrough;
> +	case HV_STATUS_INSUFFICIENT_ROOT_MEMORY:
> +		if (!hv_root_partition()) {
> +			hv_status_err(hv_status, "Unexpected root memory deposit\n");
> +			return -ENOMEM;
> +		}
> +		partition_id = HV_PARTITION_ID_SELF;
> +		break;
> +

Per the discussion in v1 of this patch set, if the number of pages that should be
deposited in a particular situation is different from what this function provides,
the fallback is to use hv_call_deposit_pages() directly. From what I see, there's
only one such fallback case after a hypercall failure -- in hv_do_map_gpa_hcall().
The other uses of hv_call_deposit_pages() are initial deposits when creating a
VP or partition.

But if hv_call_deposit_pages() is used directly, the logic added here to detect
insufficient root memory and deposit to HV_PARTITION_ID_SELF isn't applied.
So if the hypercall in hv_do_map_gpa_hcall() fails with insufficient root
memory, the deposit is done to the wrong partition ID. If that case can
actually happen, then some additional logic is needed in
hv_do_map_gpa_hcall() to handle it. Or there needs to be a fallback
function that contains the logic.

Other than that, everything else in this patch set looks good to me.

Michael

>  	default:
>  		hv_status_err(hv_status, "Unexpected!\n");
>  		return -ENOMEM;