linux-kernel - RE: [Patch v2 1/4] Drivers: hv: Allocate interrupt and monitor pages aligned to system page boundary

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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SN6PR02MB41574E031668E0F27AABB978D4822@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Thu, 1 May 2025 01:55:39 +0000
From: Michael Kelley <mhklinux@...look.com>
To: "longli@...uxonhyperv.com" <longli@...uxonhyperv.com>, "K. Y. Srinivasan"
	<kys@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>, Wei Liu
	<wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>, Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>, "linux-hyperv@...r.kernel.org"
	<linux-hyperv@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: Long Li <longli@...rosoft.com>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>
Subject: RE: [Patch v2 1/4] Drivers: hv: Allocate interrupt and monitor pages
 aligned to system page boundary

From: longli@...uxonhyperv.com <longli@...uxonhyperv.com> Sent: Wednesday, April 30, 2025 3:06 PM
> 
> There are use cases that interrupt and monitor pages are mapped to
> user-mode through UIO, they need to be system page aligned. Some Hyper-V

s/UIO, they/UIO, so they/

> allocation APIs introduced earlier broke those requirements.
> 
> Fix those APIs by always allocating Hyper-V page at system page boundaries.

This patch modifies hv_alloc_hyperv_page() and friends. Then Patch 4 of the
series deletes them, including the modifications. It would be less code motion
to do the first part of Patch 4 (i.e., the use of __get_free_page directly in
connection.c) here in Patch 1, and leave hv_alloc_hyperv_page() and friends
unmodified. Continue to make the change to hv_kmsg_dump_register() here
in Patch 1 as well.

Then have Patch 2 simply delete hv_alloc_hyperv_page() and friends
because they are no longer used. The modifications to hv_alloc_hyperv_page()
and friends would not be needed.

Patch 3 and 4 would be the additional changes in uio_hv_generic.c.

Michael

> 
> Cc: stable@...r.kernel.org
> Fixes: ca48739e59df ("Drivers: hv: vmbus: Move Hyper-V page allocator to arch neutral code")
> Signed-off-by: Long Li <longli@...rosoft.com>
> ---
>  drivers/hv/hv_common.c | 35 ++++++++++-------------------------
>  1 file changed, 10 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> index a7d7494feaca..297ccd7d4997 100644
> --- a/drivers/hv/hv_common.c
> +++ b/drivers/hv/hv_common.c
> @@ -106,41 +106,26 @@ void __init hv_common_free(void)
>  }
> 
>  /*
> - * Functions for allocating and freeing memory with size and
> - * alignment HV_HYP_PAGE_SIZE. These functions are needed because
> - * the guest page size may not be the same as the Hyper-V page
> - * size. We depend upon kmalloc() aligning power-of-two size
> - * allocations to the allocation size boundary, so that the
> - * allocated memory appears to Hyper-V as a page of the size
> - * it expects.
> + * A Hyper-V page can be used by UIO for mapping to user-space, it should
> + * always be allocated on system page boundaries.
>   */
> -
>  void *hv_alloc_hyperv_page(void)
>  {
> -	BUILD_BUG_ON(PAGE_SIZE <  HV_HYP_PAGE_SIZE);
> -
> -	if (PAGE_SIZE == HV_HYP_PAGE_SIZE)
> -		return (void *)__get_free_page(GFP_KERNEL);
> -	else
> -		return kmalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL);
> +	BUILD_BUG_ON(PAGE_SIZE < HV_HYP_PAGE_SIZE);
> +	return (void *)__get_free_page(GFP_KERNEL);
>  }
>  EXPORT_SYMBOL_GPL(hv_alloc_hyperv_page);
> 
>  void *hv_alloc_hyperv_zeroed_page(void)
>  {
> -	if (PAGE_SIZE == HV_HYP_PAGE_SIZE)
> -		return (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> -	else
> -		return kzalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL);
> +	BUILD_BUG_ON(PAGE_SIZE < HV_HYP_PAGE_SIZE);
> +	return (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
>  }
>  EXPORT_SYMBOL_GPL(hv_alloc_hyperv_zeroed_page);
> 
>  void hv_free_hyperv_page(void *addr)
>  {
> -	if (PAGE_SIZE == HV_HYP_PAGE_SIZE)
> -		free_page((unsigned long)addr);
> -	else
> -		kfree(addr);
> +	free_page((unsigned long)addr);
>  }
>  EXPORT_SYMBOL_GPL(hv_free_hyperv_page);
> 
> @@ -272,7 +257,7 @@ static void hv_kmsg_dump_unregister(void)
>  	atomic_notifier_chain_unregister(&panic_notifier_list,
>  					 &hyperv_panic_report_block);
> 
> -	hv_free_hyperv_page(hv_panic_page);
> +	kfree(hv_panic_page);
>  	hv_panic_page = NULL;
>  }
> 
> @@ -280,7 +265,7 @@ static void hv_kmsg_dump_register(void)
>  {
>  	int ret;
> 
> -	hv_panic_page = hv_alloc_hyperv_zeroed_page();
> +	hv_panic_page = kzalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL);
>  	if (!hv_panic_page) {
>  		pr_err("Hyper-V: panic message page memory allocation failed\n");
>  		return;
> @@ -289,7 +274,7 @@ static void hv_kmsg_dump_register(void)
>  	ret = kmsg_dump_register(&hv_kmsg_dumper);
>  	if (ret) {
>  		pr_err("Hyper-V: kmsg dump register error 0x%x\n", ret);
> -		hv_free_hyperv_page(hv_panic_page);
> +		kfree(hv_panic_page);
>  		hv_panic_page = NULL;
>  	}
>  }
> --
> 2.34.1
>