[PATCH 0/6] drivers: hv: vmbus: Some miscellaneous fixes for Linux 4.0

[PATCH 0/6] drivers: hv: vmbus: Some miscellaneous fixes for Linux 4.0

[K. Y. Srinivasan]

Some miscellaneous fixes to the vmbus driver and the balloon driver.
Currently the Linux 4.0 RC3 tree is broken on Hyper-V and this patch-set
fixes the issues.

Dexuan Cui (1):
  tools: hv: fcopy_daemon: support >2GB files for x86_32 guest

K. Y. Srinivasan (2):
  Drivers: hv: vmbus: Perform device register in the per-channel work
    element
  Drivers: hv: vmbus: Fix a bug in rescind processing in
    vmbus_close_internal()

Nick Meier (1):
  Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY

Vitaly Kuznetsov (2):
  Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure
  Drivers: hv: hv_balloon: don't lose memory when onlining order is not
    natural

 drivers/hv/channel.c      |   15 ++---
 drivers/hv/channel_mgmt.c |  143 +++++++++++++++++++++++++++++++-------------
 drivers/hv/connection.c   |    6 ++-
 drivers/hv/hv_balloon.c   |   15 ++---
 drivers/hv/hyperv_vmbus.h |    4 +-
 tools/hv/Makefile         |    2 +-
 6 files changed, 120 insertions(+), 65 deletions(-)

-- 
1.7.4.1

[PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[K. Y. Srinivasan]

This patch is a continuation of the rescind handling cleanup work. We cannot
block in the global message handling work context especially if we are blocking
waiting for the host to wake us up. I would like to thank
Dexuan Cui <decui@microsoft.com> for observing this problem.

The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/channel_mgmt.c |  143 +++++++++++++++++++++++++++++++-------------
 drivers/hv/connection.c   |    6 ++-
 drivers/hv/hyperv_vmbus.h |    2 +-
 3 files changed, 107 insertions(+), 44 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 6117891..5f8e47b 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -23,6 +23,7 @@
 #include <linux/kernel.h>
 #include <linux/sched.h>
 #include <linux/wait.h>
+#include <linux/delay.h>
 #include <linux/mm.h>
 #include <linux/slab.h>
 #include <linux/list.h>
@@ -37,6 +38,10 @@ struct vmbus_channel_message_table_entry {
 	void (*message_handler)(struct vmbus_channel_message_header *msg);
 };
 
+struct vmbus_rescind_work {
+	struct work_struct work;
+	struct vmbus_channel *channel;
+};
 
 /**
  * vmbus_prep_negotiate_resp() - Create default response for Hyper-V Negotiate message
@@ -134,20 +139,6 @@ fw_error:
 
 EXPORT_SYMBOL_GPL(vmbus_prep_negotiate_resp);
 
-static void vmbus_process_device_unregister(struct work_struct *work)
-{
-	struct device *dev;
-	struct vmbus_channel *channel = container_of(work,
-							struct vmbus_channel,
-							work);
-
-	dev = get_device(&channel->device_obj->device);
-	if (dev) {
-		vmbus_device_unregister(channel->device_obj);
-		put_device(dev);
-	}
-}
-
 static void vmbus_sc_creation_cb(struct work_struct *work)
 {
 	struct vmbus_channel *newchannel = container_of(work,
@@ -220,6 +211,40 @@ static void free_channel(struct vmbus_channel *channel)
 	queue_work(vmbus_connection.work_queue, &channel->work);
 }
 
+static void process_rescind_fn(struct work_struct *work)
+{
+	struct vmbus_rescind_work *rc_work;
+	struct vmbus_channel *channel;
+	struct device *dev;
+
+	rc_work = container_of(work, struct vmbus_rescind_work, work);
+	channel = rc_work->channel;
+
+	/*
+	 * We have already acquired a reference on the channel
+	 * and so it cannot vanish underneath us.
+	 * It is possible (while very unlikely) that we may
+	 * get here while the processing of the initial offer
+	 * is still not complete. Deal with this situation by
+	 * just waiting until the channel is in the correct state.
+	 */
+
+	while (channel->work.func != release_channel)
+		msleep(1000);
+
+	if (channel->device_obj) {
+		dev = get_device(&channel->device_obj->device);
+		if (dev) {
+			vmbus_device_unregister(channel->device_obj);
+			put_device(dev);
+		}
+	} else {
+		hv_process_channel_removal(channel,
+					   channel->offermsg.child_relid);
+	}
+	kfree(work);
+}
+
 static void percpu_channel_enq(void *arg)
 {
 	struct vmbus_channel *channel = arg;
@@ -282,6 +307,46 @@ void vmbus_free_channels(void)
 	}
 }
 
+static void vmbus_do_device_register(struct work_struct *work)
+{
+	struct hv_device *device_obj;
+	int ret;
+	unsigned long flags;
+	struct vmbus_channel *newchannel = container_of(work,
+						     struct vmbus_channel,
+						     work);
+
+	ret = vmbus_device_register(newchannel->device_obj);
+	if (ret != 0) {
+		pr_err("unable to add child device object (relid %d)\n",
+			newchannel->offermsg.child_relid);
+		spin_lock_irqsave(&vmbus_connection.channel_lock, flags);
+		list_del(&newchannel->listentry);
+		device_obj = newchannel->device_obj;
+		newchannel->device_obj = NULL;
+		spin_unlock_irqrestore(&vmbus_connection.channel_lock, flags);
+
+		if (newchannel->target_cpu != get_cpu()) {
+			put_cpu();
+			smp_call_function_single(newchannel->target_cpu,
+					 percpu_channel_deq, newchannel, true);
+		} else {
+			percpu_channel_deq(newchannel);
+			put_cpu();
+		}
+
+		kfree(device_obj);
+		if (!newchannel->rescind) {
+			free_channel(newchannel);
+			return;
+		}
+	}
+	/*
+	 * The next state for this channel is to be freed.
+	 */
+	INIT_WORK(&newchannel->work, release_channel);
+}
+
 /*
  * vmbus_process_offer - Process the offer by creating a channel/device
  * associated with this offer
@@ -291,7 +356,6 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)
 	struct vmbus_channel *channel;
 	bool fnew = true;
 	bool enq = false;
-	int ret;
 	unsigned long flags;
 
 	/* Make sure this is a new offer */
@@ -393,16 +457,13 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)
 	 * Add the new device to the bus. This will kick off device-driver
 	 * binding which eventually invokes the device driver's AddDevice()
 	 * method.
+	 * Invoke this call on the per-channel work context.
+	 * Until we return from this function, rescind offer message
+	 * cannot be processed as we are running on the global message
+	 * handling work.
 	 */
-	ret = vmbus_device_register(newchannel->device_obj);
-	if (ret != 0) {
-		pr_err("unable to add child device object (relid %d)\n",
-			   newchannel->offermsg.child_relid);
-
-		kfree(newchannel->device_obj);
-		goto err_deq_chan;
-	}
-
+	INIT_WORK(&newchannel->work, vmbus_do_device_register);
+	queue_work(newchannel->controlwq, &newchannel->work);
 	return;
 
 err_deq_chan:
@@ -556,33 +617,31 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr)
 {
 	struct vmbus_channel_rescind_offer *rescind;
 	struct vmbus_channel *channel;
-	unsigned long flags;
+	struct vmbus_rescind_work *rc_work;
 
 	rescind = (struct vmbus_channel_rescind_offer *)hdr;
-	channel = relid2channel(rescind->child_relid);
+	channel = relid2channel(rescind->child_relid, true);
 
 	if (channel == NULL) {
 		hv_process_channel_removal(NULL, rescind->child_relid);
 		return;
 	}
 
-	spin_lock_irqsave(&channel->lock, flags);
-	channel->rescind = true;
-	spin_unlock_irqrestore(&channel->lock, flags);
-
-	if (channel->device_obj) {
-		/*
-		 * We will have to unregister this device from the
-		 * driver core. Do this in the per-channel work context.
-		 * Note that we are currently executing on the global
-		 * workq for handling messages from the host.
-		 */
-		INIT_WORK(&channel->work, vmbus_process_device_unregister);
-		queue_work(channel->controlwq, &channel->work);
-	} else {
-		hv_process_channel_removal(channel,
-					   channel->offermsg.child_relid);
+	/*
+	 * We have acquired a reference on the channel and have posted
+	 * the rescind state. Perform further cleanup in a work context
+	 * that is different from the global work context in which
+	 * we process messages from the host (we are currently executing
+	 * on that global context.
+	 */
+	rc_work = kzalloc(sizeof(struct vmbus_rescind_work), GFP_KERNEL);
+	if (!rc_work) {
+		pr_err("Unable to allocate memory for rescind processing ");
+		return;
 	}
+	rc_work->channel = channel;
+	INIT_WORK(&rc_work->work, process_rescind_fn);
+	schedule_work(&rc_work->work);
 }
 
 /*
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 583d7d4..8bcd307 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -270,7 +270,7 @@ static struct vmbus_channel *pcpu_relid2channel(u32 relid)
  * relid2channel - Get the channel object given its
  * child relative id (ie channel id)
  */
-struct vmbus_channel *relid2channel(u32 relid)
+struct vmbus_channel *relid2channel(u32 relid, bool rescind)
 {
 	struct vmbus_channel *channel;
 	struct vmbus_channel *found_channel  = NULL;
@@ -282,6 +282,8 @@ struct vmbus_channel *relid2channel(u32 relid)
 	list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
 		if (channel->offermsg.child_relid == relid) {
 			found_channel = channel;
+			if (rescind)
+				found_channel->rescind = true;
 			break;
 		} else if (!list_empty(&channel->sc_list)) {
 			/*
@@ -292,6 +294,8 @@ struct vmbus_channel *relid2channel(u32 relid)
 							sc_list);
 				if (cur_sc->offermsg.child_relid == relid) {
 					found_channel = cur_sc;
+					if (rescind)
+						found_channel->rescind = true;
 					break;
 				}
 			}
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 88af4ec..6339589 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -698,7 +698,7 @@ void vmbus_device_unregister(struct hv_device *device_obj);
 /* VmbusChildDeviceDestroy( */
 /* struct hv_device *); */
 
-struct vmbus_channel *relid2channel(u32 relid);
+struct vmbus_channel *relid2channel(u32 relid, bool rescind);
 
 void vmbus_free_channels(void);
 
-- 
1.7.4.1

[PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure

[K. Y. Srinivasan]

From: Vitaly Kuznetsov <vkuznets@redhat.com>

When add_memory() fails the following BUG is observed:
[  743.646107] hv_balloon: hot_add memory failed error is -17
[  743.679973]
[  743.680930] =====================================
[  743.680930] [ BUG: bad unlock balance detected! ]
[  743.680930] 3.19.0-rc5_bug1131426+ #552 Not tainted
[  743.680930] -------------------------------------
[  743.680930] kworker/0:2/255 is trying to release lock (&dm_device.ha_region_mutex) at:
[  743.680930] [<ffffffff81aae5fe>] mutex_unlock+0xe/0x10
[  743.680930] but there are no more locks to release!

This happens as we don't acquire ha_region_mutex and hot_add_req() expects us
to as it does unconditional mutex_unlock(). Acquire the lock on the error path.

The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/hv_balloon.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index c5bb872..f1f17c5 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -652,6 +652,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
 			}
 			has->ha_end_pfn -= HA_CHUNK;
 			has->covered_end_pfn -=  processed_pfn;
+			mutex_lock(&dm_device.ha_region_mutex);
 			break;
 		}
 
-- 
1.7.4.1

Re: [PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure

[Olaf Hering]

On Wed, Mar 11, K. Y. Srinivasan wrote:

> +++ b/drivers/hv/hv_balloon.c
> @@ -652,6 +652,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
>  			}
>  			has->ha_end_pfn -= HA_CHUNK;
>  			has->covered_end_pfn -=  processed_pfn;
> +			mutex_lock(&dm_device.ha_region_mutex);
>  			break;
>  		}

Should it call the wrapper instead of doing mutex_lock directly?
Like 'acquire_region_mutex(false);'.

Olaf

Re: [PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure

[Vitaly Kuznetsov]

Olaf Hering <olaf@aepfle.de> writes:

> On Wed, Mar 11, K. Y. Srinivasan wrote:
>
>> +++ b/drivers/hv/hv_balloon.c
>> @@ -652,6 +652,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
>>  			}
>>  			has->ha_end_pfn -= HA_CHUNK;
>>  			has->covered_end_pfn -=  processed_pfn;
>> +			mutex_lock(&dm_device.ha_region_mutex);
>>  			break;
>>  		}
>
> Should it call the wrapper instead of doing mutex_lock directly?
> Like 'acquire_region_mutex(false);'.

My "Drivers: hv: hv_balloon: eliminate the trylock path in
acquire/release_region_mutex" (b05d8d9ef5ef21d1b18440430f950304836e1aaa
in char-misc-next) removed these wrappers.

>
> Olaf

-- 
  Vitaly

Re: [PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure

[Olaf Hering]

On Thu, Mar 12, Vitaly Kuznetsov wrote:

> My "Drivers: hv: hv_balloon: eliminate the trylock path in
> acquire/release_region_mutex" (b05d8d9ef5ef21d1b18440430f950304836e1aaa
> in char-misc-next) removed these wrappers.

I see now. There are many changes in char-misc-next. The description
gives the impression that mainline is broken. Not sure if thats true,
perhaps its just char-misc-next which is affected.

Olaf

Re: [PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure

[Dan Carpenter]

On Thu, Mar 12, 2015 at 12:14:28PM +0100, Olaf Hering wrote:
> On Thu, Mar 12, Vitaly Kuznetsov wrote:
> 
> > My "Drivers: hv: hv_balloon: eliminate the trylock path in
> > acquire/release_region_mutex" (b05d8d9ef5ef21d1b18440430f950304836e1aaa
> > in char-misc-next) removed these wrappers.
> 
> I see now. There are many changes in char-misc-next. The description
> gives the impression that mainline is broken. Not sure if thats true,
> perhaps its just char-misc-next which is affected.

Mainline is broken.  We only found these when we removed the wrapper and
then static checkers were able to catch the bug.

regards,
dan carpenter

RE: [PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure

[KY Srinivasan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1100 bytes --]



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Thursday, March 12, 2015 4:14 AM
> To: Vitaly Kuznetsov
> Cc: KY Srinivasan; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org; apw@canonical.com
> Subject: Re: [PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on
> add_memory() failure
> 
> On Thu, Mar 12, Vitaly Kuznetsov wrote:
> 
> > My "Drivers: hv: hv_balloon: eliminate the trylock path in
> > acquire/release_region_mutex"
> > (b05d8d9ef5ef21d1b18440430f950304836e1aaa
> > in char-misc-next) removed these wrappers.
> 
> I see now. There are many changes in char-misc-next. The description gives
> the impression that mainline is broken. Not sure if thats true, perhaps its just
> char-misc-next which is affected.

Yes; I notified Greg of this and I have resent the set with proper tag for Greg to pick this set up
for 4.0.

Regards,

K. Y
> 
> Olaf
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

[PATCH 3/6] Drivers: hv: hv_balloon: don't lose memory when onlining order is not natural

[K. Y. Srinivasan]

From: Vitaly Kuznetsov <vkuznets@redhat.com>

Memory blocks can be onlined in random order. When this order is not natural
some memory pages are not onlined because of the redundant check in
hv_online_page().

Here is a real world scenario:
1) Host tries to hot-add the following (process_hot_add):
  pg_start=rg_start=0x48000, pfn_cnt=111616, rg_size=262144

2) This results in adding 4 memory blocks:
[  109.057866] init_memory_mapping: [mem 0x48000000-0x4fffffff]
[  114.102698] init_memory_mapping: [mem 0x50000000-0x57ffffff]
[  119.168039] init_memory_mapping: [mem 0x58000000-0x5fffffff]
[  124.233053] init_memory_mapping: [mem 0x60000000-0x67ffffff]
The last one is incomplete but we have special has->covered_end_pfn counter to
avoid onlining non-backed frames and hv_bring_pgs_online() function to bring
them online later on.

3) Now we have 4 offline memory blocks: /sys/devices/system/memory/memory9-12
$ for f in /sys/devices/system/memory/memory*/state; do echo $f `cat $f`; done | grep -v onlin
/sys/devices/system/memory/memory10/state offline
/sys/devices/system/memory/memory11/state offline
/sys/devices/system/memory/memory12/state offline
/sys/devices/system/memory/memory9/state offline

4) We bring them online in non-natural order:
$grep MemTotal /proc/meminfo
MemTotal:         966348 kB
$echo online > /sys/devices/system/memory/memory12/state && grep MemTotal /proc/meminfo
MemTotal:        1019596 kB
$echo online > /sys/devices/system/memory/memory11/state && grep MemTotal /proc/meminfo
MemTotal:        1150668 kB
$echo online > /sys/devices/system/memory/memory9/state && grep MemTotal /proc/meminfo
MemTotal:        1150668 kB

As you can see memory9 block gives us zero additional memory. We can also
observe a huge discrepancy between host- and guest-reported memory sizes.

The root cause of the issue is the redundant pg >= covered_start_pfn check (and
covered_start_pfn advancing) in hv_online_page(). When upper memory block in
being onlined before the lower one (memory12 and memory11 in the above case) we
advance the covered_start_pfn pointer and all memory9 pages do not pass the
check. If the assumption that host always gives us requests in sequential order
and pg_start always equals rg_start when the first request for the new HA
region is received (that's the case in my testing) is correct than we can get
rid of covered_start_pfn and pg >= start_pfn check in hv_online_page() is
sufficient.

The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/hv_balloon.c |   14 ++++----------
 1 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index f1f17c5..014256a 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -428,14 +428,13 @@ 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_start_pfn : covered_end_pfn defines the pages that can
+ * 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;
@@ -679,8 +678,7 @@ 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_start_pgp = (unsigned long)pfn_to_page(has->start_pfn);
 		cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn);
 
 		if (((unsigned long)pg >= cur_start_pgp) &&
@@ -692,7 +690,6 @@ static void hv_online_page(struct page *pg)
 			__online_page_set_limits(pg);
 			__online_page_increment_counters(pg);
 			__online_page_free(pg);
-			has->covered_start_pfn++;
 		}
 	}
 }
