* Re: [PATCH][v2] drivers: hid: Add a module description line to the hid_hyperv driver
From: Sasha Levin @ 2019-04-23 19:44 UTC (permalink / raw)
To: Michael Kelley
Cc: Joseph Salisbury, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
jikos@kernel.org, benjamin.tissoires@redhat.com,
linux-hyperv@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DM5PR2101MB09183A22984131883E033DA7D7230@DM5PR2101MB0918.namprd21.prod.outlook.com>
On Tue, Apr 23, 2019 at 04:38:05PM +0000, Michael Kelley wrote:
>From: Joseph Salisbury <joseph.salisbury@microsoft.com> Sent: Monday, April 22, 2019 8:47 PM
>>
>> This patch only adds a MODULE_DESCRIPTION statement to the driver.
>> This change is only cosmetic, so there should be no runtime impact.
>>
>>
>> Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
>> ---
>
>Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Queued up for hyperv-next, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* RE: [PATCH][v2] drivers: hid: Add a module description line to the hid_hyperv driver
From: Michael Kelley @ 2019-04-23 16:38 UTC (permalink / raw)
To: Joseph Salisbury, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, jikos@kernel.org,
benjamin.tissoires@redhat.com
Cc: linux-hyperv@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <324016691a62a13ce46c9ccd35c7e492bf609fd6.1555967348.git.joseph.salisbury@microsoft.com>
From: Joseph Salisbury <joseph.salisbury@microsoft.com> Sent: Monday, April 22, 2019 8:47 PM
>
> This patch only adds a MODULE_DESCRIPTION statement to the driver.
> This change is only cosmetic, so there should be no runtime impact.
>
>
> Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
> ---
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
^ permalink raw reply
* RE: [PATCH][v2] drivers: hv: Add a module description line to the hv_vmbus driver
From: Michael Kelley @ 2019-04-23 16:39 UTC (permalink / raw)
To: Joseph Salisbury, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <04eaef0e2b365317935ff756c7365ee13a6f18f8.1555967337.git.joseph.salisbury@microsoft.com>
From: Joseph Salisbury <joseph.salisbury@microsoft.com> Sent: Monday, April 22, 2019 8:47 PM
>
> This patch only adds a MODULE_DESCRIPTION statement to the driver.
> This change is only cosmetic, so there should be no runtime impact.
>
> Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
^ permalink raw reply
* RE: [PATCH][v2] drivers: input: serio: Add a module desription to the hyperv_keyboard driver
From: Michael Kelley @ 2019-04-23 16:39 UTC (permalink / raw)
To: Joseph Salisbury, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, dmitry.torokhov@gmail.com
Cc: linux-hyperv@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <6a2c2e15e90138fcef67bed294d2e82d8d6f679b.1555967323.git.joseph.salisbury@microsoft.com>
From: Joseph Salisbury <joseph.salisbury@microsoft.com> Sent: Monday, April 22, 2019 8:47 PM
>
> This patch only adds a MODULE_DESCRIPTION statement to the driver.
> This change is only cosmetic, so there should be no runtime impact.
>
> Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
> ---
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
^ permalink raw reply
* [PATCH][v2] drivers: hv: Add a module description line to the hv_vmbus driver
From: Joseph Salisbury @ 2019-04-23 3:47 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Michael Kelley,
sashal@kernel.org
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
This patch only adds a MODULE_DESCRIPTION statement to the driver.
This change is only cosmetic, so there should be no runtime impact.
Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
---
drivers/hv/vmbus_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index aa25f3bcbdea..1cb9408b0d40 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -2174,6 +2174,7 @@ static void __exit vmbus_exit(void)
MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Microsoft Hyper-V VMBus Driver");
subsys_initcall(hv_acpi_init);
module_exit(vmbus_exit);
--
2.17.1
^ permalink raw reply related
* [PATCH][v2] drivers: input: serio: Add a module desription to the hyperv_keyboard driver
From: Joseph Salisbury @ 2019-04-23 3:47 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Michael Kelley,
sashal@kernel.org, dmitry.torokhov@gmail.com
Cc: linux-hyperv@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
This patch only adds a MODULE_DESCRIPTION statement to the driver.
This change is only cosmetic, so there should be no runtime impact.
Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
---
drivers/input/serio/hyperv-keyboard.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/serio/hyperv-keyboard.c b/drivers/input/serio/hyperv-keyboard.c
index a8b9be3e28db..7935e52b5435 100644
--- a/drivers/input/serio/hyperv-keyboard.c
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -440,5 +440,7 @@ static void __exit hv_kbd_exit(void)
}
MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Microsoft Hyper-V Synthetic Keyboard Driver");
+
module_init(hv_kbd_init);
module_exit(hv_kbd_exit);
--
2.17.1
^ permalink raw reply related
* [PATCH][v2] drivers: hid: Add a module description line to the hid_hyperv driver
From: Joseph Salisbury @ 2019-04-23 3:46 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Michael Kelley,
sashal@kernel.org, jikos@kernel.org,
benjamin.tissoires@redhat.com
Cc: linux-hyperv@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
This patch only adds a MODULE_DESCRIPTION statement to the driver.
This change is only cosmetic, so there should be no runtime impact.
Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
---
drivers/hid/hid-hyperv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
index 704049e62d58..d3311d714d35 100644
--- a/drivers/hid/hid-hyperv.c
+++ b/drivers/hid/hid-hyperv.c
@@ -614,5 +614,7 @@ static void __exit mousevsc_exit(void)
}
MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Microsoft Hyper-V Synthetic HID Driver");
+
module_init(mousevsc_init);
module_exit(mousevsc_exit);
--
2.17.1
^ permalink raw reply related
* RE: [PATCH] drivers: hid: Add a module description line
From: Joseph Salisbury @ 2019-04-23 3:25 UTC (permalink / raw)
To: Michael Kelley, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, jikos@kernel.org,
benjamin.tissoires@redhat.com
Cc: linux-hyperv@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <SN6PR2101MB092558880B017881591E41E2D7230@SN6PR2101MB0925.namprd21.prod.outlook.com>
Thanks for the feedback. I'll probably update each patch subject with the module names as well. I'll send a v2 for all three.
Thanks,
Joe
-----Original Message-----
From: Michael Kelley <mikelley@microsoft.com>
Sent: Monday, April 22, 2019 11:16 PM
To: Joseph Salisbury <Joseph.Salisbury@microsoft.com>; KY Srinivasan <kys@microsoft.com>; Haiyang Zhang <haiyangz@microsoft.com>; Stephen Hemminger <sthemmin@microsoft.com>; sashal@kernel.org; jikos@kernel.org; benjamin.tissoires@redhat.com
Cc: linux-hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: RE: [PATCH] drivers: hid: Add a module description line
From: Joseph Salisbury <Joseph.Salisbury@microsoft.com> Sent: Monday, April 22, 2019 2:31 PM
>
> Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
> ---
> drivers/hid/hid-hyperv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c index
> 704049e62d58..d3311d714d35 100644
> --- a/drivers/hid/hid-hyperv.c
> +++ b/drivers/hid/hid-hyperv.c
> @@ -614,5 +614,7 @@ static void __exit mousevsc_exit(void) }
>
> MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Microsoft Hyper-V Synthetic HID Driver");
> +
> module_init(mousevsc_init);
> module_exit(mousevsc_exit);
> --
> 2.17.1
Even though it will likely be redundant with the commit title, there
probably needs to be a short commit message. (And also with the
other two similar patches.)
Michael
^ permalink raw reply
* RE: [PATCH] drivers: hid: Add a module description line
From: Michael Kelley @ 2019-04-23 3:15 UTC (permalink / raw)
To: Joseph Salisbury, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, jikos@kernel.org,
benjamin.tissoires@redhat.com
Cc: linux-hyperv@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <324016691a62a13ce46c9ccd35c7e492bf609fd6.1555967348.git.joseph.salisbury@microsoft.com>
From: Joseph Salisbury <Joseph.Salisbury@microsoft.com> Sent: Monday, April 22, 2019 2:31 PM
>
> Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
> ---
> drivers/hid/hid-hyperv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
> index 704049e62d58..d3311d714d35 100644
> --- a/drivers/hid/hid-hyperv.c
> +++ b/drivers/hid/hid-hyperv.c
> @@ -614,5 +614,7 @@ static void __exit mousevsc_exit(void)
> }
>
> MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Microsoft Hyper-V Synthetic HID Driver");
> +
> module_init(mousevsc_init);
> module_exit(mousevsc_exit);
> --
> 2.17.1
Even though it will likely be redundant with the commit title, there
probably needs to be a short commit message. (And also with the
other two similar patches.)
Michael
^ permalink raw reply
* [PATCH] drivers: hv: Add a module description line
From: Joseph Salisbury @ 2019-04-22 21:39 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Michael Kelley,
sashal@kernel.org
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
---
drivers/hv/vmbus_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index aa25f3bcbdea..1cb9408b0d40 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -2174,6 +2174,7 @@ static void __exit vmbus_exit(void)
MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Microsoft Hyper-V VMBus Driver");
subsys_initcall(hv_acpi_init);
module_exit(vmbus_exit);
--
2.17.1
^ permalink raw reply related
* [PATCH] drivers: input: serio: Add a module desription
From: Joseph Salisbury @ 2019-04-22 21:38 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Michael Kelley,
sashal@kernel.org, dmitry.torokhov@gmail.com
Cc: linux-hyperv@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
---
drivers/input/serio/hyperv-keyboard.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/serio/hyperv-keyboard.c b/drivers/input/serio/hyperv-keyboard.c
index a8b9be3e28db..7935e52b5435 100644
--- a/drivers/input/serio/hyperv-keyboard.c
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -440,5 +440,7 @@ static void __exit hv_kbd_exit(void)
}
MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Microsoft Hyper-V Synthetic Keyboard Driver");
+
module_init(hv_kbd_init);
module_exit(hv_kbd_exit);
--
2.17.1
^ permalink raw reply related
* [PATCH] drivers: hid: Add a module description line
From: Joseph Salisbury @ 2019-04-22 21:31 UTC (permalink / raw)
To: KY Srinivasan, Haiyang Zhang, Stephen Hemminger, Michael Kelley,
sashal@kernel.org, jikos@kernel.org,
benjamin.tissoires@redhat.com
Cc: linux-hyperv@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
Signed-off-by: Joseph Salisbury <joseph.salisbury@microsoft.com>
---
drivers/hid/hid-hyperv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
index 704049e62d58..d3311d714d35 100644
--- a/drivers/hid/hid-hyperv.c
+++ b/drivers/hid/hid-hyperv.c
@@ -614,5 +614,7 @@ static void __exit mousevsc_exit(void)
}
MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Microsoft Hyper-V Synthetic HID Driver");
+
module_init(mousevsc_init);
module_exit(mousevsc_exit);
--
2.17.1
^ permalink raw reply related
* Re: [GIT PULL] Hyper-V commits for 5.1
From: Sasha Levin @ 2019-04-22 13:25 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-hyperv, kys, haiyangz, sthemmin, linux-kernel
In-Reply-To: <20190417124157.GA28651@sasha-vm>
ping?
On Wed, Apr 17, 2019 at 08:41:57AM -0400, Sasha Levin wrote:
>On Wed, Apr 17, 2019 at 08:28:54AM +0200, Greg KH wrote:
>>On Tue, Apr 16, 2019 at 09:34:51PM -0400, Sasha Levin wrote:
>>> 2. Fix to show monitor data only when monitor pages are actually
>>>allocated, also by Kimberly Brown.
>>
>>That's not really a "fix", more like a "new feature", right?
>
>This is (sadly) a fix; we access invalid memory or leak kernel memory to
>userspace if we access the monitor sysfs files when there are no monitor
>pages allocated.
>
>>> drivers/hv/vmbus_drv.c | 166 +++++++++++++++++++++++++------
>>A patch this big so late in the release cycle is not good.
>
>Indeed, but I've had it in my queue for a few weeks now so it's been
>receiving a good amount of testing - it's not something we came up with
>a few days ago.
>
>>Can you drop this one and resend the others? If you sent this as a
>>patch series, I could have done it that way on my own :)
>
>I would prefer if you could take it in. While it's on the bigger side, a
>lot of it is documentation (and comments!), and the code itself is
>straightforward and was well reviewed over 6 iterations of the original
>patch.
>
>--
>Thanks,
>Sasha
^ permalink raw reply
* [PATCH 4.19 045/110] x86/hyperv: Prevent potential NULL pointer dereference
From: Greg Kroah-Hartman @ 2019-04-18 17:56 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kangjie Lu, Thomas Gleixner,
Mukesh Ojha, K. Y. Srinivasan, pakki001, Haiyang Zhang,
Stephen Hemminger, Sasha Levin, Borislav Petkov, H. Peter Anvin,
linux-hyperv
In-Reply-To: <20190418160437.484158340@linuxfoundation.org>
[ Upstream commit 534c89c22e26b183d838294f0937ee092c82ad3a ]
The page allocation in hv_cpu_init() can fail, but the code does not
have a check for that.
Add a check and return -ENOMEM when the allocation fails.
[ tglx: Massaged changelog ]
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Acked-by: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: pakki001@umn.edu
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-hyperv@vger.kernel.org
Link: https://lkml.kernel.org/r/20190314054651.1315-1-kjlu@umn.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/hyperv/hv_init.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 87abd5145cc9..3fb855155286 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -101,9 +101,13 @@ static int hv_cpu_init(unsigned int cpu)
u64 msr_vp_index;
struct hv_vp_assist_page **hvp = &hv_vp_assist_page[smp_processor_id()];
void **input_arg;
+ struct page *pg;
input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
- *input_arg = page_address(alloc_page(GFP_KERNEL));
+ pg = alloc_page(GFP_KERNEL);
+ if (unlikely(!pg))
+ return -ENOMEM;
+ *input_arg = page_address(pg);
hv_get_vp_index(msr_vp_index);
--
2.19.1
^ permalink raw reply related
* [PATCH 5.0 57/93] x86/hyperv: Prevent potential NULL pointer dereference
From: Greg Kroah-Hartman @ 2019-04-18 17:57 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kangjie Lu, Thomas Gleixner,
Mukesh Ojha, K. Y. Srinivasan, pakki001, Haiyang Zhang,
Stephen Hemminger, Sasha Levin, Borislav Petkov, H. Peter Anvin,
linux-hyperv
In-Reply-To: <20190418160436.781762249@linuxfoundation.org>
[ Upstream commit 534c89c22e26b183d838294f0937ee092c82ad3a ]
The page allocation in hv_cpu_init() can fail, but the code does not
have a check for that.
Add a check and return -ENOMEM when the allocation fails.
[ tglx: Massaged changelog ]
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Acked-by: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: pakki001@umn.edu
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-hyperv@vger.kernel.org
Link: https://lkml.kernel.org/r/20190314054651.1315-1-kjlu@umn.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/hyperv/hv_init.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index d3f42b6bbdac..8a9cff1f129d 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -102,9 +102,13 @@ static int hv_cpu_init(unsigned int cpu)
u64 msr_vp_index;
struct hv_vp_assist_page **hvp = &hv_vp_assist_page[smp_processor_id()];
void **input_arg;
+ struct page *pg;
input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
- *input_arg = page_address(alloc_page(GFP_KERNEL));
+ pg = alloc_page(GFP_KERNEL);
+ if (unlikely(!pg))
+ return -ENOMEM;
+ *input_arg = page_address(pg);
hv_get_vp_index(msr_vp_index);
--
2.19.1
^ permalink raw reply related
* Re: [GIT PULL] Hyper-V commits for 5.1
From: Sasha Levin @ 2019-04-17 12:41 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-hyperv, kys, haiyangz, sthemmin, linux-kernel
In-Reply-To: <20190417062854.GA24045@kroah.com>
On Wed, Apr 17, 2019 at 08:28:54AM +0200, Greg KH wrote:
>On Tue, Apr 16, 2019 at 09:34:51PM -0400, Sasha Levin wrote:
>> 2. Fix to show monitor data only when monitor pages are actually
>> allocated, also by Kimberly Brown.
>
>That's not really a "fix", more like a "new feature", right?
This is (sadly) a fix; we access invalid memory or leak kernel memory to
userspace if we access the monitor sysfs files when there are no monitor
pages allocated.
>> drivers/hv/vmbus_drv.c | 166 +++++++++++++++++++++++++------
>A patch this big so late in the release cycle is not good.
Indeed, but I've had it in my queue for a few weeks now so it's been
receiving a good amount of testing - it's not something we came up with
a few days ago.
>Can you drop this one and resend the others? If you sent this as a
>patch series, I could have done it that way on my own :)
I would prefer if you could take it in. While it's on the bigger side, a
lot of it is documentation (and comments!), and the code itself is
straightforward and was well reviewed over 6 iterations of the original
patch.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [GIT PULL] Hyper-V commits for 5.1
From: Greg KH @ 2019-04-17 6:28 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, linux-hyperv, kys, haiyangz, sthemmin, linux-kernel
In-Reply-To: <20190417013452.438FA20821@mail.kernel.org>
On Tue, Apr 16, 2019 at 09:34:51PM -0400, Sasha Levin wrote:
> 2. Fix to show monitor data only when monitor pages are actually
> allocated, also by Kimberly Brown.
That's not really a "fix", more like a "new feature", right?
> drivers/hv/vmbus_drv.c | 166 +++++++++++++++++++++++++------
A patch this big so late in the release cycle is not good.
Can you drop this one and resend the others? If you sent this as a
patch series, I could have done it that way on my own :)
thanks,
greg k-h
^ permalink raw reply
* [GIT PULL] Hyper-V commits for 5.1
From: Sasha Levin @ 2019-04-17 1:34 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-hyperv, kys, haiyangz, sthemmin, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-fixes-signed
for you to fetch changes up to a0033bd1eae4650b69be07c17cb87393da584563:
Drivers: hv: vmbus: Remove the undesired put_cpu_ptr() in hv_synic_cleanup() (2019-04-13 09:36:35 -0400)
- ----------------------------------------------------------------
Three fixes:
1. Fix for a race condition in the hyper-v ringbuffer code by Kimberly
Brown.
2. Fix to show monitor data only when monitor pages are actually
allocated, also by Kimberly Brown.
3. Fix cpu reference counting in the vmbus code by Dexuan Cui.
- ----------------------------------------------------------------
Dexuan Cui (1):
Drivers: hv: vmbus: Remove the undesired put_cpu_ptr() in hv_synic_cleanup()
Kimberly Brown (4):
Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
Drivers: hv: vmbus: Refactor chan->state if statement
Drivers: hv: vmbus: Set ring_info field to 0 and remove memset
Drivers: hv: vmbus: Fix race condition with new ring_buffer_info mutex
Documentation/ABI/stable/sysfs-bus-vmbus | 12 ++-
drivers/hv/channel_mgmt.c | 3 +
drivers/hv/hv.c | 1 -
drivers/hv/hyperv_vmbus.h | 3 +
drivers/hv/ring_buffer.c | 22 +++-
drivers/hv/vmbus_drv.c | 166 +++++++++++++++++++++++++------
include/linux/hyperv.h | 7 +-
7 files changed, 175 insertions(+), 39 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAly2gjwACgkQ3qZv95d3
LNwtLg//UPVpBuilk7pzyumaEYNNeVcq781h/cghAOxiTDPlCI/qAkshdPj9ePAI
UWmBl/lUTXWcN26Xb2NLF9VulXfTFCiphQdgYMQEVslnOvbYLMLkIOOkrkovT6ie
OE5x1j+2S2uF+nwZvLq+FYuS5OiCBx8De1HaCUJQjh1dnrcdjCBTk+idE12tdqa6
pXO32CBKLUK0AEo9yHfeyg9RRsXV89u0wDEOhS160sqx5B6o1TevGOxkPDDQKrKG
mo80aY17MV3ljcODt4pqCNz1rITV6wwZ2oTz1sEv+5nMsqGZ9dcpXYQiQp0huaVl
/j4v/xY9gUDhGYvixoT8Mn87zc7y0y6o+VMcoM7YO7NJkbDA3XN6UaGzXdon061U
w25JBpWdHmot+5PxNafp708V7OBcWpbCoEFhSKvzKcYZlnGo4OA0om966v1WsW2K
ssXEPS4qdwtRM1dyK9c/Lt9HgaZWXzpIzj2bMxVjYPMeAmOd6W0QlfnuZuxYHmRd
aoZswMwFiC2lyOoHtbo50EzeKLwxVju+ToHFTf2jRXnjsLvDXkE6FmX9DSYnwvnE
Vs5qCvW8ynOPhTWAn6eKl0Ysb12+m36w+MEol7JTUlw4XPw7ahHsuxsN4TJQnshD
mZYG2Mrc38B/YOytT0asT5Z9U5ob9U7446I2Rn3XbdjVs9EEBAA=
=gXIY
-----END PGP SIGNATURE-----
^ permalink raw reply
* RE: [PATCH] x86/hyper-v: implement EOI assist
From: Long Li @ 2019-04-16 0:21 UTC (permalink / raw)
To: vkuznets, Simon Xiao
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, KY Srinivasan,
Haiyang Zhang, Stephen Hemminger, Sasha Levin, Michael Kelley,
linux-hyperv@vger.kernel.org
In-Reply-To: <87v9zfh2rr.fsf@vitty.brq.redhat.com>
>>>Subject: Re: [PATCH] x86/hyper-v: implement EOI assist
>>>
>>>Vitaly Kuznetsov <vkuznets@redhat.com> writes:
>>>
>>>> Hyper-V TLFS suggests an optimization to avoid imminent VMExit on EOI:
>>>> "The OS performs an EOI by atomically writing zero to the EOI Assist
>>>> field of the virtual VP assist page and checking whether the "No EOI
>>>required"
>>>> field was previously zero. If it was, the OS must write to the
>>>> HV_X64_APIC_EOI MSR thereby triggering an intercept into the
>>>hypervisor."
>>>>
>>>> Implement the optimization in Linux.
>>>>
>>>
>>>Simon, Long,
>>>
>>>did you get a chance to run some tests with this?
I have ran some tests on Azure L80s_v2.
With 10 NVMe disks on raid0 and formatted to EXT4, I'm getting 2.6m max IOPS with the patch, compared to 2.55m IOPS before.
The VM has been running stable. Thank you!
Tested-by: Long Li <longli@microsoft.com>
>>>
>>>--
>>>Vitaly
^ permalink raw reply
* Re: [PATCH] x86/hyper-v: implement EOI assist
From: Vitaly Kuznetsov @ 2019-04-15 12:27 UTC (permalink / raw)
To: Long Li, Simon Xiao
Cc: x86, linux-kernel, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, Sasha Levin, Michael Kelley (EOSG),
linux-hyperv
In-Reply-To: <20190403170309.4107-1-vkuznets@redhat.com>
Vitaly Kuznetsov <vkuznets@redhat.com> writes:
> Hyper-V TLFS suggests an optimization to avoid imminent VMExit on EOI:
> "The OS performs an EOI by atomically writing zero to the EOI Assist field
> of the virtual VP assist page and checking whether the "No EOI required"
> field was previously zero. If it was, the OS must write to the
> HV_X64_APIC_EOI MSR thereby triggering an intercept into the hypervisor."
>
> Implement the optimization in Linux.
>
Simon, Long,
did you get a chance to run some tests with this?
--
Vitaly
^ permalink raw reply
* Re: [PATCH 2/6] x86: hv: hv_init.c: Replace alloc_page() with kmem_cache_alloc()
From: Vitaly Kuznetsov @ 2019-04-12 7:52 UTC (permalink / raw)
To: Maya Nakamura
Cc: mikelley, kys, haiyangz, sthemmin, sashal, x86, linux-hyperv,
linux-kernel
In-Reply-To: <20190412072401.GA69620@maya190131.isni1t2eisqetojrdim5hhf1se.xx.internal.cloudapp.net>
Maya Nakamura <m.maya.nakamura@gmail.com> writes:
> On Fri, Apr 05, 2019 at 01:31:02PM +0200, Vitaly Kuznetsov wrote:
>> Maya Nakamura <m.maya.nakamura@gmail.com> writes:
>>
>> > @@ -98,18 +99,20 @@ EXPORT_SYMBOL_GPL(hyperv_pcpu_input_arg);
>> > u32 hv_max_vp_index;
>> > EXPORT_SYMBOL_GPL(hv_max_vp_index);
>> >
>> > +struct kmem_cache *cachep;
>> > +EXPORT_SYMBOL_GPL(cachep);
>> > +
>> > static int hv_cpu_init(unsigned int cpu)
>> > {
>> > u64 msr_vp_index;
>> > struct hv_vp_assist_page **hvp = &hv_vp_assist_page[smp_processor_id()];
>> > void **input_arg;
>> > - struct page *pg;
>> >
>> > input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
>> > - pg = alloc_page(GFP_KERNEL);
>> > - if (unlikely(!pg))
>> > + *input_arg = kmem_cache_alloc(cachep, GFP_KERNEL);
>>
>> I'm not sure use of kmem_cache is justified here: pages we allocate are
>> not cache-line and all these allocations are supposed to persist for the
>> lifetime of the guest. In case you think that even on x86 it will be
>> possible to see PAGE_SIZE != HV_HYP_PAGE_SIZE you can use alloc_pages()
>> instead.
>>
> Thank you for your feedback, Vitaly!
>
> Will you please tell me how cache-line relates to kmem_cache?
>
> I understand that alloc_pages() would work when PAGE_SIZE <=
> HV_HYP_PAGE_SIZE, but I think that it would not work if PAGE_SIZE >
> HV_HYP_PAGE_SIZE.
Sorry, my bad: I meant to say "not cache-like" (these allocations are
not 'cache') but the typo made it completely incomprehensible.
>
>> Also, in case the idea is to generalize stuff, what will happen if
>> PAGE_SIZE > HV_HYP_PAGE_SIZE? Who will guarantee proper alignment?
>>
>> I think we can leave hypercall arguments, vp_assist and similar pages
>> alone for now: the code is not going to be shared among architectures
>> anyways.
>>
> About the alignment, kmem_cache_create() aligns memory with its third
> parameter, offset.
Yes, I know, I was trying to think about a (hypothetical) situation when
page sizes differ: what would be the memory alignment requirements from
the hypervisor for e.g. hypercall arguments? In case it's always
HV_HYP_PAGE_SIZE we're good but could it be PAGE_SIZE (for e.g. TLB
flush hypercall)? I don't know. For x86 this discussion probably makes
no sense. I'm, however, struggling to understand what benefit we will
get from the change. Maybe just leave it as-is for now and fix
arch-independent code only? And later, if we decide to generalize this
code, make another approach? (Not insisting, just a suggestion)
>
>> > @@ -338,7 +349,10 @@ void __init hyperv_init(void)
>> > guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
>> > wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
>> >
>> > - hv_hypercall_pg = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
>> > + hv_hypercall_pg = kmem_cache_alloc(cachep, GFP_KERNEL);
>> > + if (hv_hypercall_pg)
>> > + set_memory_x((unsigned long)hv_hypercall_pg, 1);
>>
>> _RX is not writeable, right?
>>
> Yes, you are correct. I should use set_memory_ro() in addition to
> set_memory_x().
>
>> > @@ -416,6 +431,7 @@ void hyperv_cleanup(void)
>> > * let hypercall operations fail safely rather than
>> > * panic the kernel for using invalid hypercall page
>> > */
>> > + kmem_cache_free(cachep, hv_hypercall_pg);
>>
>> Please don't do that: hyperv_cleanup() is called on kexec/kdump and
>> we're trying to do the bare minimum to allow next kernel to boot. Doing
>> excessive work here will likely lead to consequent problems (we're
>> already crashing the case it's kdump!).
>>
> Thank you for the explanation! I will remove that.
>
--
Vitaly
^ permalink raw reply
* Re: [PATCH 2/6] x86: hv: hv_init.c: Replace alloc_page() with kmem_cache_alloc()
From: Maya Nakamura @ 2019-04-12 7:24 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: mikelley, kys, haiyangz, sthemmin, sashal, x86, linux-hyperv,
linux-kernel
In-Reply-To: <87wok8it8p.fsf@vitty.brq.redhat.com>
On Fri, Apr 05, 2019 at 01:31:02PM +0200, Vitaly Kuznetsov wrote:
> Maya Nakamura <m.maya.nakamura@gmail.com> writes:
>
> > @@ -98,18 +99,20 @@ EXPORT_SYMBOL_GPL(hyperv_pcpu_input_arg);
> > u32 hv_max_vp_index;
> > EXPORT_SYMBOL_GPL(hv_max_vp_index);
> >
> > +struct kmem_cache *cachep;
> > +EXPORT_SYMBOL_GPL(cachep);
> > +
> > static int hv_cpu_init(unsigned int cpu)
> > {
> > u64 msr_vp_index;
> > struct hv_vp_assist_page **hvp = &hv_vp_assist_page[smp_processor_id()];
> > void **input_arg;
> > - struct page *pg;
> >
> > input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
> > - pg = alloc_page(GFP_KERNEL);
> > - if (unlikely(!pg))
> > + *input_arg = kmem_cache_alloc(cachep, GFP_KERNEL);
>
> I'm not sure use of kmem_cache is justified here: pages we allocate are
> not cache-line and all these allocations are supposed to persist for the
> lifetime of the guest. In case you think that even on x86 it will be
> possible to see PAGE_SIZE != HV_HYP_PAGE_SIZE you can use alloc_pages()
> instead.
>
Thank you for your feedback, Vitaly!
Will you please tell me how cache-line relates to kmem_cache?
I understand that alloc_pages() would work when PAGE_SIZE <=
HV_HYP_PAGE_SIZE, but I think that it would not work if PAGE_SIZE >
HV_HYP_PAGE_SIZE.
> Also, in case the idea is to generalize stuff, what will happen if
> PAGE_SIZE > HV_HYP_PAGE_SIZE? Who will guarantee proper alignment?
>
> I think we can leave hypercall arguments, vp_assist and similar pages
> alone for now: the code is not going to be shared among architectures
> anyways.
>
About the alignment, kmem_cache_create() aligns memory with its third
parameter, offset.
> > @@ -338,7 +349,10 @@ void __init hyperv_init(void)
> > guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
> > wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
> >
> > - hv_hypercall_pg = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
> > + hv_hypercall_pg = kmem_cache_alloc(cachep, GFP_KERNEL);
> > + if (hv_hypercall_pg)
> > + set_memory_x((unsigned long)hv_hypercall_pg, 1);
>
> _RX is not writeable, right?
>
Yes, you are correct. I should use set_memory_ro() in addition to
set_memory_x().
> > @@ -416,6 +431,7 @@ void hyperv_cleanup(void)
> > * let hypercall operations fail safely rather than
> > * panic the kernel for using invalid hypercall page
> > */
> > + kmem_cache_free(cachep, hv_hypercall_pg);
>
> Please don't do that: hyperv_cleanup() is called on kexec/kdump and
> we're trying to do the bare minimum to allow next kernel to boot. Doing
> excessive work here will likely lead to consequent problems (we're
> already crashing the case it's kdump!).
>
Thank you for the explanation! I will remove that.
^ permalink raw reply
* RE: [PATCH 4/6] x86: hv: mmu.c: Replace page definitions with Hyper-V specific ones
From: Vitaly Kuznetsov @ 2019-04-12 6:58 UTC (permalink / raw)
To: Michael Kelley, m.maya.nakamura
Cc: x86@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, KY Srinivasan, Haiyang Zhang,
Stephen Hemminger, sashal@kernel.org
In-Reply-To: <DM5PR2101MB091843B6DD7A11C2C27917F1D7280@DM5PR2101MB0918.namprd21.prod.outlook.com>
Michael Kelley <mikelley@microsoft.com> writes:
> From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Friday, April 5, 2019 4:11 AM
>> >
>> > @@ -32,15 +32,15 @@ static inline int fill_gva_list(u64 gva_list[], int offset,
>> > do {
>> > diff = end > cur ? end - cur : 0;
>> >
>> > - gva_list[gva_n] = cur & PAGE_MASK;
>> > + gva_list[gva_n] = cur & HV_HYP_PAGE_MASK;
>>
>> I'm not sure this is correct: here we're expressing guest virtual
>> addresses in need of flushing, this should be unrelated to the
>> hypervisor page size.
>>
>
> I talked to the Hyper-V guys about this. They have not implemented
> the HvFlushVirtualAddressList hypercalls for ARM64 yet. But when they
> do, they expect the GVA list will need to be in terms of the Hyper-V
> page size. They don't want to have to figure out the guest page size
> and adjust their arithmetic on a per-guest basis.
Understood, thanks! However, what I wanted to say is that this code is
x86-specific (arch/x86/hyperv/mmu.c) and the implementation is
hard-wired to the spec, namely we use lower 12 bits (there's even a
comment in the code about this which the patch doesn't change) to encode
the number of pages to flush. We can speculate that when these
hypercalls are implemented on ARM they'll have similar requirements but
I'd suggest we leave it as-is for now and fix this when (and, actually,
if) we decide to move this to arch-independent part. We may need to do
additional adjustments - and we don't know about them yet because
there's no spec published.
--
Vitaly
^ permalink raw reply
* Re: [PATCH v3 0/3] Drivers: hv: vmbus: Fix a race condition in "_show" functions
From: Sasha Levin @ 2019-04-10 22:59 UTC (permalink / raw)
To: Kimberly Brown
Cc: Michael Kelley, Long Li, Sasha Levin, Stephen Hemminger,
Dexuan Cui, K. Y. Srinivasan, Haiyang Zhang, linux-hyperv,
linux-kernel
In-Reply-To: <cover.1552592620.git.kimbrownkd@gmail.com>
On Thu, Mar 14, 2019 at 04:04:52PM -0400, Kimberly Brown wrote:
>This patchset fixes a race condition in the "_show" functions that
>access the channel ring buffers.
>
>Changes in v3:
>Patch 1: Drivers: hv: vmbus: Refactor chan->state if statement
> - Added the “reviewed-by” line from v2.
>
>Patch 2: Drivers: hv: vmbus: Set ring_info field to 0 and remove memset
> - This patch is new. This change allows the new mutex locks in patch 3
> to be initialized when the channel is initialized.
>
>Patch 3: Drivers: hv: vmbus: Fix race condition with new
> ring_buffer_info mutex
> - Added two ring buffer info mutex locks instead of the single channel
> mutex lock that was proposed in v2.
> - Changed the mutex acquire/release calls as needed for the new ring
> buffer info mutex locks.
> - Updated the commit message.
>
>
>Changes in v2:
> - In v1, I proposed using “vmbus_connection.channel_mutex” in the
> “_show” functions to prevent the race condition. However, using this
> mutex could result in a deadlock, so a new approach is proposed in
> this patchset.
> - Patch 1 is new and consists of refactoring an if statement.
> - Patch 2 introduces a new mutex lock in the “vmbus_channel” struct,
> which is used to eliminate the race condition.
>
>Kimberly Brown (3):
> Drivers: hv: vmbus: Refactor chan->state if statement
> Drivers: hv: vmbus: Set ring_info field to 0 and remove memset
> Drivers: hv: vmbus: Fix race condition with new ring_buffer_info mutex
>
> drivers/hv/channel_mgmt.c | 2 +
> drivers/hv/hyperv_vmbus.h | 1 +
> drivers/hv/ring_buffer.c | 22 ++++++++--
> drivers/hv/vmbus_drv.c | 89 +++++++++++++++++++++++++++------------
> include/linux/hyperv.h | 7 ++-
> 5 files changed, 88 insertions(+), 33 deletions(-)
Queued up, thanks Kimberly!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 2/6] x86: hv: hv_init.c: Replace alloc_page() with kmem_cache_alloc()
From: Vitaly Kuznetsov @ 2019-04-05 11:31 UTC (permalink / raw)
To: Maya Nakamura, mikelley, kys, haiyangz, sthemmin, sashal
Cc: x86, linux-hyperv, linux-kernel
In-Reply-To: <bdbacc872e369762a877af4415ad1b07054826db.1554426040.git.m.maya.nakamura@gmail.com>
Maya Nakamura <m.maya.nakamura@gmail.com> writes:
> Switch from the function that allocates a single Linux guest page to a
> different one to use a Hyper-V page because the guest page size and
> hypervisor page size concepts are different, even though they happen to
> be the same value on x86.
>
> Signed-off-by: Maya Nakamura <m.maya.nakamura@gmail.com>
> ---
> arch/x86/hyperv/hv_init.c | 38 +++++++++++++++++++++++++++-----------
> 1 file changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index e4ba467a9fc6..5f946135aa18 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -31,6 +31,7 @@
> #include <linux/hyperv.h>
> #include <linux/slab.h>
> #include <linux/cpuhotplug.h>
> +#include <asm/set_memory.h>
>
> #ifdef CONFIG_HYPERV_TSCPAGE
>
> @@ -98,18 +99,20 @@ EXPORT_SYMBOL_GPL(hyperv_pcpu_input_arg);
> u32 hv_max_vp_index;
> EXPORT_SYMBOL_GPL(hv_max_vp_index);
>
> +struct kmem_cache *cachep;
> +EXPORT_SYMBOL_GPL(cachep);
> +
> static int hv_cpu_init(unsigned int cpu)
> {
> u64 msr_vp_index;
> struct hv_vp_assist_page **hvp = &hv_vp_assist_page[smp_processor_id()];
> void **input_arg;
> - struct page *pg;
>
> input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
> - pg = alloc_page(GFP_KERNEL);
> - if (unlikely(!pg))
> + *input_arg = kmem_cache_alloc(cachep, GFP_KERNEL);
I'm not sure use of kmem_cache is justified here: pages we allocate are
not cache-line and all these allocations are supposed to persist for the
lifetime of the guest. In case you think that even on x86 it will be
possible to see PAGE_SIZE != HV_HYP_PAGE_SIZE you can use alloc_pages()
instead.
Also, in case the idea is to generalize stuff, what will happen if
PAGE_SIZE > HV_HYP_PAGE_SIZE? Who will guarantee proper alignment?
I think we can leave hypercall arguments, vp_assist and similar pages
alone for now: the code is not going to be shared among architectures
anyways.
> +
> + if (unlikely(!*input_arg))
> return -ENOMEM;
> - *input_arg = page_address(pg);
>
> hv_get_vp_index(msr_vp_index);
>
> @@ -122,14 +125,12 @@ static int hv_cpu_init(unsigned int cpu)
> return 0;
>
> if (!*hvp)
> - *hvp = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL);
> + *hvp = kmem_cache_alloc(cachep, GFP_KERNEL);
>
> if (*hvp) {
> u64 val;
>
> - val = vmalloc_to_pfn(*hvp);
> - val = (val << HV_X64_MSR_VP_ASSIST_PAGE_ADDRESS_SHIFT) |
> - HV_X64_MSR_VP_ASSIST_PAGE_ENABLE;
> + val = virt_to_phys(*hvp) | HV_X64_MSR_VP_ASSIST_PAGE_ENABLE;
>
> wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE, val);
> }
> @@ -233,17 +234,22 @@ static int hv_cpu_die(unsigned int cpu)
> unsigned long flags;
> void **input_arg;
> void *input_pg = NULL;
> + struct hv_vp_assist_page **hvp = &hv_vp_assist_page[cpu];
>
> local_irq_save(flags);
> input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
> input_pg = *input_arg;
> *input_arg = NULL;
> local_irq_restore(flags);
> - free_page((unsigned long)input_pg);
> + kmem_cache_free(cachep, input_pg);
> + input_pg = NULL;
>
> if (hv_vp_assist_page && hv_vp_assist_page[cpu])
> wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE, 0);
>
> + kmem_cache_free(cachep, *hvp);
> + *hvp = NULL;
> +
> if (hv_reenlightenment_cb == NULL)
> return 0;
>
> @@ -325,6 +331,11 @@ void __init hyperv_init(void)
> goto free_vp_index;
> }
>
> + cachep = kmem_cache_create("hyperv_pages", HV_HYP_PAGE_SIZE,
> + HV_HYP_PAGE_SIZE, 0, NULL);
> + if (!cachep)
> + goto free_vp_assist_page;
> +
> cpuhp = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/hyperv_init:online",
> hv_cpu_init, hv_cpu_die);
> if (cpuhp < 0)
> @@ -338,7 +349,10 @@ void __init hyperv_init(void)
> guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
> wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
>
> - hv_hypercall_pg = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
> + hv_hypercall_pg = kmem_cache_alloc(cachep, GFP_KERNEL);
> + if (hv_hypercall_pg)
> + set_memory_x((unsigned long)hv_hypercall_pg, 1);
_RX is not writeable, right?
> +
> if (hv_hypercall_pg == NULL) {
> wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
> goto remove_cpuhp_state;
> @@ -346,7 +360,8 @@ void __init hyperv_init(void)
>
> rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> hypercall_msr.enable = 1;
> - hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
> + hypercall_msr.guest_physical_address = virt_to_phys(hv_hypercall_pg) >>
> + HV_HYP_PAGE_SHIFT;
> wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
>
> hv_apic_init();
> @@ -416,6 +431,7 @@ void hyperv_cleanup(void)
> * let hypercall operations fail safely rather than
> * panic the kernel for using invalid hypercall page
> */
> + kmem_cache_free(cachep, hv_hypercall_pg);
Please don't do that: hyperv_cleanup() is called on kexec/kdump and
we're trying to do the bare minimum to allow next kernel to boot. Doing
excessive work here will likely lead to consequent problems (we're
already crashing the case it's kdump!).
> hv_hypercall_pg = NULL;
>
> /* Reset the hypercall page */
--
Vitaly
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox