[v3 PATCH for-4.4 0/7] hv patches for 4.4.y (resubmit)

[v3 PATCH for-4.4 0/7] hv patches for 4.4.y (resubmit)

[Sumit Semwal]

Hi Greg,

>From my previous submission of patches for 4.4 from Ubuntu Xenial, dropping one
patch caused the patch right after to fail to apply; I've reworked the failing
patch. I've also included the remaining hv ones (that anyways apply cleanly) for
the sake of completion.

These apply cleanly on top of 4.4.62, and are build tested on 4.4.y with x86
allmodconfig. 

Best,
Sumit.

K. Y. Srinivasan (1):
  Drivers: hv: vmbus: Reduce the delay between retries in
    vmbus_post_msg()

Vitaly Kuznetsov (6):
  Drivers: hv: don't leak memory in vmbus_establish_gpadl()
  Drivers: hv: get rid of timeout in vmbus_open()
  Tools: hv: kvp: ensure kvp device fd is closed on exec
  Drivers: hv: balloon: keep track of where ha_region starts
  Drivers: hv: balloon: account for gaps in hot add regions
  hv: don't reset hv_context.tsc_page on crash

 drivers/hv/channel.c     |  16 +++---
 drivers/hv/connection.c  |   8 +--
 drivers/hv/hv.c          |   5 +-
 drivers/hv/hv_balloon.c  | 136 ++++++++++++++++++++++++++++++++++-------------
 tools/hv/hv_kvp_daemon.c |   2 +-
 5 files changed, 115 insertions(+), 52 deletions(-)

-- 
2.7.4

[v3 PATCH for-4.4 1/7] Drivers: hv: don't leak memory in vmbus_establish_gpadl()

[Sumit Semwal]

From: Vitaly Kuznetsov <vkuznets@redhat.com>

[ Upstream commit 7cc80c98070ccc7940fc28811c92cca0a681015d ]

In some cases create_gpadl_header() allocates submessages but we never
free them.

[sumits] Note for stable:
Upstream commit 4d63763296ab7865a98bc29cc7d77145815ef89f:
(Drivers: hv: get rid of redundant messagecount in create_gpadl_header())
changes the list usage to initialize list header in all cases; that patch
isn't added to stable, so the current patch is modified a little bit from
the upstream commit to check if the list is valid or not.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 drivers/hv/channel.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 1ef37c7..49d2449 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -375,7 +375,7 @@ int vmbus_establish_gpadl(struct vmbus_channel *channel, void *kbuffer,
 	struct vmbus_channel_gpadl_header *gpadlmsg;
 	struct vmbus_channel_gpadl_body *gpadl_body;
 	struct vmbus_channel_msginfo *msginfo = NULL;
-	struct vmbus_channel_msginfo *submsginfo;
+	struct vmbus_channel_msginfo *submsginfo, *tmp;
 	u32 msgcount;
 	struct list_head *curr;
 	u32 next_gpadl_handle;
@@ -437,6 +437,13 @@ cleanup:
 	list_del(&msginfo->msglistentry);
 	spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
 
+	if (msgcount > 1) {
+		list_for_each_entry_safe(submsginfo, tmp, &msginfo->submsglist,
+			 msglistentry) {
+			kfree(submsginfo);
+		}
+	}
+
 	kfree(msginfo);
 	return ret;
 }
-- 
2.7.4

[v3 PATCH for-4.4 2/7] Drivers: hv: get rid of timeout in vmbus_open()

[Sumit Semwal]

From: Vitaly Kuznetsov <vkuznets@redhat.com>

[ Upstream commit 396e287fa2ff46e83ae016cdcb300c3faa3b02f6 ]

vmbus_teardown_gpadl() can result in infinite wait when it is called on 5
second timeout in vmbus_open(). The issue is caused by the fact that gpadl
teardown operation won't ever succeed for an opened channel and the timeout
isn't always enough. As a guest, we can always trust the host to respond to
our request (and there is nothing we can do if it doesn't).

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 drivers/hv/channel.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 49d2449..d037454 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -73,7 +73,6 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 send_ringbuffer_size,
 	void *in, *out;
 	unsigned long flags;
 	int ret, err = 0;
-	unsigned long t;
 	struct page *page;
 
 	spin_lock_irqsave(&newchannel->lock, flags);
@@ -183,11 +182,7 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 send_ringbuffer_size,
 		goto error1;
 	}
 
-	t = wait_for_completion_timeout(&open_info->waitevent, 5*HZ);
-	if (t == 0) {
-		err = -ETIMEDOUT;
-		goto error1;
-	}
+	wait_for_completion(&open_info->waitevent);
 
 	spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
 	list_del(&open_info->msglistentry);
-- 
2.7.4

[v3 PATCH for-4.4 3/7] Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg()

[Sumit Semwal]

From: "K. Y. Srinivasan" <kys@microsoft.com>

[ Upstream commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 ]

The current delay between retries is unnecessarily high and is negatively
affecting the time it takes to boot the system.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 drivers/hv/connection.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 4fc2e88..2bbc530 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -429,7 +429,7 @@ int vmbus_post_msg(void *buffer, size_t buflen)
 	union hv_connection_id conn_id;
 	int ret = 0;
 	int retries = 0;
-	u32 msec = 1;
+	u32 usec = 1;
 
 	conn_id.asu32 = 0;
 	conn_id.u.id = VMBUS_MESSAGE_CONNECTION_ID;
@@ -462,9 +462,9 @@ int vmbus_post_msg(void *buffer, size_t buflen)
 		}
 
 		retries++;
-		msleep(msec);
-		if (msec < 2048)
-			msec *= 2;
+		udelay(usec);
+		if (usec < 2048)
+			usec *= 2;
 	}
 	return ret;
 }
-- 
2.7.4

Re: [v3 PATCH for-4.4 3/7] Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg()

[Ben Hutchings]

On Thu, 2017-04-20 at 13:08 +0530, Sumit Semwal wrote:
> From: "K. Y. Srinivasan" <kys@microsoft.com>
> 
> [ Upstream commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 ]
> 
> The current delay between retries is unnecessarily high and is negatively
> affecting the time it takes to boot the system.
> 
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[...]

Should this also be applied to 4.4?

commit c0bb03924f1a80e7f65900e36c8e6b3dc167c5f8
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Wed Dec 7 01:16:24 2016 -0800

    Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: [v3 PATCH for-4.4 3/7] Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg()

[Sumit Semwal]

Hi Ben,

On 9 May 2017 at 18:06, Ben Hutchings <ben.hutchings@codethink.co.uk> wrote:
> On Thu, 2017-04-20 at 13:08 +0530, Sumit Semwal wrote:
>> From: "K. Y. Srinivasan" <kys@microsoft.com>
>>
>> [ Upstream commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 ]
>>
>> The current delay between retries is unnecessarily high and is negatively
>> affecting the time it takes to boot the system.
>>
>> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
> [...]
>
> Should this also be applied to 4.4?
>
> commit c0bb03924f1a80e7f65900e36c8e6b3dc167c5f8
> Author: Vitaly Kuznetsov <vkuznets@redhat.com>
> Date:   Wed Dec 7 01:16:24 2016 -0800
>
>     Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()

I tried to rebase that to 4.4 code base, but 4.4 seems to require some
more patches to make it work - some of those patches might not fit the
stable requirements.

I'm not a hv expert, so didn't want to mess up, and hence didn't send it.

Best,
Sumit.
>
> Ben.
>
> --
> Ben Hutchings
> Software Developer, Codethink Ltd.
>
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs

Re: [v3 PATCH for-4.4 3/7] Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg()

[Ben Hutchings]

On Tue, 2017-05-09 at 18:11 +0530, Sumit Semwal wrote:
> Hi Ben,
> 
> On 9 May 2017 at 18:06, Ben Hutchings <ben.hutchings@codethink.co.uk> wrote:
> > On Thu, 2017-04-20 at 13:08 +0530, Sumit Semwal wrote:
> >> From: "K. Y. Srinivasan" <kys@microsoft.com>
> >>
> >> [ Upstream commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 ]
> >>
> >> The current delay between retries is unnecessarily high and is negatively
> >> affecting the time it takes to boot the system.
> >>
> >> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> >> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
> > [...]
> >
> > Should this also be applied to 4.4?
> >
> > commit c0bb03924f1a80e7f65900e36c8e6b3dc167c5f8
> > Author: Vitaly Kuznetsov <vkuznets@redhat.com>
> > Date:   Wed Dec 7 01:16:24 2016 -0800
> >
> >     Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()
> 
> I tried to rebase that to 4.4 code base, but 4.4 seems to require some
> more patches to make it work - some of those patches might not fit the
> stable requirements.
> 
> I'm not a hv expert, so didn't want to mess up, and hence didn't send it.

If it touches some functions that don't exist in 4.4, those parts could
just be dropped.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

RE: [v3 PATCH for-4.4 3/7] Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg()

[KY Srinivasan]

> -----Original Message-----
> From: Sumit Semwal [mailto:sumit.semwal@linaro.org]
> Sent: Tuesday, May 9, 2017 5:41 AM
> To: Ben Hutchings <ben.hutchings@codethink.co.uk>
> Cc: stable@vger.kernel.org; KY Srinivasan <kys@microsoft.com>; Greg
> Kroah-Hartman <gregkh@linuxfoundation.org>
> Subject: Re: [v3 PATCH for-4.4 3/7] Drivers: hv: vmbus: Reduce the delay
> between retries in vmbus_post_msg()
> 
> Hi Ben,
> 
> On 9 May 2017 at 18:06, Ben Hutchings <ben.hutchings@codethink.co.uk>
> wrote:
> > On Thu, 2017-04-20 at 13:08 +0530, Sumit Semwal wrote:
> >> From: "K. Y. Srinivasan" <kys@microsoft.com>
> >>
> >> [ Upstream commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 ]
> >>
> >> The current delay between retries is unnecessarily high and is negatively
> >> affecting the time it takes to boot the system.
> >>
> >> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> >> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
> > [...]
> >
> > Should this also be applied to 4.4?
> >
> > commit c0bb03924f1a80e7f65900e36c8e6b3dc167c5f8
> > Author: Vitaly Kuznetsov <vkuznets@redhat.com>
> > Date:   Wed Dec 7 01:16:24 2016 -0800
> >
> >     Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()
> 
> I tried to rebase that to 4.4 code base, but 4.4 seems to require some
> more patches to make it work - some of those patches might not fit the
> stable requirements.
> 
> I'm not a hv expert, so didn't want to mess up, and hence didn't send it.

I am not sure if all the needed changes will meet the stable requirements.

K. Y
> 
> Best,
> Sumit.
> >
> > Ben.
> >
> > --
> > Ben Hutchings
> > Software Developer, Codethink Ltd.
> >
> >
> 
> 
> 
> --
> Thanks and regards,
> 
> Sumit Semwal
> Linaro Mobile Group - Kernel Team Lead
> Linaro.org │ Open source software for ARM SoCs

[v3 PATCH for-4.4 4/7] Tools: hv: kvp: ensure kvp device fd is closed on exec

[Sumit Semwal]

From: Vitaly Kuznetsov <vkuznets@redhat.com>

[ Upstream commit 26840437cbd6d3625ea6ab34e17cd34bb810c861 ]

KVP daemon does fork()/exec() (with popen()) so we need to close our fds
to avoid sharing them with child processes. The immediate implication of
not doing so I see is SELinux complaining about 'ip' trying to access
'/dev/vmbus/hv_kvp'.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 tools/hv/hv_kvp_daemon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 0d9f48e..bc7adb8 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1433,7 +1433,7 @@ int main(int argc, char *argv[])
 	openlog("KVP", 0, LOG_USER);
 	syslog(LOG_INFO, "KVP starting; pid is:%d", getpid());
 
-	kvp_fd = open("/dev/vmbus/hv_kvp", O_RDWR);
+	kvp_fd = open("/dev/vmbus/hv_kvp", O_RDWR | O_CLOEXEC);
 
 	if (kvp_fd < 0) {
 		syslog(LOG_ERR, "open /dev/vmbus/hv_kvp failed; error: %d %s",
-- 
2.7.4

[v3 PATCH for-4.4 5/7] Drivers: hv: balloon: keep track of where ha_region starts

[Sumit Semwal]

From: Vitaly Kuznetsov <vkuznets@redhat.com>

[ Upstream commit 7cf3b79ec85ee1a5bbaaf936bb1d050dc652983b ]

Windows 2012 (non-R2) does not specify hot add region in hot add requests
and the logic in hot_add_req() is trying to find a 128Mb-aligned region
covering the request. It may also happen that host's requests are not 128Mb
aligned and the created ha_region will start before the first specified
PFN. We can't online these non-present pages but we don't remember the real
start of the region.

This is a regression introduced by the commit 5abbbb75d733 ("Drivers: hv:
hv_balloon: don't lose memory when onlining order is not natural"). While
the idea of keeping the 'moving window' was wrong (as there is no guarantee
that hot add requests come ordered) we should still keep track of
covered_start_pfn. This is not a revert, the logic is different.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 drivers/hv/hv_balloon.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 43af913..1542d89 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -430,13 +430,14 @@ struct dm_info_msg {
  * currently hot added. We hot add in multiples of 128M
  * chunks; it is possible that we may not be able to bring
  * online all the pages in the region. The range
- * covered_end_pfn defines the pages that can
+ * covered_start_pfn:covered_end_pfn defines the pages that can
  * be brough online.
  */
 
 struct hv_hotadd_state {
 	struct list_head list;
 	unsigned long start_pfn;
+	unsigned long covered_start_pfn;
 	unsigned long covered_end_pfn;
 	unsigned long ha_end_pfn;
 	unsigned long end_pfn;
@@ -682,7 +683,8 @@ static void hv_online_page(struct page *pg)
 
 	list_for_each(cur, &dm_device.ha_region_list) {
 		has = list_entry(cur, struct hv_hotadd_state, list);
-		cur_start_pgp = (unsigned long)pfn_to_page(has->start_pfn);
+		cur_start_pgp = (unsigned long)
+			pfn_to_page(has->covered_start_pfn);
 		cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn);
 
 		if (((unsigned long)pg >= cur_start_pgp) &&
@@ -854,6 +856,7 @@ static unsigned long process_hot_add(unsigned long pg_start,
 		list_add_tail(&ha_region->list, &dm_device.ha_region_list);
 		ha_region->start_pfn = rg_start;
 		ha_region->ha_end_pfn = rg_start;
+		ha_region->covered_start_pfn = pg_start;
 		ha_region->covered_end_pfn = pg_start;
 		ha_region->end_pfn = rg_start + rg_size;
 	}
-- 
2.7.4

[v3 PATCH for-4.4 6/7] Drivers: hv: balloon: account for gaps in hot add regions

[Sumit Semwal]

From: Vitaly Kuznetsov <vkuznets@redhat.com>

[ Upstream commit cb7a5724c7e1bfb5766ad1c3beba14cc715991cf ]

I'm observing the following hot add requests from the WS2012 host:

hot_add_req: start_pfn = 0x108200 count = 330752
hot_add_req: start_pfn = 0x158e00 count = 193536
hot_add_req: start_pfn = 0x188400 count = 239616

As the host doesn't specify hot add regions we're trying to create
128Mb-aligned region covering the first request, we create the 0x108000 -
0x160000 region and we add 0x108000 - 0x158e00 memory. The second request
passes the pfn_covered() check, we enlarge the region to 0x108000 -
0x190000 and add 0x158e00 - 0x188200 memory. The problem emerges with the
third request as it starts at 0x188400 so there is a 0x200 gap which is
not covered. As the end of our region is 0x190000 now it again passes the
pfn_covered() check were we just adjust the covered_end_pfn and make it
0x188400 instead of 0x188200 which means that we'll try to online
0x188200-0x188400 pages but these pages were never assigned to us and we
crash.

We can't react to such requests by creating new hot add regions as it may
happen that the whole suggested range falls into the previously identified
128Mb-aligned area so we'll end up adding nothing or create intersecting
regions and our current logic doesn't allow that. Instead, create a list of
such 'gaps' and check for them in the page online callback.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 drivers/hv/hv_balloon.c | 131 ++++++++++++++++++++++++++++++++++--------------
 1 file changed, 94 insertions(+), 37 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 1542d89..354da7f 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -441,6 +441,16 @@ struct hv_hotadd_state {
 	unsigned long covered_end_pfn;
 	unsigned long ha_end_pfn;
 	unsigned long end_pfn;
+	/*
+	 * A list of gaps.
+	 */
+	struct list_head gap_list;
+};
+
+struct hv_hotadd_gap {
+	struct list_head list;
+	unsigned long start_pfn;
+	unsigned long end_pfn;
 };
 
 struct balloon_state {
@@ -596,18 +606,46 @@ static struct notifier_block hv_memory_nb = {
 	.priority = 0
 };
 
+/* Check if the particular page is backed and can be onlined and online it. */
+static void hv_page_online_one(struct hv_hotadd_state *has, struct page *pg)
+{
+	unsigned long cur_start_pgp;
+	unsigned long cur_end_pgp;
+	struct hv_hotadd_gap *gap;
+
+	cur_start_pgp = (unsigned long)pfn_to_page(has->covered_start_pfn);
+	cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn);
 
-static void hv_bring_pgs_online(unsigned long start_pfn, unsigned long size)
+	/* The page is not backed. */
+	if (((unsigned long)pg < cur_start_pgp) ||
+	    ((unsigned long)pg >= cur_end_pgp))
+		return;
+
+	/* Check for gaps. */
+	list_for_each_entry(gap, &has->gap_list, list) {
+		cur_start_pgp = (unsigned long)
+			pfn_to_page(gap->start_pfn);
+		cur_end_pgp = (unsigned long)
+			pfn_to_page(gap->end_pfn);
+		if (((unsigned long)pg >= cur_start_pgp) &&
+		    ((unsigned long)pg < cur_end_pgp)) {
+			return;
+		}
+	}
+
+	/* This frame is currently backed; online the page. */
+	__online_page_set_limits(pg);
+	__online_page_increment_counters(pg);
+	__online_page_free(pg);
+}
+
+static void hv_bring_pgs_online(struct hv_hotadd_state *has,
+				unsigned long start_pfn, unsigned long size)
 {
 	int i;
 
-	for (i = 0; i < size; i++) {
-		struct page *pg;
-		pg = pfn_to_page(start_pfn + i);
-		__online_page_set_limits(pg);
-		__online_page_increment_counters(pg);
-		__online_page_free(pg);
-	}
+	for (i = 0; i < size; i++)
+		hv_page_online_one(has, pfn_to_page(start_pfn + i));
 }
 
 static void hv_mem_hot_add(unsigned long start, unsigned long size,
@@ -684,26 +722,24 @@ static void hv_online_page(struct page *pg)
 	list_for_each(cur, &dm_device.ha_region_list) {
 		has = list_entry(cur, struct hv_hotadd_state, list);
 		cur_start_pgp = (unsigned long)
-			pfn_to_page(has->covered_start_pfn);
-		cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn);
+			pfn_to_page(has->start_pfn);
+		cur_end_pgp = (unsigned long)pfn_to_page(has->end_pfn);
 
-		if (((unsigned long)pg >= cur_start_pgp) &&
-			((unsigned long)pg < cur_end_pgp)) {
-			/*
-			 * This frame is currently backed; online the
-			 * page.
-			 */
-			__online_page_set_limits(pg);
-			__online_page_increment_counters(pg);
-			__online_page_free(pg);
-		}
+		/* The page belongs to a different HAS. */
+		if (((unsigned long)pg < cur_start_pgp) ||
+		    ((unsigned long)pg >= cur_end_pgp))
+			continue;
+
+		hv_page_online_one(has, pg);
+		break;
 	}
 }
 
-static bool pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
+static int pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
 {
 	struct list_head *cur;
 	struct hv_hotadd_state *has;
+	struct hv_hotadd_gap *gap;
 	unsigned long residual, new_inc;
 
 	if (list_empty(&dm_device.ha_region_list))
@@ -718,6 +754,24 @@ static bool pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
 		 */
 		if (start_pfn < has->start_pfn || start_pfn >= has->end_pfn)
 			continue;
+
+		/*
+		 * If the current start pfn is not where the covered_end
+		 * is, create a gap and update covered_end_pfn.
+		 */
+		if (has->covered_end_pfn != start_pfn) {
+			gap = kzalloc(sizeof(struct hv_hotadd_gap), GFP_ATOMIC);
+			if (!gap)
+				return -ENOMEM;
+
+			INIT_LIST_HEAD(&gap->list);
+			gap->start_pfn = has->covered_end_pfn;
+			gap->end_pfn = start_pfn;
+			list_add_tail(&gap->list, &has->gap_list);
+
+			has->covered_end_pfn = start_pfn;
+		}
+
 		/*
 		 * If the current hot add-request extends beyond
 		 * our current limit; extend it.
@@ -734,19 +788,10 @@ static bool pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
 			has->end_pfn += new_inc;
 		}
 
-		/*
-		 * If the current start pfn is not where the covered_end
-		 * is, update it.
-		 */
-
-		if (has->covered_end_pfn != start_pfn)
-			has->covered_end_pfn = start_pfn;
-
-		return true;
-
+		return 1;
 	}
 
-	return false;
+	return 0;
 }
 
 static unsigned long handle_pg_range(unsigned long pg_start,
@@ -785,6 +830,8 @@ static unsigned long handle_pg_range(unsigned long pg_start,
 			if (pgs_ol > pfn_cnt)
 				pgs_ol = pfn_cnt;
 
+			has->covered_end_pfn +=  pgs_ol;
+			pfn_cnt -= pgs_ol;
 			/*
 			 * Check if the corresponding memory block is already
 			 * online by checking its last previously backed page.
@@ -793,10 +840,8 @@ static unsigned long handle_pg_range(unsigned long pg_start,
 			 */
 			if (start_pfn > has->start_pfn &&
 			    !PageReserved(pfn_to_page(start_pfn - 1)))
-				hv_bring_pgs_online(start_pfn, pgs_ol);
+				hv_bring_pgs_online(has, start_pfn, pgs_ol);
 
-			has->covered_end_pfn +=  pgs_ol;
-			pfn_cnt -= pgs_ol;
 		}
 
 		if ((has->ha_end_pfn < has->end_pfn) && (pfn_cnt > 0)) {
@@ -834,13 +879,19 @@ static unsigned long process_hot_add(unsigned long pg_start,
 					unsigned long rg_size)
 {
 	struct hv_hotadd_state *ha_region = NULL;
+	int covered;
 
 	if (pfn_cnt == 0)
 		return 0;
 
-	if (!dm_device.host_specified_ha_region)
-		if (pfn_covered(pg_start, pfn_cnt))
+	if (!dm_device.host_specified_ha_region) {
+		covered = pfn_covered(pg_start, pfn_cnt);
+		if (covered < 0)
+			return 0;
+
+		if (covered)
 			goto do_pg_range;
+	}
 
 	/*
 	 * If the host has specified a hot-add range; deal with it first.
@@ -852,6 +903,7 @@ static unsigned long process_hot_add(unsigned long pg_start,
 			return 0;
 
 		INIT_LIST_HEAD(&ha_region->list);
+		INIT_LIST_HEAD(&ha_region->gap_list);
 
 		list_add_tail(&ha_region->list, &dm_device.ha_region_list);
 		ha_region->start_pfn = rg_start;
@@ -1584,6 +1636,7 @@ static int balloon_remove(struct hv_device *dev)
 	struct hv_dynmem_device *dm = hv_get_drvdata(dev);
 	struct list_head *cur, *tmp;
 	struct hv_hotadd_state *has;
+	struct hv_hotadd_gap *gap, *tmp_gap;
 
 	if (dm->num_pages_ballooned != 0)
 		pr_warn("Ballooned pages: %d\n", dm->num_pages_ballooned);
@@ -1600,6 +1653,10 @@ static int balloon_remove(struct hv_device *dev)
 #endif
 	list_for_each_safe(cur, tmp, &dm->ha_region_list) {
 		has = list_entry(cur, struct hv_hotadd_state, list);
+		list_for_each_entry_safe(gap, tmp_gap, &has->gap_list, list) {
+			list_del(&gap->list);
+			kfree(gap);
+		}
 		list_del(&has->list);
 		kfree(has);
 	}
-- 
2.7.4

[v3 PATCH for-4.4 7/7] hv: don't reset hv_context.tsc_page on crash

[Sumit Semwal]

From: Vitaly Kuznetsov <vkuznets@redhat.com>

[ Upstream commit 56ef6718a1d8d77745033c5291e025ce18504159 ]

It may happen that secondary CPUs are still alive and resetting
hv_context.tsc_page will cause a consequent crash in read_hv_clock_tsc()
as we don't check for it being not NULL there. It is safe as we're not
freeing this page anyways.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 drivers/hv/hv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index ddbf7e7..8ce1f2e 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -305,9 +305,10 @@ void hv_cleanup(bool crash)
 
 		hypercall_msr.as_uint64 = 0;
 		wrmsrl(HV_X64_MSR_REFERENCE_TSC, hypercall_msr.as_uint64);
-		if (!crash)
+		if (!crash) {
 			vfree(hv_context.tsc_page);
-		hv_context.tsc_page = NULL;
+			hv_context.tsc_page = NULL;
+		}
 	}
 #endif
 }
-- 
2.7.4

Re: [v3 PATCH for-4.4 0/7] hv patches for 4.4.y (resubmit)

[Greg KH]

On Thu, Apr 20, 2017 at 01:08:36PM +0530, Sumit Semwal wrote:
> Hi Greg,
> 
> >From my previous submission of patches for 4.4 from Ubuntu Xenial, dropping one
> patch caused the patch right after to fail to apply; I've reworked the failing
> patch. I've also included the remaining hv ones (that anyways apply cleanly) for
> the sake of completion.
> 
> These apply cleanly on top of 4.4.62, and are build tested on 4.4.y with x86
> allmodconfig. 

All now applied, thanks.

greg k-h