@@ -736,10 +733,9 @@ static bool pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
 		 * is, update it.
 		 */
 
-		if (has->covered_end_pfn != start_pfn) {
+		if (has->covered_end_pfn != start_pfn)
 			has->covered_end_pfn = start_pfn;
-			has->covered_start_pfn = start_pfn;
-		}
+
 		return true;
 
 	}
@@ -784,7 +780,6 @@ static unsigned long handle_pg_range(unsigned long pg_start,
 				pgs_ol = pfn_cnt;
 			hv_bring_pgs_online(start_pfn, pgs_ol);
 			has->covered_end_pfn +=  pgs_ol;
-			has->covered_start_pfn +=  pgs_ol;
 			pfn_cnt -= pgs_ol;
 		}
 
@@ -845,7 +840,6 @@ 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;
 	}
-- 
1.7.4.1

[PATCH 4/6] Correcting truncation error for constant HV_CRASH_CTL_CRASH_NOTIFY

[K. Y. Srinivasan]

From: Nick Meier <nmeier@microsoft.com>

HV_CRASH_CTL_CRASH_NOTIFY is a 64 bit number.  Depending on the usage context,
the value may be truncated. This patch is in response from the following
email from Intel:

    [char-misc:char-misc-testing 25/45] drivers/hv/vmbus_drv.c:67:9: sparse:
                   constant 0x8000000000000000 is so big it is unsigned long

    tree:   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git char-misc-testing
    head:   b3de8e3719e582f3182bb504295e4a8e43c8c96f
    commit: 96c1d0581d00f7abe033350edb021a9d947d8d81 [25/45] Drivers: hv: vmbus: Add support for VMBus panic notifier handler
    reproduce:
      # apt-get install sparse
      git checkout 96c1d0581d00f7abe033350edb021a9d947d8d81
      make ARCH=x86_64 allmodconfig
      make C=1 CF=-D__CHECK_ENDIAN__

    sparse warnings: (new ones prefixed by >>)

    drivers/hv/vmbus_drv.c:67:9: sparse: constant 0x8000000000000000 is so big it is unsigned long
    ...

The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.

Signed-off-by: Nick Meier <nmeier@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/hyperv_vmbus.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 6339589..c8e27e0 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -58,7 +58,7 @@ enum hv_cpuid_function {
 #define HV_X64_MSR_CRASH_P4   0x40000104
 #define HV_X64_MSR_CRASH_CTL  0x40000105
 
-#define HV_CRASH_CTL_CRASH_NOTIFY 0x8000000000000000
+#define HV_CRASH_CTL_CRASH_NOTIFY (1ULL << 63)
 
 /* Define version of the synthetic interrupt controller. */
 #define HV_SYNIC_VERSION		(1)
-- 
1.7.4.1

[PATCH 5/6] tools: hv: fcopy_daemon: support >2GB files for x86_32 guest

[K. Y. Srinivasan]

From: Dexuan Cui <decui@microsoft.com>

Without this patch, hv_fcopy_daemon's hv_copy_data() -> pwrite()
will fail for >2GB file offset.

The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.

Signed-off-by: Alex Ng <alexng@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 tools/hv/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index 99ffe61..a8ab795 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -3,7 +3,7 @@
 CC = $(CROSS_COMPILE)gcc
 PTHREAD_LIBS = -lpthread
 WARNINGS = -Wall -Wextra
-CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS)
+CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS) $(shell getconf LFS_CFLAGS)
 
 all: hv_kvp_daemon hv_vss_daemon hv_fcopy_daemon
 %: %.c
-- 
1.7.4.1

[PATCH 6/6] Drivers: hv: vmbus: Fix a bug in rescind processing in vmbus_close_internal()

[K. Y. Srinivasan]

When a channel has been rescinded, the close operation is a noop.
Restructure the code so we deal with the rescind condition after
we properly cleanup the channel. I would like to thank
Dexuan Cui <decui@microsoft.com> for observing this problem.
The current code leaks memory when the channel is rescinded.

The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/channel.c |   15 ++++++---------
 1 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index da53180..2c8206d 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -501,15 +501,6 @@ static int vmbus_close_internal(struct vmbus_channel *channel)
 		put_cpu();
 	}
 
-	/*
-	 * If the channel has been rescinded; process device removal.
-	 */
-	if (channel->rescind) {
-		hv_process_channel_removal(channel,
-					   channel->offermsg.child_relid);
-		return 0;
-	}
-
 	/* Send a closing message */
 
 	msg = &channel->close_msg.msg;
@@ -549,6 +540,12 @@ static int vmbus_close_internal(struct vmbus_channel *channel)
 	free_pages((unsigned long)channel->ringbuffer_pages,
 		get_order(channel->ringbuffer_pagecount * PAGE_SIZE));
 
+	/*
+	 * If the channel has been rescinded; process device removal.
+	 */
+	if (channel->rescind)
+		hv_process_channel_removal(channel,
+					   channel->offermsg.child_relid);
 	return ret;
 }
 
-- 
1.7.4.1

Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[Greg KH]

On Wed, Mar 11, 2015 at 06:56:54PM -0700, K. Y. Srinivasan wrote:
> This patch is a continuation of the rescind handling cleanup work. We cannot
> block in the global message handling work context especially if we are blocking
> waiting for the host to wake us up. I would like to thank
> Dexuan Cui <decui@microsoft.com> for observing this problem.
> 
> The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.
> 
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
>  drivers/hv/channel_mgmt.c |  143 +++++++++++++++++++++++++++++++-------------
>  drivers/hv/connection.c   |    6 ++-
>  drivers/hv/hyperv_vmbus.h |    2 +-
>  3 files changed, 107 insertions(+), 44 deletions(-)

This is a very big patch so late in the -rc cycle.  Is there some patch
that got merged in 4.0-rc1 that I should be reverting instead to fix
things up?

thanks,

greg k-h

Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[Greg KH]

On Thu, Mar 12, 2015 at 10:02:24AM +0100, Greg KH wrote:
> On Wed, Mar 11, 2015 at 06:56:54PM -0700, K. Y. Srinivasan wrote:
> > This patch is a continuation of the rescind handling cleanup work. We cannot
> > block in the global message handling work context especially if we are blocking
> > waiting for the host to wake us up. I would like to thank
> > Dexuan Cui <decui@microsoft.com> for observing this problem.
> > 
> > The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.
> > 
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> >  drivers/hv/channel_mgmt.c |  143 +++++++++++++++++++++++++++++++-------------
> >  drivers/hv/connection.c   |    6 ++-
> >  drivers/hv/hyperv_vmbus.h |    2 +-
> >  3 files changed, 107 insertions(+), 44 deletions(-)
> 
> This is a very big patch so late in the -rc cycle.  Is there some patch
> that got merged in 4.0-rc1 that I should be reverting instead to fix
> things up?

Make that, "this is a very large patch set", not just one patch.  I
can't take all of these this late, sorry.  Please just tell me what to
revert.

thanks,

greg k-h

RE: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Thursday, March 12, 2015 2:03 AM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com
> Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> per-channel work element
> 
> On Thu, Mar 12, 2015 at 10:02:24AM +0100, Greg KH wrote:
> > On Wed, Mar 11, 2015 at 06:56:54PM -0700, K. Y. Srinivasan wrote:
> > > This patch is a continuation of the rescind handling cleanup work.
> > > We cannot block in the global message handling work context
> > > especially if we are blocking waiting for the host to wake us up. I
> > > would like to thank Dexuan Cui <decui@microsoft.com> for observing
> this problem.
> > >
> > > The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > ---
> > >  drivers/hv/channel_mgmt.c |  143
> +++++++++++++++++++++++++++++++-------------
> > >  drivers/hv/connection.c   |    6 ++-
> > >  drivers/hv/hyperv_vmbus.h |    2 +-
> > >  3 files changed, 107 insertions(+), 44 deletions(-)
> >
> > This is a very big patch so late in the -rc cycle.  Is there some
> > patch that got merged in 4.0-rc1 that I should be reverting instead to
> > fix things up?
> 
> Make that, "this is a very large patch set", not just one patch.  I can't take all
> of these this late, sorry.  Please just tell me what to revert.

Greg,

Would it be possible to pick up two patches. I could prune this down to two. The two I want you to
pick up are (in the order of importance):

[PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element
[PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure

If you could pickup an additional patch that would be:

[PATCH 6/6] Drivers: hv: vmbus: Fix a bug in rescind processing in vmbus_close_internal()

The first one is the most important one and if you can only pickup one, the first one is the one I want you to pick up.
The third one fixes a memory leak issue that occurs only under
certain conditions. We may have to revert more patches than applying the two patches that
would fix the most important issues.

Let me know if you want me to resend the ones that you can apply.

Thank you in advance,

K. Y

Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[Greg KH]

On Thu, Mar 12, 2015 at 01:12:29PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Thursday, March 12, 2015 2:03 AM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com
> > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> > per-channel work element
> > 
> > On Thu, Mar 12, 2015 at 10:02:24AM +0100, Greg KH wrote:
> > > On Wed, Mar 11, 2015 at 06:56:54PM -0700, K. Y. Srinivasan wrote:
> > > > This patch is a continuation of the rescind handling cleanup work.
> > > > We cannot block in the global message handling work context
> > > > especially if we are blocking waiting for the host to wake us up. I
> > > > would like to thank Dexuan Cui <decui@microsoft.com> for observing
> > this problem.
> > > >
> > > > The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > ---
> > > >  drivers/hv/channel_mgmt.c |  143
> > +++++++++++++++++++++++++++++++-------------
> > > >  drivers/hv/connection.c   |    6 ++-
> > > >  drivers/hv/hyperv_vmbus.h |    2 +-
> > > >  3 files changed, 107 insertions(+), 44 deletions(-)
> > >
> > > This is a very big patch so late in the -rc cycle.  Is there some
> > > patch that got merged in 4.0-rc1 that I should be reverting instead to
> > > fix things up?
> > 
> > Make that, "this is a very large patch set", not just one patch.  I can't take all
> > of these this late, sorry.  Please just tell me what to revert.
> 
> Greg,
> 
> Would it be possible to pick up two patches. I could prune this down to two. The two I want you to
> pick up are (in the order of importance):
> 
> [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element
> [PATCH 2/6] Drivers: hv: hv_balloon: keep locks balanced on add_memory() failure
> 
> If you could pickup an additional patch that would be:
> 
> [PATCH 6/6] Drivers: hv: vmbus: Fix a bug in rescind processing in vmbus_close_internal()
> 
> The first one is the most important one and if you can only pickup one, the first one is the one I want you to pick up.

You aren't answering my question, what happened that caused these to
become an error and break the 4.0-rc tree?  Shouldn't I just revert a
recent change here?  Or has things always been broken and no one has
noticed it before?

I need a lot more information here please.

Oh, and also, please wrap your email lines :)

> The third one fixes a memory leak issue that occurs only under
> certain conditions.

You need to describe those "certian conditions" better.

> We may have to revert more patches than applying the two patches that
> would fix the most important issues.

I can easly revert everything recently applied, which is much safer than
adding more patches on top of things.  In fact, I prefer to do that, so
what git commit ids should I revert?

thanks,

greg k-h

RE: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Thursday, March 12, 2015 6:29 AM
> To: KY Srinivasan
> Cc: apw@canonical.com; devel@linuxdriverproject.org; olaf@aepfle.de;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> per-channel work element
> 
> On Thu, Mar 12, 2015 at 01:12:29PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Thursday, March 12, 2015 2:03 AM
> > > To: KY Srinivasan
> > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com
> > > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register
> > > in the per-channel work element
> > >
> > > On Thu, Mar 12, 2015 at 10:02:24AM +0100, Greg KH wrote:
> > > > On Wed, Mar 11, 2015 at 06:56:54PM -0700, K. Y. Srinivasan wrote:
> > > > > This patch is a continuation of the rescind handling cleanup work.
> > > > > We cannot block in the global message handling work context
> > > > > especially if we are blocking waiting for the host to wake us
> > > > > up. I would like to thank Dexuan Cui <decui@microsoft.com> for
> > > > > observing
> > > this problem.
> > > > >
> > > > > The current Linux 4.0 RC3 tree is broken and this patch fixes the
> problem.
> > > > >
> > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > ---
> > > > >  drivers/hv/channel_mgmt.c |  143
> > > +++++++++++++++++++++++++++++++-------------
> > > > >  drivers/hv/connection.c   |    6 ++-
> > > > >  drivers/hv/hyperv_vmbus.h |    2 +-
> > > > >  3 files changed, 107 insertions(+), 44 deletions(-)
> > > >
> > > > This is a very big patch so late in the -rc cycle.  Is there some
> > > > patch that got merged in 4.0-rc1 that I should be reverting
> > > > instead to fix things up?
> > >
> > > Make that, "this is a very large patch set", not just one patch.  I
> > > can't take all of these this late, sorry.  Please just tell me what to revert.
> >
> > Greg,
> >
> > Would it be possible to pick up two patches. I could prune this down
> > to two. The two I want you to pick up are (in the order of importance):
> >
> > [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> > per-channel work element [PATCH 2/6] Drivers: hv: hv_balloon: keep
> > locks balanced on add_memory() failure
> >
> > If you could pickup an additional patch that would be:
> >
> > [PATCH 6/6] Drivers: hv: vmbus: Fix a bug in rescind processing in
> > vmbus_close_internal()
> >
> > The first one is the most important one and if you can only pickup one, the
> first one is the one I want you to pick up.
> 
> You aren't answering my question, what happened that caused these to
> become an error and break the 4.0-rc tree?  Shouldn't I just revert a recent
> change here?  Or has things always been broken and no one has noticed it
> before?

commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7

introduced the bug (committed on Feb 28th). This patch cleaned up
the rescind handling code.

The patches I sent a few days later:

Drivers: hv: vmbus: Perform device register in the
per-channel work element fixed it.

Drivers: hv: vmbus: Fix a bug in rescind processing in 
vmbus_close_internal()
 
Fixed the bugs.

> 
> I need a lot more information here please.
> 
> Oh, and also, please wrap your email lines :)
> 
> > The third one fixes a memory leak issue that occurs only under certain
> > conditions.
> 
> You need to describe those "certian conditions" better.

When a channel that has been rescinded is closed, we will leak memory.
This bug was also introduced by:
commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7

> 
> > We may have to revert more patches than applying the two patches that
> > would fix the most important issues.
> 
> I can easly revert everything recently applied, which is much safer than
> adding more patches on top of things.  In fact, I prefer to do that, so what git
> commit ids should I revert?

If you revert commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7
we should be fine in that we will have all the issues we have had
for a while with regards to rescind handling. 

Regards,

K. Y

Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[Greg KH]

On Thu, Mar 12, 2015 at 02:16:23PM +0000, KY Srinivasan wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Thursday, March 12, 2015 6:29 AM
> > To: KY Srinivasan
> > Cc: apw@canonical.com; devel@linuxdriverproject.org; olaf@aepfle.de;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> > per-channel work element
> > 
> > On Thu, Mar 12, 2015 at 01:12:29PM +0000, KY Srinivasan wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > > Sent: Thursday, March 12, 2015 2:03 AM
> > > > To: KY Srinivasan
> > > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com
> > > > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register
> > > > in the per-channel work element
> > > >
> > > > On Thu, Mar 12, 2015 at 10:02:24AM +0100, Greg KH wrote:
> > > > > On Wed, Mar 11, 2015 at 06:56:54PM -0700, K. Y. Srinivasan wrote:
> > > > > > This patch is a continuation of the rescind handling cleanup work.
> > > > > > We cannot block in the global message handling work context
> > > > > > especially if we are blocking waiting for the host to wake us
> > > > > > up. I would like to thank Dexuan Cui <decui@microsoft.com> for
> > > > > > observing
> > > > this problem.
> > > > > >
> > > > > > The current Linux 4.0 RC3 tree is broken and this patch fixes the
> > problem.
> > > > > >
> > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > > ---
> > > > > >  drivers/hv/channel_mgmt.c |  143
> > > > +++++++++++++++++++++++++++++++-------------
> > > > > >  drivers/hv/connection.c   |    6 ++-
> > > > > >  drivers/hv/hyperv_vmbus.h |    2 +-
> > > > > >  3 files changed, 107 insertions(+), 44 deletions(-)
> > > > >
> > > > > This is a very big patch so late in the -rc cycle.  Is there some
> > > > > patch that got merged in 4.0-rc1 that I should be reverting
> > > > > instead to fix things up?
> > > >
> > > > Make that, "this is a very large patch set", not just one patch.  I
> > > > can't take all of these this late, sorry.  Please just tell me what to revert.
> > >
> > > Greg,
> > >
> > > Would it be possible to pick up two patches. I could prune this down
> > > to two. The two I want you to pick up are (in the order of importance):
> > >
> > > [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> > > per-channel work element [PATCH 2/6] Drivers: hv: hv_balloon: keep
> > > locks balanced on add_memory() failure
> > >
> > > If you could pickup an additional patch that would be:
> > >
> > > [PATCH 6/6] Drivers: hv: vmbus: Fix a bug in rescind processing in
> > > vmbus_close_internal()
> > >
> > > The first one is the most important one and if you can only pickup one, the
> > first one is the one I want you to pick up.
> > 
> > You aren't answering my question, what happened that caused these to
> > become an error and break the 4.0-rc tree?  Shouldn't I just revert a recent
> > change here?  Or has things always been broken and no one has noticed it
> > before?
> 
> commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7
> 
> introduced the bug (committed on Feb 28th). This patch cleaned up
> the rescind handling code.
> 
> The patches I sent a few days later:
> 
> Drivers: hv: vmbus: Perform device register in the
> per-channel work element fixed it.
> 
> Drivers: hv: vmbus: Fix a bug in rescind processing in 
> vmbus_close_internal()
>  
> Fixed the bugs.

Ok, commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7 is on my
char-misc-next branch, and has nothing to do with 4.0-final.  So why do
you think anything needs to be done for 4.0?

Please take a look at my tree, at Linus's tree, and figure out exactly
what needs to be fixed where, and resend me patches that explicitly says
which branch for me to apply them to (char-linus for patches that need
to go for 4.0-final, char-next for patches that need to go into
4.1-rc1.)

I'm again dropping all of your pending patches in my to-apply queue, as
it's all just too confusing here and no one seems to know what is going
on (myself included.)

thanks,

greg k-h

RE: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Monday, March 16, 2015 1:22 PM
> To: KY Srinivasan
> Cc: apw@canonical.com; devel@linuxdriverproject.org; olaf@aepfle.de;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> per-channel work element
> 
> On Thu, Mar 12, 2015 at 02:16:23PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Thursday, March 12, 2015 6:29 AM
> > > To: KY Srinivasan
> > > Cc: apw@canonical.com; devel@linuxdriverproject.org; olaf@aepfle.de;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register
> > > in the per-channel work element
> > >
> > > On Thu, Mar 12, 2015 at 01:12:29PM +0000, KY Srinivasan wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > > > Sent: Thursday, March 12, 2015 2:03 AM
> > > > > To: KY Srinivasan
> > > > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > > > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com
> > > > > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device
> > > > > register in the per-channel work element
> > > > >
> > > > > On Thu, Mar 12, 2015 at 10:02:24AM +0100, Greg KH wrote:
> > > > > > On Wed, Mar 11, 2015 at 06:56:54PM -0700, K. Y. Srinivasan wrote:
> > > > > > > This patch is a continuation of the rescind handling cleanup work.
> > > > > > > We cannot block in the global message handling work context
> > > > > > > especially if we are blocking waiting for the host to wake
> > > > > > > us up. I would like to thank Dexuan Cui
> > > > > > > <decui@microsoft.com> for observing
> > > > > this problem.
> > > > > > >
> > > > > > > The current Linux 4.0 RC3 tree is broken and this patch
> > > > > > > fixes the
> > > problem.
> > > > > > >
> > > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > > > ---
> > > > > > >  drivers/hv/channel_mgmt.c |  143
> > > > > +++++++++++++++++++++++++++++++-------------
> > > > > > >  drivers/hv/connection.c   |    6 ++-
> > > > > > >  drivers/hv/hyperv_vmbus.h |    2 +-
> > > > > > >  3 files changed, 107 insertions(+), 44 deletions(-)
> > > > > >
> > > > > > This is a very big patch so late in the -rc cycle.  Is there
> > > > > > some patch that got merged in 4.0-rc1 that I should be
> > > > > > reverting instead to fix things up?
> > > > >
> > > > > Make that, "this is a very large patch set", not just one patch.
> > > > > I can't take all of these this late, sorry.  Please just tell me what to
> revert.
> > > >
> > > > Greg,
> > > >
> > > > Would it be possible to pick up two patches. I could prune this
> > > > down to two. The two I want you to pick up are (in the order of
> importance):
> > > >
> > > > [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> > > > per-channel work element [PATCH 2/6] Drivers: hv: hv_balloon: keep
> > > > locks balanced on add_memory() failure
> > > >
> > > > If you could pickup an additional patch that would be:
> > > >
> > > > [PATCH 6/6] Drivers: hv: vmbus: Fix a bug in rescind processing in
> > > > vmbus_close_internal()
> > > >
> > > > The first one is the most important one and if you can only pickup
> > > > one, the
> > > first one is the one I want you to pick up.
> > >
> > > You aren't answering my question, what happened that caused these to
> > > become an error and break the 4.0-rc tree?  Shouldn't I just revert
> > > a recent change here?  Or has things always been broken and no one
> > > has noticed it before?
> >
> > commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7
> >
> > introduced the bug (committed on Feb 28th). This patch cleaned up the
> > rescind handling code.
> >
> > The patches I sent a few days later:
> >
> > Drivers: hv: vmbus: Perform device register in the per-channel work
> > element fixed it.
> >
> > Drivers: hv: vmbus: Fix a bug in rescind processing in
> > vmbus_close_internal()
> >
> > Fixed the bugs.
> 
> Ok, commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7 is on my char-
> misc-next branch, and has nothing to do with 4.0-final.  So why do you think
> anything needs to be done for 4.0?
> 
> Please take a look at my tree, at Linus's tree, and figure out exactly what
> needs to be fixed where, and resend me patches that explicitly says which
> branch for me to apply them to (char-linus for patches that need to go for
> 4.0-final, char-next for patches that need to go into
> 4.1-rc1.)
> 
> I'm again dropping all of your pending patches in my to-apply queue, as it's all
> just too confusing here and no one seems to know what is going on (myself
> included.)
> 
> thanks,

Thanks Greg; I will look at all the trees and get back to you.

Regards,

K. Y

> 
> greg k-h

RE: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Monday, March 16, 2015 1:22 PM
> To: KY Srinivasan
> Cc: apw@canonical.com; devel@linuxdriverproject.org; olaf@aepfle.de;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> per-channel work element
> 
> On Thu, Mar 12, 2015 at 02:16:23PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Thursday, March 12, 2015 6:29 AM
> > > To: KY Srinivasan
> > > Cc: apw@canonical.com; devel@linuxdriverproject.org; olaf@aepfle.de;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register
> > > in the per-channel work element
> > >
> > > On Thu, Mar 12, 2015 at 01:12:29PM +0000, KY Srinivasan wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > > > Sent: Thursday, March 12, 2015 2:03 AM
> > > > > To: KY Srinivasan
> > > > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > > > olaf@aepfle.de; apw@canonical.com; vkuznets@redhat.com
> > > > > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device
> > > > > register in the per-channel work element
> > > > >
> > > > > On Thu, Mar 12, 2015 at 10:02:24AM +0100, Greg KH wrote:
> > > > > > On Wed, Mar 11, 2015 at 06:56:54PM -0700, K. Y. Srinivasan wrote:
> > > > > > > This patch is a continuation of the rescind handling cleanup work.
> > > > > > > We cannot block in the global message handling work context
> > > > > > > especially if we are blocking waiting for the host to wake
> > > > > > > us up. I would like to thank Dexuan Cui
> > > > > > > <decui@microsoft.com> for observing
> > > > > this problem.
> > > > > > >
> > > > > > > The current Linux 4.0 RC3 tree is broken and this patch
> > > > > > > fixes the
> > > problem.
> > > > > > >
> > > > > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > > > > ---
> > > > > > >  drivers/hv/channel_mgmt.c |  143
> > > > > +++++++++++++++++++++++++++++++-------------
> > > > > > >  drivers/hv/connection.c   |    6 ++-
> > > > > > >  drivers/hv/hyperv_vmbus.h |    2 +-
> > > > > > >  3 files changed, 107 insertions(+), 44 deletions(-)
> > > > > >
> > > > > > This is a very big patch so late in the -rc cycle.  Is there
> > > > > > some patch that got merged in 4.0-rc1 that I should be
> > > > > > reverting instead to fix things up?
> > > > >
> > > > > Make that, "this is a very large patch set", not just one patch.
> > > > > I can't take all of these this late, sorry.  Please just tell me what to
> revert.
> > > >
> > > > Greg,
> > > >
> > > > Would it be possible to pick up two patches. I could prune this
> > > > down to two. The two I want you to pick up are (in the order of
> importance):
> > > >
> > > > [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> > > > per-channel work element [PATCH 2/6] Drivers: hv: hv_balloon: keep
> > > > locks balanced on add_memory() failure
> > > >
> > > > If you could pickup an additional patch that would be:
> > > >
> > > > [PATCH 6/6] Drivers: hv: vmbus: Fix a bug in rescind processing in
> > > > vmbus_close_internal()
> > > >
> > > > The first one is the most important one and if you can only pickup
> > > > one, the
> > > first one is the one I want you to pick up.
> > >
> > > You aren't answering my question, what happened that caused these to
> > > become an error and break the 4.0-rc tree?  Shouldn't I just revert
> > > a recent change here?  Or has things always been broken and no one
> > > has noticed it before?
> >
> > commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7
> >
> > introduced the bug (committed on Feb 28th). This patch cleaned up the
> > rescind handling code.
> >
> > The patches I sent a few days later:
> >
> > Drivers: hv: vmbus: Perform device register in the per-channel work
> > element fixed it.
> >
> > Drivers: hv: vmbus: Fix a bug in rescind processing in
> > vmbus_close_internal()
> >
> > Fixed the bugs.
> 
> Ok, commit 2dd37cb81580dce6dfb8c5a7d5c37b904a188ae7 is on my char-
> misc-next branch, and has nothing to do with 4.0-final.  So why do you think
> anything needs to be done for 4.0?
> 
> Please take a look at my tree, at Linus's tree, and figure out exactly what
> needs to be fixed where, and resend me patches that explicitly says which
> branch for me to apply them to (char-linus for patches that need to go for
> 4.0-final, char-next for patches that need to go into
> 4.1-rc1.)

You are right, the offending commit is NOT in 4.0-rc4 tree that 
I looked at earlier this afternoon.
 
> 
> I'm again dropping all of your pending patches in my to-apply queue, as it's all
> just too confusing here and no one seems to know what is going on (myself
> included.)

Sorry about the confusion. My mistake; last week I looked at a test tree that had the
offending commit and I was told that the tree was the 4.0-rc3 tree.

I will resend the patches that need to go into 4.1-rc1.

Regards,

K. Y 

Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[Olaf Hering]

On Wed, Mar 11, K. Y. Srinivasan wrote:

> The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.

This does not seem to apply to master. What it is based on?

checking file drivers/hv/channel_mgmt.c
Hunk #3 FAILED at 139.
Hunk #4 succeeded at 194 (offset -31 lines).
Hunk #5 succeeded at 303 (offset -18 lines).
Hunk #6 succeeded at 355 (offset -15 lines).
Hunk #7 FAILED at 471.
Hunk #8 FAILED at 634.
3 out of 8 hunks FAILED
checking file drivers/hv/connection.c
Hunk #1 succeeded at 263 (offset -7 lines).
Hunk #2 succeeded at 275 (offset -7 lines).
Hunk #3 succeeded at 287 (offset -7 lines).
checking file drivers/hv/hyperv_vmbus.h
Hunk #1 succeeded at 685 (offset -13 lines).

Olaf

RE: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[KY Srinivasan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 769 bytes --]



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Thursday, March 12, 2015 3:44 AM
> To: KY Srinivasan
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; apw@canonical.com; vkuznets@redhat.com
> Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> per-channel work element
> 
> On Wed, Mar 11, K. Y. Srinivasan wrote:
> 
> > The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.
> 
> This does not seem to apply to master. What it is based on?

They were based on Greg's tree. 

K. Y

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the per-channel work element

[KY Srinivasan]

> -----Original Message-----
> From: devel [mailto:driverdev-devel-bounces@linuxdriverproject.org] On
> Behalf Of KY Srinivasan
> Sent: Thursday, March 12, 2015 7:29 AM
> To: Olaf Hering
> Cc: apw@canonical.com; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org
> Subject: RE: [PATCH 1/6] Drivers: hv: vmbus: Perform device register in the
> per-channel work element
> 
> 
> 
> > -----Original Message-----
> > From: Olaf Hering [mailto:olaf@aepfle.de]
> > Sent: Thursday, March 12, 2015 3:44 AM
> > To: KY Srinivasan
> > Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> > devel@linuxdriverproject.org; apw@canonical.com; vkuznets@redhat.com
> > Subject: Re: [PATCH 1/6] Drivers: hv: vmbus: Perform device register
> > in the per-channel work element
> >
> > On Wed, Mar 11, K. Y. Srinivasan wrote:
> >
> > > The current Linux 4.0 RC3 tree is broken and this patch fixes the problem.
> >
> > This does not seem to apply to master. What it is based on?
> 
> They were based on Greg's tree.

Olaf,

I don't know exactly what Greg will do. If he reverts the previous commits, 
I don't know If it will be on  4.0 branch or from 4.1 as well. I can rebase 
these patches on linux-next and give them to you if you want.

K. Y
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel