All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 1/3] Drivers: hv: hv_balloon: Make adjustments in computing the floor
  2014-12-02 22:29 ` [PATCH 1/3] Drivers: hv: hv_balloon: Make adjustments in computing the floor K. Y. Srinivasan
@ 2014-12-02 21:51   ` Dan Carpenter
  2014-12-02 22:03     ` KY Srinivasan
  2014-12-02 22:29   ` [PATCH 2/3] Drivers: hv: hv_balloon: Fix a locking bug in the balloon driver K. Y. Srinivasan
  2014-12-02 22:29   ` [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context K. Y. Srinivasan
  2 siblings, 1 reply; 10+ messages in thread
From: Dan Carpenter @ 2014-12-02 21:51 UTC (permalink / raw)
  To: K. Y. Srinivasan; +Cc: gregkh, linux-kernel, devel, olaf, apw, jasowang

On Tue, Dec 02, 2014 at 02:29:13PM -0800, K. Y. Srinivasan wrote:
> Make adjustments in computing the balloon floor.
> 

The changelog should say what the user visible effects of the bug are.

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [PATCH 1/3] Drivers: hv: hv_balloon: Make adjustments in computing the floor
  2014-12-02 21:51   ` Dan Carpenter
@ 2014-12-02 22:03     ` KY Srinivasan
  0 siblings, 0 replies; 10+ messages in thread
From: KY Srinivasan @ 2014-12-02 22:03 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: gregkh, linux-kernel, devel, olaf, apw, jasowang



> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Tuesday, December 2, 2014 1:51 PM
> To: KY Srinivasan
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com
> Subject: Re: [PATCH 1/3] Drivers: hv: hv_balloon: Make adjustments in
> computing the floor
> 
> On Tue, Dec 02, 2014 at 02:29:13PM -0800, K. Y. Srinivasan wrote:
> > Make adjustments in computing the balloon floor.
> >
> 
> The changelog should say what the user visible effects of the bug are.

Thanks Dan; I will make the log more descriptive.

K. Y
> 
> regards,
> dan carpenter


^ permalink raw reply	[flat|nested] 10+ messages in thread
* [PATCH 0/3] Drivers: hv: hv_balloon
@ 2014-12-02 22:28 K. Y. Srinivasan
  2014-12-02 22:29 ` [PATCH 1/3] Drivers: hv: hv_balloon: Make adjustments in computing the floor K. Y. Srinivasan
  0 siblings, 1 reply; 10+ messages in thread
From: K. Y. Srinivasan @ 2014-12-02 22:28 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, olaf, apw, jasowang; +Cc: K. Y. Srinivasan

Some bug fixes for the balloon driver.

K. Y. Srinivasan (3):
  Drivers: hv: hv_balloon: Make adjustments in computing the floor
  Drivers: hv: hv_balloon: Fix a locking bug in the balloon driver
  Drivers: hv: hv_balloon: Don't post pressure status from interrupt
    context

 drivers/hv/hv_balloon.c |   89 ++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 73 insertions(+), 16 deletions(-)

-- 
1.7.4.1


^ permalink raw reply	[flat|nested] 10+ messages in thread
* [PATCH 1/3] Drivers: hv: hv_balloon: Make adjustments in computing the floor
  2014-12-02 22:28 [PATCH 0/3] Drivers: hv: hv_balloon K. Y. Srinivasan
@ 2014-12-02 22:29 ` K. Y. Srinivasan
  2014-12-02 21:51   ` Dan Carpenter
                     ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: K. Y. Srinivasan @ 2014-12-02 22:29 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, olaf, apw, jasowang; +Cc: K. Y. Srinivasan

Make adjustments in computing the balloon floor.

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

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b958ded..9cbbb83 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -928,9 +928,8 @@ static unsigned long compute_balloon_floor(void)
 	 *     128        72    (1/2)
 	 *     512       168    (1/4)
 	 *    2048       360    (1/8)
-	 *    8192       552    (1/32)
-	 *   32768      1320
-	 *  131072      4392
+	 *    8192       768    (1/16)
+	 *   32768      1536	(1/32)
 	 */
 	if (totalram_pages < MB2PAGES(128))
 		min_pages = MB2PAGES(8) + (totalram_pages >> 1);
@@ -938,8 +937,10 @@ static unsigned long compute_balloon_floor(void)
 		min_pages = MB2PAGES(40) + (totalram_pages >> 2);
 	else if (totalram_pages < MB2PAGES(2048))
 		min_pages = MB2PAGES(104) + (totalram_pages >> 3);
+	else if (totalram_pages < MB2PAGES(8192))
+		min_pages = MB2PAGES(256) + (totalram_pages >> 4);
 	else
-		min_pages = MB2PAGES(296) + (totalram_pages >> 5);
+		min_pages = MB2PAGES(512) + (totalram_pages >> 5);
 #undef MB2PAGES
 	return min_pages;
 }
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread
* [PATCH 2/3] Drivers: hv: hv_balloon: Fix a locking bug in the balloon driver
  2014-12-02 22:29 ` [PATCH 1/3] Drivers: hv: hv_balloon: Make adjustments in computing the floor K. Y. Srinivasan
  2014-12-02 21:51   ` Dan Carpenter
@ 2014-12-02 22:29   ` K. Y. Srinivasan
  2014-12-02 22:29   ` [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context K. Y. Srinivasan
  2 siblings, 0 replies; 10+ messages in thread
From: K. Y. Srinivasan @ 2014-12-02 22:29 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, olaf, apw, jasowang; +Cc: K. Y. Srinivasan

We support memory hot-add in the Hyper-V balloon driver by hot adding an appropriately
sized and aligned region and controlling the on-lining of pages within that region
based on the pages that the host wants us to online. We do this because the
granularity and alignment requirements in Linux are different from what Windows
expects. The state to manage the onlining of pages needs to be correctly
protected. Fix this bug.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/hv/hv_balloon.c |   69 +++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 64 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 9cbbb83..2c610ec 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -533,6 +533,9 @@ struct hv_dynmem_device {
 	 */
 	struct task_struct *thread;
 
+	struct mutex ha_region_mutex;
+	struct completion waiter_event;
+
 	/*
 	 * A list of hot-add regions.
 	 */
@@ -549,7 +552,60 @@ struct hv_dynmem_device {
 static struct hv_dynmem_device dm_device;
 
 static void post_status(struct hv_dynmem_device *dm);
+
+static void acquire_region_mutex(bool trylock)
+{
+	if (trylock) {
+		reinit_completion(&dm_device.waiter_event);
+		while (!mutex_trylock(&dm_device.ha_region_mutex))
+			wait_for_completion(&dm_device.waiter_event);
+	} else {
+		mutex_lock(&dm_device.ha_region_mutex);
+	}
+}
+
+static void release_region_mutex(bool trylock)
+{
+	if (trylock) {
+		mutex_unlock(&dm_device.ha_region_mutex);
+	} else {
+		mutex_unlock(&dm_device.ha_region_mutex);
+		complete(&dm_device.waiter_event);
+	}
+}
+
+
 #ifdef CONFIG_MEMORY_HOTPLUG
+static int hv_memory_notifier(struct notifier_block *nb, unsigned long val,
+			      void *v)
+{
+	switch (val) {
+	case MEM_GOING_ONLINE:
+		acquire_region_mutex(true);
+		break;
+
+	case MEM_ONLINE:
+	case MEM_CANCEL_ONLINE:
+		release_region_mutex(true);
+		if (dm_device.ha_waiting) {
+			dm_device.ha_waiting = false;
+			complete(&dm_device.ol_waitevent);
+		}
+		break;
+
+	case MEM_GOING_OFFLINE:
+	case MEM_OFFLINE:
+	case MEM_CANCEL_OFFLINE:
+		break;
+	}
+	return NOTIFY_OK;
+}
+
+static struct notifier_block hv_memory_nb = {
+	.notifier_call = hv_memory_notifier,
+	.priority = 0
+};
+
 
 static void hv_bring_pgs_online(unsigned long start_pfn, unsigned long size)
 {
@@ -591,6 +647,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
 		init_completion(&dm_device.ol_waitevent);
 		dm_device.ha_waiting = true;
 
+		release_region_mutex(false);
 		nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
 		ret = add_memory(nid, PFN_PHYS((start_pfn)),
 				(HA_CHUNK << PAGE_SHIFT));
@@ -619,6 +676,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
 		 * have not been "onlined" within the allowed time.
 		 */
 		wait_for_completion_timeout(&dm_device.ol_waitevent, 5*HZ);
+		acquire_region_mutex(false);
 		post_status(&dm_device);
 	}
 
@@ -632,11 +690,6 @@ static void hv_online_page(struct page *pg)
 	unsigned long cur_start_pgp;
 	unsigned long cur_end_pgp;
 
-	if (dm_device.ha_waiting) {
-		dm_device.ha_waiting = false;
-		complete(&dm_device.ol_waitevent);
-	}
-
 	list_for_each(cur, &dm_device.ha_region_list) {
 		has = list_entry(cur, struct hv_hotadd_state, list);
 		cur_start_pgp = (unsigned long)
@@ -834,6 +887,7 @@ static void hot_add_req(struct work_struct *dummy)
 	resp.hdr.size = sizeof(struct dm_hot_add_response);
 
 #ifdef CONFIG_MEMORY_HOTPLUG
+	acquire_region_mutex(false);
 	pg_start = dm->ha_wrk.ha_page_range.finfo.start_page;
 	pfn_cnt = dm->ha_wrk.ha_page_range.finfo.page_cnt;
 
@@ -865,6 +919,7 @@ static void hot_add_req(struct work_struct *dummy)
 	if (do_hot_add)
 		resp.page_count = process_hot_add(pg_start, pfn_cnt,
 						rg_start, rg_sz);
+	release_region_mutex(false);
 #endif
 	/*
 	 * The result field of the response structure has the
@@ -1388,7 +1443,9 @@ static int balloon_probe(struct hv_device *dev,
 	dm_device.next_version = DYNMEM_PROTOCOL_VERSION_WIN7;
 	init_completion(&dm_device.host_event);
 	init_completion(&dm_device.config_event);
+	init_completion(&dm_device.waiter_event);
 	INIT_LIST_HEAD(&dm_device.ha_region_list);
+	mutex_init(&dm_device.ha_region_mutex);
 	INIT_WORK(&dm_device.balloon_wrk.wrk, balloon_up);
 	INIT_WORK(&dm_device.ha_wrk.wrk, hot_add_req);
 	dm_device.host_specified_ha_region = false;
@@ -1402,6 +1459,7 @@ static int balloon_probe(struct hv_device *dev,
 
 #ifdef CONFIG_MEMORY_HOTPLUG
 	set_online_page_callback(&hv_online_page);
+	register_memory_notifier(&hv_memory_nb);
 #endif
 
 	hv_set_drvdata(dev, &dm_device);
@@ -1520,6 +1578,7 @@ static int balloon_remove(struct hv_device *dev)
 	kfree(send_buffer);
 #ifdef CONFIG_MEMORY_HOTPLUG
 	restore_online_page_callback(&hv_online_page);
+	unregister_memory_notifier(&hv_memory_nb);
 #endif
 	list_for_each_safe(cur, tmp, &dm->ha_region_list) {
 		has = list_entry(cur, struct hv_hotadd_state, list);
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread
* [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context
  2014-12-02 22:29 ` [PATCH 1/3] Drivers: hv: hv_balloon: Make adjustments in computing the floor K. Y. Srinivasan
  2014-12-02 21:51   ` Dan Carpenter
  2014-12-02 22:29   ` [PATCH 2/3] Drivers: hv: hv_balloon: Fix a locking bug in the balloon driver K. Y. Srinivasan
@ 2014-12-02 22:29   ` K. Y. Srinivasan
  2014-12-07  8:04     ` Sitsofe Wheeler
  2 siblings, 1 reply; 10+ messages in thread
From: K. Y. Srinivasan @ 2014-12-02 22:29 UTC (permalink / raw)
  To: gregkh, linux-kernel, devel, olaf, apw, jasowang; +Cc: K. Y. Srinivasan

We currently release memory (balloon down) in the interrupt context and we also
post memory status while releasing memory. Rather than posting the status
in the interrupt context, wakeup the status posting thread to post the status.
This will address the inconsistent lock state that Sitsofe Wheeler <sitsofe@gmail.com>
reported:

http://lkml.iu.edu/hypermail/linux/kernel/1411.1/00075.html

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reported-by: Sitsofe Wheeler <sitsofe@gmail.com>
---
 drivers/hv/hv_balloon.c |   11 ++++-------
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 2c610ec..afdb0d5 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1227,7 +1227,7 @@ static void balloon_down(struct hv_dynmem_device *dm,
 
 	for (i = 0; i < range_count; i++) {
 		free_balloon_pages(dm, &range_array[i]);
-		post_status(&dm_device);
+		complete(&dm_device.config_event);
 	}
 
 	if (req->more_pages == 1)
@@ -1251,19 +1251,16 @@ static void balloon_onchannelcallback(void *context);
 static int dm_thread_func(void *dm_dev)
 {
 	struct hv_dynmem_device *dm = dm_dev;
-	int t;
 
 	while (!kthread_should_stop()) {
-		t = wait_for_completion_interruptible_timeout(
+		wait_for_completion_interruptible_timeout(
 						&dm_device.config_event, 1*HZ);
 		/*
 		 * The host expects us to post information on the memory
 		 * pressure every second.
 		 */
-
-		if (t == 0)
-			post_status(dm);
-
+		reinit_completion(&dm_device.config_event);
+		post_status(dm);
 	}
 
 	return 0;
-- 
1.7.4.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread
* Re: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context
  2014-12-02 22:29   ` [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context K. Y. Srinivasan
@ 2014-12-07  8:04     ` Sitsofe Wheeler
  2014-12-08  6:04       ` KY Srinivasan
  0 siblings, 1 reply; 10+ messages in thread
From: Sitsofe Wheeler @ 2014-12-07  8:04 UTC (permalink / raw)
  To: K. Y. Srinivasan; +Cc: gregkh, linux-kernel, devel, olaf, apw, jasowang

On Tue, Dec 02, 2014 at 02:29:15PM -0800, K. Y. Srinivasan wrote:
> We currently release memory (balloon down) in the interrupt context and we also
> post memory status while releasing memory. Rather than posting the status
> in the interrupt context, wakeup the status posting thread to post the status.
> This will address the inconsistent lock state that Sitsofe Wheeler <sitsofe@gmail.com>
> reported:

Sorry I didn't follow up on this. Things looked better after the patch
but I was seeing a strange issue where the memory was being reduced to
some minimum and the balloon would never shrink so the available memory
was seemingly locked from then on. I ran out of time to investigate this
later behaviour and didn't have the time to check if it had always been
the case but I think I see other patches saying you nailed it and other
issues. Do you have a published git tree with all these pieces in or
have they already been mainlined?

-- 
Sitsofe | http://sucs.org/~sits/

^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context
  2014-12-07  8:04     ` Sitsofe Wheeler
@ 2014-12-08  6:04       ` KY Srinivasan
  2014-12-10 20:50         ` Sitsofe Wheeler
  0 siblings, 1 reply; 10+ messages in thread
From: KY Srinivasan @ 2014-12-08  6:04 UTC (permalink / raw)
  To: Sitsofe Wheeler; +Cc: gregkh, linux-kernel, devel, olaf, apw, jasowang



> -----Original Message-----
> From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> Sent: Sunday, December 7, 2014 12:05 AM
> To: KY Srinivasan
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com
> Subject: Re: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status
> from interrupt context
> 
> On Tue, Dec 02, 2014 at 02:29:15PM -0800, K. Y. Srinivasan wrote:
> > We currently release memory (balloon down) in the interrupt context
> > and we also post memory status while releasing memory. Rather than
> > posting the status in the interrupt context, wakeup the status posting
> thread to post the status.
> > This will address the inconsistent lock state that Sitsofe Wheeler
> > <sitsofe@gmail.com>
> > reported:
> 
> Sorry I didn't follow up on this. Things looked better after the patch but I was
> seeing a strange issue where the memory was being reduced to some
> minimum and the balloon would never shrink so the available memory was
> seemingly locked from then on. I ran out of time to investigate this later
> behaviour and didn't have the time to check if it had always been the case
> but I think I see other patches saying you nailed it and other issues. Do you
> have a published git tree with all these pieces in or have they already been
> mainlined?

Greg has not committed these patches yet. One of the patches changes the balloon floor.
This means that the guest will not be ballooned down below the floor. Is this what you are
seeing? In our testing we did not see anything unusual other than the floor being elevated
(as per the design).

K. Y 
> 
> --
> Sitsofe | http://sucs.org/~sits/

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context
  2014-12-08  6:04       ` KY Srinivasan
@ 2014-12-10 20:50         ` Sitsofe Wheeler
  2014-12-10 23:43           ` KY Srinivasan
  0 siblings, 1 reply; 10+ messages in thread
From: Sitsofe Wheeler @ 2014-12-10 20:50 UTC (permalink / raw)
  To: KY Srinivasan; +Cc: gregkh, linux-kernel, devel, olaf, apw, jasowang

On Mon, Dec 08, 2014 at 06:04:35AM +0000, KY Srinivasan wrote:
> 
> Greg has not committed these patches yet. One of the patches changes the balloon floor.
> This means that the guest will not be ballooned down below the floor. Is this what you are
> seeing? In our testing we did not see anything unusual other than the floor being elevated
> (as per the design).

I applied the following:

drivers-scsi-storvsc-Fix-a-bug-in-handling-ring-buffer-failures-that-may-result-in-I-O-freeze.patch
V2-1-3-Drivers-hv-hv_balloon-Make-adjustments-in-computing-the-floor.patch
V2-2-3-Drivers-hv-hv_balloon-Fix-a-locking-bug-in-the-balloon-driver.patch
V2-3-3-Drivers-hv-hv_balloon-Don-t-post-pressure-status-from-interrupt-context.patch

Initially things looked OK but now I'm starting to see the following
which is rather worrying:

Dec 10 20:37:11 a kernel: BUG: unable to handle kernel NULL pointer dereference at           (null)
Dec 10 20:37:11 a kernel: IP: [<ffffffff811c30a0>] commit_charge+0x20/0x90
Dec 10 20:37:11 a kernel: PGD e44cb067 PUD e4495067 PMD 0 
Dec 10 20:37:11 a kernel: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Dec 10 20:37:11 a kernel: CPU: 5 PID: 1490 Comm: ruby Not tainted 3.18.0.x86_64-01967-g86c6a2f-dirty #163
Dec 10 20:37:11 a kernel: Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006  05/23/2012
Dec 10 20:37:11 a kernel: task: ffff8800e9bce040 ti: ffff880003890000 task.ti: ffff880003890000
Dec 10 20:37:11 a kernel: RIP: 0010:[<ffffffff811c30a0>]  [<ffffffff811c30a0>] commit_charge+0x20/0x90
Dec 10 20:37:11 a kernel: RSP: 0018:ffff880003893a88  EFLAGS: 00010246
Dec 10 20:37:11 a kernel: RAX: 0000000000000000 RBX: ffffea00048d0380 RCX: 0000000000000006
Dec 10 20:37:11 a kernel: RDX: 0000000000000480 RSI: ffff880108829bd8 RDI: 000000000012340e
Dec 10 20:37:11 a kernel: RBP: ffff880003893ac8 R08: 0000000000000000 R09: 0000000000000000
Dec 10 20:37:11 a kernel: R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
Dec 10 20:37:11 a kernel: R13: ffff880108829bd8 R14: ffff880017669c58 R15: 0000000000000000
Dec 10 20:37:11 a kernel: FS:  00007f4dc62fa740(0000) GS:ffff88010d4a0000(0000) knlGS:0000000000000000
Dec 10 20:37:11 a kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 10 20:37:11 a kernel: CR2: 0000000000000000 CR3: 00000000f1459000 CR4: 00000000000406e0
Dec 10 20:37:11 a kernel: Stack:
Dec 10 20:37:11 a kernel:  ffff8800e9bce040 ffffffff816f3950 0000000000000000 ffff880017669c58
Dec 10 20:37:11 a kernel:  ffff880003893ac8 ffffea00048d0380 ffff880108829bd8 0000000000000000
Dec 10 20:37:11 a kernel:  ffff880003893af8 ffffffff811c6b36 ffff880003893af8 ffffea00048d0380
Dec 10 20:37:11 a kernel: Call Trace:
Dec 10 20:37:11 a kernel:  [<ffffffff816f3950>] ? _raw_spin_unlock_irq+0x30/0x50
Dec 10 20:37:11 a kernel:  [<ffffffff811c6b36>] mem_cgroup_commit_charge+0x76/0x140
Dec 10 20:37:11 a kernel:  [<ffffffff8115d8d5>] __add_to_page_cache_locked+0x1e5/0x2d0
Dec 10 20:37:11 a kernel:  [<ffffffff8115dfb8>] add_to_page_cache_lru+0x28/0x80
Dec 10 20:37:11 a kernel:  [<ffffffff8115f347>] pagecache_get_page+0x197/0x220
Dec 10 20:37:11 a kernel:  [<ffffffff81160cc3>] grab_cache_page_write_begin+0x33/0x50
Dec 10 20:37:11 a kernel:  [<ffffffff81254fd7>] ext4_da_write_begin+0x157/0x340
Dec 10 20:37:11 a kernel:  [<ffffffff81160da1>] generic_perform_write+0xc1/0x1d0
Dec 10 20:37:11 a kernel:  [<ffffffff81161138>] __generic_file_write_iter+0x288/0x340
Dec 10 20:37:11 a kernel:  [<ffffffff8124a693>] ext4_file_write_iter+0x2f3/0x3b0
Dec 10 20:37:11 a kernel:  [<ffffffff811cde47>] ? vfs_write+0xa7/0x1d0
Dec 10 20:37:11 a kernel:  [<ffffffff811cdc31>] new_sync_write+0x81/0xb0
Dec 10 20:37:11 a kernel:  [<ffffffff811cde6b>] vfs_write+0xcb/0x1d0
Dec 10 20:37:11 a kernel:  [<ffffffff811ce069>] SyS_write+0x49/0xb0
Dec 10 20:37:11 a kernel:  [<ffffffff816f45a9>] system_call_fastpath+0x12/0x17
Dec 10 20:37:11 a kernel: Code: 5d c3 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 55 49 89 f5 41 54 41 89 d4 53 48 89 fb 48 83 ec 28 e8 90 3e 00 00 <f6> 00 01 74 1b 48 c7 c6 e0 f1 9e 81 48 89 df e8 cc 4f fc ff 0f 
Dec 10 20:37:11 a kernel: RIP  [<ffffffff811c30a0>] commit_charge+0x20/0x90
Dec 10 20:37:11 a kernel:  RSP <ffff880003893a88>
Dec 10 20:37:11 a kernel: CR2: 0000000000000000
Dec 10 20:37:11 a kernel: BUG: unable to handle kernel 
Dec 10 20:37:11 a kernel: ---[ end trace 0ae405bbdfb1f416 ]---
Dec 10 20:37:11 a kernel: NULL pointer dereference
Dec 10 20:37:11 a kernel:  at           (null)
Dec 10 20:37:11 a kernel: IP: [<ffffffff811c30a0>] commit_charge+0x20/0x90
Dec 10 20:37:11 a kernel: PGD f17d4067 PUD f1567067 PMD 0 
Dec 10 20:37:12 a kernel: Oops: 0000 [#2] SMP DEBUG_PAGEALLOC
Dec 10 20:37:12 a kernel: CPU: 2 PID: 25465 Comm: ruby Tainted: G      D        3.18.0.x86_64-01967-g86c6a2f-dirty #163
Dec 10 20:37:12 a kernel: Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006  05/23/2012
Dec 10 20:37:12 a kernel: task: ffff880011a16040 ti: ffff880098754000 task.ti: ffff880098754000
Dec 10 20:37:12 a kernel: init_memory_mapping: [mem 0x128000000-0x12fffffff]
Dec 10 20:37:12 a kernel:  [mem 0x128000000-0x12fffffff] page 4k
Dec 10 20:37:12 a kernel:  [ffffea0004800000-ffffea00049fffff] PMD -> [ffff8800c7400000-ffff8800c75fffff] on node 0
Dec 10 20:37:12 a kernel: RIP: 0010:[<ffffffff811c30a0>]  [<ffffffff811c30a0>] commit_charge+0x20/0x90
Dec 10 20:37:12 a kernel: RSP: 0000:ffff880098757d18  EFLAGS: 00010246
Dec 10 20:37:12 a kernel: RAX: 0000000000000000 RBX: ffffea0004915300 RCX: 0000000000000001
Dec 10 20:37:12 a kernel: RDX: 0000000000000480 RSI: ffff880108829bd8 RDI: 000000000012454c
Dec 10 20:37:12 a kernel: RBP: ffff880098757d58 R08: 0000000000000006 R09: 0000000000000000
Dec 10 20:37:12 a kernel: R10: ffff880011a16040 R11: 0000000000000000 R12: 0000000000000000
Dec 10 20:37:12 a kernel: R13: ffff880108829bd8 R14: ffff8800f159a5f0 R15: ffff88006b3bc600
Dec 10 20:37:12 a kernel: FS:  00007f0836edf700(0000) GS:ffff88010d440000(0000) knlGS:0000000000000000
Dec 10 20:37:12 a kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 10 20:37:12 a kernel: CR2: 0000000000000000 CR3: 00000000b8bfd000 CR4: 00000000000406e0
Dec 10 20:37:12 a kernel: Stack:
Dec 10 20:37:12 a kernel:  00000000811bf285 ffff88000723e118 ffff880108829bd8 ffff88000723e100
Dec 10 20:37:12 a kernel:  ffffea0004915300 ffffea0004915300 ffff880108829bd8 ffff88000613a280
Dec 10 20:37:12 a kernel:  ffff880098757d88 ffffffff811c6b36 ffffffff8118d6fc 00007f08200bea58
Dec 10 20:37:12 a kernel: Call Trace:
Dec 10 20:37:12 a kernel:  [<ffffffff811c6b36>] mem_cgroup_commit_charge+0x76/0x140
Dec 10 20:37:12 a kernel:  [<ffffffff8118d6fc>] ? handle_mm_fault+0x62c/0x12a0
Dec 10 20:37:12 a kernel:  [<ffffffff8118d742>] handle_mm_fault+0x672/0x12a0
Dec 10 20:37:12 a kernel:  [<ffffffff81041a13>] ? __do_page_fault+0x1c3/0x4f0
Dec 10 20:37:12 a kernel:  [<ffffffff81041ce0>] __do_page_fault+0x490/0x4f0
Dec 10 20:37:12 a kernel:  [<ffffffff810bf2cd>] ? trace_hardirqs_on+0xd/0x10
Dec 10 20:37:12 a kernel:  [<ffffffff816f3950>] ? _raw_spin_unlock_irq+0x30/0x50
Dec 10 20:37:12 a kernel:  [<ffffffff81097a88>] ? finish_task_switch+0x88/0x100
Dec 10 20:37:12 a kernel:  [<ffffffff81097a4a>] ? finish_task_switch+0x4a/0x100
Dec 10 20:37:12 a kernel:  [<ffffffff816ee380>] ? __schedule+0x6a0/0x830
Dec 10 20:37:12 a kernel:  [<ffffffff813b24ed>] ? trace_hardirqs_off_thunk+0x3a/0x3c
Dec 10 20:37:12 a kernel:  [<ffffffff81041d92>] do_page_fault+0x22/0x30
Dec 10 20:37:12 a kernel:  [<ffffffff816f6398>] page_fault+0x28/0x30
Dec 10 20:37:12 a kernel: Code: 5d c3 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 55 49 89 f5 41 54 41 89 d4 53 48 89 fb 48 83 ec 28 e8 90 3e 00 00 <f6> 00 01 74 1b 48 c7 c6 e0 f1 9e 81 48 89 df e8 cc 4f fc ff 0f 
Dec 10 20:37:12 a kernel: RIP  [<ffffffff811c30a0>] commit_charge+0x20/0x90
Dec 10 20:37:12 a kernel:  RSP <ffff880098757d18>
Dec 10 20:37:12 a kernel: CR2: 0000000000000000
Dec 10 20:37:12 a kernel: ---[ end trace 0ae405bbdfb1f417 ]---
Dec 10 20:37:12 a kernel: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41
Dec 10 20:37:12 a kernel: in_atomic(): 1, irqs_disabled(): 1, pid: 25465, name: ruby
Dec 10 20:37:12 a kernel: INFO: lockdep is turned off.
Dec 10 20:37:12 a kernel: irq event stamp: 2431342
Dec 10 20:37:12 a kernel: hardirqs last  enabled at (2431341): [<ffffffff816f38fd>] _raw_spin_unlock_irqrestore+0x4d/0x70
Dec 10 20:37:12 a kernel: hardirqs last disabled at (2431342): [<ffffffff816f37dd>] _raw_spin_lock_irq+0x1d/0x60
Dec 10 20:37:12 a kernel: softirqs last  enabled at (2431322): [<ffffffff81078458>] __do_softirq+0x298/0x340
Dec 10 20:37:12 a kernel: softirqs last disabled at (2431317): [<ffffffff810787c8>] irq_exit+0x58/0xc0
Dec 10 20:37:12 a kernel: CPU: 2 PID: 25465 Comm: ruby Tainted: G      D        3.18.0.x86_64-01967-g86c6a2f-dirty #163
Dec 10 20:37:12 a kernel: Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006  05/23/2012
Dec 10 20:37:12 a kernel:  0000000000000029 ffff8800987578f8 ffffffff816ea99f 0000000000000000
Dec 10 20:37:12 a kernel:  ffff880011a16040 ffff880098757918 ffffffff810a2dc5 ffff880098757948
Dec 10 20:37:12 a kernel:  ffffffff819d796f ffff880098757948 ffffffff810a2e46 ffffffff82b828c2
Dec 10 20:37:12 a kernel: Call Trace:
Dec 10 20:37:12 a kernel:  [<ffffffff816ea99f>] dump_stack+0x4e/0x68
Dec 10 20:37:12 a kernel:  [<ffffffff810a2dc5>] ___might_sleep+0x115/0x120
Dec 10 20:37:12 a kernel:  [<ffffffff810a2e46>] __might_sleep+0x76/0xa0
Dec 10 20:37:12 a kernel:  [<ffffffff816f1f04>] down_read+0x24/0x70
Dec 10 20:37:12 a kernel:  [<ffffffff81082de4>] exit_signals+0x24/0x140
Dec 10 20:37:12 a kernel:  [<ffffffff81076714>] do_exit+0x134/0xa80
Dec 10 20:37:12 a kernel:  [<ffffffff810cb8cc>] ? kmsg_dump+0xfc/0x110
Dec 10 20:37:12 a kernel:  [<ffffffff810cb7f5>] ? kmsg_dump+0x25/0x110
Dec 10 20:37:12 a kernel:  [<ffffffff810064e8>] oops_end+0xa8/0xc0
Dec 10 20:37:12 a kernel:  [<ffffffff816e53bc>] no_context+0x319/0x362
Dec 10 20:37:12 a kernel:  [<ffffffff816e55d0>] __bad_area_nosemaphore+0x1cb/0x1ea
Dec 10 20:37:12 a kernel:  [<ffffffff816e5602>] bad_area_nosemaphore+0x13/0x15
Dec 10 20:37:12 a kernel:  [<ffffffff81041a3e>] __do_page_fault+0x1ee/0x4f0
Dec 10 20:37:12 a kernel:  [<ffffffff811680d5>] ? __alloc_pages_nodemask+0x225/0xaf0
Dec 10 20:37:12 a kernel:  [<ffffffff813b24ed>] ? trace_hardirqs_off_thunk+0x3a/0x3c
Dec 10 20:37:12 a kernel:  [<ffffffff81041d92>] do_page_fault+0x22/0x30
Dec 10 20:37:12 a kernel:  [<ffffffff816f6398>] page_fault+0x28/0x30
Dec 10 20:37:12 a kernel:  [<ffffffff811c30a0>] ? commit_charge+0x20/0x90
Dec 10 20:37:12 a kernel:  [<ffffffff811c30a0>] ? commit_charge+0x20/0x90
Dec 10 20:37:12 a kernel:  [<ffffffff811c6b36>] mem_cgroup_commit_charge+0x76/0x140
Dec 10 20:37:12 a kernel:  [<ffffffff8118d6fc>] ? handle_mm_fault+0x62c/0x12a0
Dec 10 20:37:12 a kernel:  [<ffffffff8118d742>] handle_mm_fault+0x672/0x12a0
Dec 10 20:37:12 a kernel:  [<ffffffff81041a13>] ? __do_page_fault+0x1c3/0x4f0
Dec 10 20:37:12 a kernel:  [<ffffffff81041ce0>] __do_page_fault+0x490/0x4f0
Dec 10 20:37:12 a kernel:  [<ffffffff810bf2cd>] ? trace_hardirqs_on+0xd/0x10
Dec 10 20:37:12 a kernel:  [<ffffffff816f3950>] ? _raw_spin_unlock_irq+0x30/0x50
Dec 10 20:37:12 a kernel:  [<ffffffff81097a88>] ? finish_task_switch+0x88/0x100
Dec 10 20:37:12 a kernel:  [<ffffffff81097a4a>] ? finish_task_switch+0x4a/0x100
Dec 10 20:37:12 a kernel:  [<ffffffff816ee380>] ? __schedule+0x6a0/0x830
Dec 10 20:37:12 a kernel:  [<ffffffff813b24ed>] ? trace_hardirqs_off_thunk+0x3a/0x3c
Dec 10 20:37:12 a kernel:  [<ffffffff81041d92>] do_page_fault+0x22/0x30
Dec 10 20:37:12 a kernel:  [<ffffffff816f6398>] page_fault+0x28/0x30
Dec 10 20:37:12 a kernel: note: ruby[25465] exited with preempt_count 1
Dec 10 20:37:16 a kernel: init_memory_mapping: [mem 0x130000000-0x137ffffff]
Dec 10 20:37:16 a kernel:  [mem 0x130000000-0x137ffffff] page 4k
Dec 10 20:37:16 a kernel:  [ffffea0004a00000-ffffea0004bfffff] PMD -> [ffff880093200000-ffff8800933fffff] on node 0
Dec 10 20:37:17 a kernel: BUG: unable to handle kernel NULL pointer dereference at           (null)
Dec 10 20:37:17 a kernel: IP: [<ffffffff811c30a0>] commit_charge+0x20/0x90

Are these Hyper-V related?

-- 
Sitsofe | http://sucs.org/~sits/

^ permalink raw reply	[flat|nested] 10+ messages in thread
* RE: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context
  2014-12-10 20:50         ` Sitsofe Wheeler
@ 2014-12-10 23:43           ` KY Srinivasan
  0 siblings, 0 replies; 10+ messages in thread
From: KY Srinivasan @ 2014-12-10 23:43 UTC (permalink / raw)
  To: Sitsofe Wheeler; +Cc: gregkh, linux-kernel, devel, olaf, apw, jasowang



> -----Original Message-----
> From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> Sent: Wednesday, December 10, 2014 12:50 PM
> To: KY Srinivasan
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com
> Subject: Re: [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status
> from interrupt context
> 
> On Mon, Dec 08, 2014 at 06:04:35AM +0000, KY Srinivasan wrote:
> >
> > Greg has not committed these patches yet. One of the patches changes
> the balloon floor.
> > This means that the guest will not be ballooned down below the floor.
> > Is this what you are seeing? In our testing we did not see anything
> > unusual other than the floor being elevated (as per the design).
> 
> I applied the following:
> 
> drivers-scsi-storvsc-Fix-a-bug-in-handling-ring-buffer-failures-that-may-
> result-in-I-O-freeze.patch
> V2-1-3-Drivers-hv-hv_balloon-Make-adjustments-in-computing-the-
> floor.patch
> V2-2-3-Drivers-hv-hv_balloon-Fix-a-locking-bug-in-the-balloon-driver.patch
> V2-3-3-Drivers-hv-hv_balloon-Don-t-post-pressure-status-from-interrupt-
> context.patch
> 
> Initially things looked OK but now I'm starting to see the following which is
> rather worrying:
> 
> Dec 10 20:37:11 a kernel: BUG: unable to handle kernel NULL pointer
> dereference at           (null)
> Dec 10 20:37:11 a kernel: IP: [<ffffffff811c30a0>] commit_charge+0x20/0x90
> Dec 10 20:37:11 a kernel: PGD e44cb067 PUD e4495067 PMD 0 Dec 10 20:37:11
> a kernel: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC Dec 10 20:37:11 a kernel:
> CPU: 5 PID: 1490 Comm: ruby Not tainted 3.18.0.x86_64-01967-g86c6a2f-dirty
> #163 Dec 10 20:37:11 a kernel: Hardware name: Microsoft Corporation Virtual
> Machine/Virtual Machine, BIOS 090006  05/23/2012 Dec 10 20:37:11 a kernel:
> task: ffff8800e9bce040 ti: ffff880003890000 task.ti: ffff880003890000 Dec 10
> 20:37:11 a kernel: RIP: 0010:[<ffffffff811c30a0>]  [<ffffffff811c30a0>]
> commit_charge+0x20/0x90 Dec 10 20:37:11 a kernel: RSP:
> 0018:ffff880003893a88  EFLAGS: 00010246 Dec 10 20:37:11 a kernel: RAX:
> 0000000000000000 RBX: ffffea00048d0380 RCX: 0000000000000006 Dec 10
> 20:37:11 a kernel: RDX: 0000000000000480 RSI: ffff880108829bd8 RDI:
> 000000000012340e Dec 10 20:37:11 a kernel: RBP: ffff880003893ac8 R08:
> 0000000000000000 R09: 0000000000000000 Dec 10 20:37:11 a kernel: R10:
> 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 Dec 10
> 20:37:11 a kernel: R13: ffff880108829bd8 R14: ffff880017669c58 R15:
> 0000000000000000 Dec 10 20:37:11 a kernel: FS:  00007f4dc62fa740(0000)
> GS:ffff88010d4a0000(0000) knlGS:0000000000000000 Dec 10 20:37:11 a kernel:
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Dec 10 20:37:11 a kernel:
> CR2: 0000000000000000 CR3: 00000000f1459000 CR4: 00000000000406e0 Dec
> 10 20:37:11 a kernel: Stack:
> Dec 10 20:37:11 a kernel:  ffff8800e9bce040 ffffffff816f3950
> 0000000000000000 ffff880017669c58 Dec 10 20:37:11 a kernel:
> ffff880003893ac8 ffffea00048d0380 ffff880108829bd8 0000000000000000 Dec
> 10 20:37:11 a kernel:  ffff880003893af8 ffffffff811c6b36 ffff880003893af8
> ffffea00048d0380 Dec 10 20:37:11 a kernel: Call Trace:
> Dec 10 20:37:11 a kernel:  [<ffffffff816f3950>] ?
> _raw_spin_unlock_irq+0x30/0x50 Dec 10 20:37:11 a kernel:
> [<ffffffff811c6b36>] mem_cgroup_commit_charge+0x76/0x140
> Dec 10 20:37:11 a kernel:  [<ffffffff8115d8d5>]
> __add_to_page_cache_locked+0x1e5/0x2d0
> Dec 10 20:37:11 a kernel:  [<ffffffff8115dfb8>]
> add_to_page_cache_lru+0x28/0x80 Dec 10 20:37:11 a kernel:
> [<ffffffff8115f347>] pagecache_get_page+0x197/0x220 Dec 10 20:37:11 a
> kernel:  [<ffffffff81160cc3>] grab_cache_page_write_begin+0x33/0x50
> Dec 10 20:37:11 a kernel:  [<ffffffff81254fd7>]
> ext4_da_write_begin+0x157/0x340 Dec 10 20:37:11 a kernel:
> [<ffffffff81160da1>] generic_perform_write+0xc1/0x1d0 Dec 10 20:37:11 a
> kernel:  [<ffffffff81161138>] __generic_file_write_iter+0x288/0x340
> Dec 10 20:37:11 a kernel:  [<ffffffff8124a693>]
> ext4_file_write_iter+0x2f3/0x3b0 Dec 10 20:37:11 a kernel:
> [<ffffffff811cde47>] ? vfs_write+0xa7/0x1d0 Dec 10 20:37:11 a kernel:
> [<ffffffff811cdc31>] new_sync_write+0x81/0xb0 Dec 10 20:37:11 a kernel:
> [<ffffffff811cde6b>] vfs_write+0xcb/0x1d0 Dec 10 20:37:11 a kernel:
> [<ffffffff811ce069>] SyS_write+0x49/0xb0 Dec 10 20:37:11 a kernel:
> [<ffffffff816f45a9>] system_call_fastpath+0x12/0x17 Dec 10 20:37:11 a
> kernel: Code: 5d c3 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 55 49
> 89 f5 41 54 41 89 d4 53 48 89 fb 48 83 ec 28 e8 90 3e 00 00 <f6> 00 01 74 1b 48 c7
> c6 e0 f1 9e 81 48 89 df e8 cc 4f fc ff 0f Dec 10 20:37:11 a kernel: RIP
> [<ffffffff811c30a0>] commit_charge+0x20/0x90 Dec 10 20:37:11 a kernel:  RSP
> <ffff880003893a88> Dec 10 20:37:11 a kernel: CR2: 0000000000000000 Dec 10
> 20:37:11 a kernel: BUG: unable to handle kernel Dec 10 20:37:11 a kernel: ---[
> end trace 0ae405bbdfb1f416 ]--- Dec 10 20:37:11 a kernel: NULL pointer
> dereference
> Dec 10 20:37:11 a kernel:  at           (null)
> Dec 10 20:37:11 a kernel: IP: [<ffffffff811c30a0>] commit_charge+0x20/0x90
> Dec 10 20:37:11 a kernel: PGD f17d4067 PUD f1567067 PMD 0 Dec 10 20:37:12
> a kernel: Oops: 0000 [#2] SMP DEBUG_PAGEALLOC
> Dec 10 20:37:12 a kernel: CPU: 2 PID: 25465 Comm: ruby Tainted: G      D
> 3.18.0.x86_64-01967-g86c6a2f-dirty #163
> Dec 10 20:37:12 a kernel: Hardware name: Microsoft Corporation Virtual
> Machine/Virtual Machine, BIOS 090006  05/23/2012 Dec 10 20:37:12 a kernel:
> task: ffff880011a16040 ti: ffff880098754000 task.ti: ffff880098754000 Dec 10
> 20:37:12 a kernel: init_memory_mapping: [mem 0x128000000-0x12fffffff]
> Dec 10 20:37:12 a kernel:  [mem 0x128000000-0x12fffffff] page 4k Dec 10
> 20:37:12 a kernel:  [ffffea0004800000-ffffea00049fffff] PMD ->
> [ffff8800c7400000-ffff8800c75fffff] on node 0 Dec 10 20:37:12 a kernel: RIP:
> 0010:[<ffffffff811c30a0>]  [<ffffffff811c30a0>] commit_charge+0x20/0x90
> Dec 10 20:37:12 a kernel: RSP: 0000:ffff880098757d18  EFLAGS: 00010246 Dec
> 10 20:37:12 a kernel: RAX: 0000000000000000 RBX: ffffea0004915300 RCX:
> 0000000000000001 Dec 10 20:37:12 a kernel: RDX: 0000000000000480 RSI:
> ffff880108829bd8 RDI: 000000000012454c Dec 10 20:37:12 a kernel: RBP:
> ffff880098757d58 R08: 0000000000000006 R09: 0000000000000000 Dec 10
> 20:37:12 a kernel: R10: ffff880011a16040 R11: 0000000000000000 R12:
> 0000000000000000 Dec 10 20:37:12 a kernel: R13: ffff880108829bd8 R14:
> ffff8800f159a5f0 R15: ffff88006b3bc600 Dec 10 20:37:12 a kernel: FS:
> 00007f0836edf700(0000) GS:ffff88010d440000(0000) knlGS:0000000000000000
> Dec 10 20:37:12 a kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Dec 10 20:37:12 a kernel: CR2: 0000000000000000 CR3: 00000000b8bfd000 CR4:
> 00000000000406e0 Dec 10 20:37:12 a kernel: Stack:
> Dec 10 20:37:12 a kernel:  00000000811bf285 ffff88000723e118
> ffff880108829bd8 ffff88000723e100 Dec 10 20:37:12 a kernel:
> ffffea0004915300 ffffea0004915300 ffff880108829bd8 ffff88000613a280 Dec
> 10 20:37:12 a kernel:  ffff880098757d88 ffffffff811c6b36 ffffffff8118d6fc
> 00007f08200bea58 Dec 10 20:37:12 a kernel: Call Trace:
> Dec 10 20:37:12 a kernel:  [<ffffffff811c6b36>]
> mem_cgroup_commit_charge+0x76/0x140
> Dec 10 20:37:12 a kernel:  [<ffffffff8118d6fc>] ?
> handle_mm_fault+0x62c/0x12a0 Dec 10 20:37:12 a kernel:
> [<ffffffff8118d742>] handle_mm_fault+0x672/0x12a0 Dec 10 20:37:12 a
> kernel:  [<ffffffff81041a13>] ? __do_page_fault+0x1c3/0x4f0 Dec 10 20:37:12
> a kernel:  [<ffffffff81041ce0>] __do_page_fault+0x490/0x4f0 Dec 10 20:37:12
> a kernel:  [<ffffffff810bf2cd>] ? trace_hardirqs_on+0xd/0x10 Dec 10 20:37:12
> a kernel:  [<ffffffff816f3950>] ? _raw_spin_unlock_irq+0x30/0x50 Dec 10
> 20:37:12 a kernel:  [<ffffffff81097a88>] ? finish_task_switch+0x88/0x100 Dec
> 10 20:37:12 a kernel:  [<ffffffff81097a4a>] ? finish_task_switch+0x4a/0x100
> Dec 10 20:37:12 a kernel:  [<ffffffff816ee380>] ? __schedule+0x6a0/0x830
> Dec 10 20:37:12 a kernel:  [<ffffffff813b24ed>] ?
> trace_hardirqs_off_thunk+0x3a/0x3c
> Dec 10 20:37:12 a kernel:  [<ffffffff81041d92>] do_page_fault+0x22/0x30 Dec
> 10 20:37:12 a kernel:  [<ffffffff816f6398>] page_fault+0x28/0x30 Dec 10
> 20:37:12 a kernel: Code: 5d c3 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89
> e5 41 55 49 89 f5 41 54 41 89 d4 53 48 89 fb 48 83 ec 28 e8 90 3e 00 00 <f6> 00
> 01 74 1b 48 c7 c6 e0 f1 9e 81 48 89 df e8 cc 4f fc ff 0f Dec 10 20:37:12 a kernel:
> RIP  [<ffffffff811c30a0>] commit_charge+0x20/0x90 Dec 10 20:37:12 a kernel:
> RSP <ffff880098757d18> Dec 10 20:37:12 a kernel: CR2: 0000000000000000 Dec
> 10 20:37:12 a kernel: ---[ end trace 0ae405bbdfb1f417 ]--- Dec 10 20:37:12 a
> kernel: BUG: sleeping function called from invalid context at
> kernel/locking/rwsem.c:41 Dec 10 20:37:12 a kernel: in_atomic(): 1,
> irqs_disabled(): 1, pid: 25465, name: ruby Dec 10 20:37:12 a kernel: INFO:
> lockdep is turned off.
> Dec 10 20:37:12 a kernel: irq event stamp: 2431342 Dec 10 20:37:12 a kernel:
> hardirqs last  enabled at (2431341): [<ffffffff816f38fd>]
> _raw_spin_unlock_irqrestore+0x4d/0x70
> Dec 10 20:37:12 a kernel: hardirqs last disabled at (2431342):
> [<ffffffff816f37dd>] _raw_spin_lock_irq+0x1d/0x60 Dec 10 20:37:12 a kernel:
> softirqs last  enabled at (2431322): [<ffffffff81078458>]
> __do_softirq+0x298/0x340 Dec 10 20:37:12 a kernel: softirqs last disabled at
> (2431317): [<ffffffff810787c8>] irq_exit+0x58/0xc0
> Dec 10 20:37:12 a kernel: CPU: 2 PID: 25465 Comm: ruby Tainted: G      D
> 3.18.0.x86_64-01967-g86c6a2f-dirty #163
> Dec 10 20:37:12 a kernel: Hardware name: Microsoft Corporation Virtual
> Machine/Virtual Machine, BIOS 090006  05/23/2012 Dec 10 20:37:12 a kernel:
> 0000000000000029 ffff8800987578f8 ffffffff816ea99f 0000000000000000 Dec
> 10 20:37:12 a kernel:  ffff880011a16040 ffff880098757918 ffffffff810a2dc5
> ffff880098757948 Dec 10 20:37:12 a kernel:  ffffffff819d796f ffff880098757948
> ffffffff810a2e46 ffffffff82b828c2 Dec 10 20:37:12 a kernel: Call Trace:
> Dec 10 20:37:12 a kernel:  [<ffffffff816ea99f>] dump_stack+0x4e/0x68 Dec 10
> 20:37:12 a kernel:  [<ffffffff810a2dc5>] ___might_sleep+0x115/0x120 Dec 10
> 20:37:12 a kernel:  [<ffffffff810a2e46>] __might_sleep+0x76/0xa0 Dec 10
> 20:37:12 a kernel:  [<ffffffff816f1f04>] down_read+0x24/0x70 Dec 10 20:37:12
> a kernel:  [<ffffffff81082de4>] exit_signals+0x24/0x140 Dec 10 20:37:12 a
> kernel:  [<ffffffff81076714>] do_exit+0x134/0xa80 Dec 10 20:37:12 a kernel:
> [<ffffffff810cb8cc>] ? kmsg_dump+0xfc/0x110 Dec 10 20:37:12 a kernel:
> [<ffffffff810cb7f5>] ? kmsg_dump+0x25/0x110 Dec 10 20:37:12 a kernel:
> [<ffffffff810064e8>] oops_end+0xa8/0xc0 Dec 10 20:37:12 a kernel:
> [<ffffffff816e53bc>] no_context+0x319/0x362 Dec 10 20:37:12 a kernel:
> [<ffffffff816e55d0>] __bad_area_nosemaphore+0x1cb/0x1ea
> Dec 10 20:37:12 a kernel:  [<ffffffff816e5602>]
> bad_area_nosemaphore+0x13/0x15 Dec 10 20:37:12 a kernel:
> [<ffffffff81041a3e>] __do_page_fault+0x1ee/0x4f0 Dec 10 20:37:12 a kernel:
> [<ffffffff811680d5>] ? __alloc_pages_nodemask+0x225/0xaf0
> Dec 10 20:37:12 a kernel:  [<ffffffff813b24ed>] ?
> trace_hardirqs_off_thunk+0x3a/0x3c
> Dec 10 20:37:12 a kernel:  [<ffffffff81041d92>] do_page_fault+0x22/0x30 Dec
> 10 20:37:12 a kernel:  [<ffffffff816f6398>] page_fault+0x28/0x30 Dec 10
> 20:37:12 a kernel:  [<ffffffff811c30a0>] ? commit_charge+0x20/0x90 Dec 10
> 20:37:12 a kernel:  [<ffffffff811c30a0>] ? commit_charge+0x20/0x90 Dec 10
> 20:37:12 a kernel:  [<ffffffff811c6b36>]
> mem_cgroup_commit_charge+0x76/0x140
> Dec 10 20:37:12 a kernel:  [<ffffffff8118d6fc>] ?
> handle_mm_fault+0x62c/0x12a0 Dec 10 20:37:12 a kernel:
> [<ffffffff8118d742>] handle_mm_fault+0x672/0x12a0 Dec 10 20:37:12 a
> kernel:  [<ffffffff81041a13>] ? __do_page_fault+0x1c3/0x4f0 Dec 10 20:37:12
> a kernel:  [<ffffffff81041ce0>] __do_page_fault+0x490/0x4f0 Dec 10 20:37:12
> a kernel:  [<ffffffff810bf2cd>] ? trace_hardirqs_on+0xd/0x10 Dec 10 20:37:12
> a kernel:  [<ffffffff816f3950>] ? _raw_spin_unlock_irq+0x30/0x50 Dec 10
> 20:37:12 a kernel:  [<ffffffff81097a88>] ? finish_task_switch+0x88/0x100 Dec
> 10 20:37:12 a kernel:  [<ffffffff81097a4a>] ? finish_task_switch+0x4a/0x100
> Dec 10 20:37:12 a kernel:  [<ffffffff816ee380>] ? __schedule+0x6a0/0x830
> Dec 10 20:37:12 a kernel:  [<ffffffff813b24ed>] ?
> trace_hardirqs_off_thunk+0x3a/0x3c
> Dec 10 20:37:12 a kernel:  [<ffffffff81041d92>] do_page_fault+0x22/0x30 Dec
> 10 20:37:12 a kernel:  [<ffffffff816f6398>] page_fault+0x28/0x30 Dec 10
> 20:37:12 a kernel: note: ruby[25465] exited with preempt_count 1 Dec 10
> 20:37:16 a kernel: init_memory_mapping: [mem 0x130000000-0x137ffffff]
> Dec 10 20:37:16 a kernel:  [mem 0x130000000-0x137ffffff] page 4k Dec 10
> 20:37:16 a kernel:  [ffffea0004a00000-ffffea0004bfffff] PMD ->
> [ffff880093200000-ffff8800933fffff] on node 0
> Dec 10 20:37:17 a kernel: BUG: unable to handle kernel NULL pointer
> dereference at           (null)
> Dec 10 20:37:17 a kernel: IP: [<ffffffff811c30a0>] commit_charge+0x20/0x90
> 
> Are these Hyper-V related?

I cannot see how the patches that you have applied can cause this problem. What do you need
to run to trigger this problem. Do you see this issue even without these patches.

Regards,

K. Y 

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-12-10 23:43 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-02 22:28 [PATCH 0/3] Drivers: hv: hv_balloon K. Y. Srinivasan
2014-12-02 22:29 ` [PATCH 1/3] Drivers: hv: hv_balloon: Make adjustments in computing the floor K. Y. Srinivasan
2014-12-02 21:51   ` Dan Carpenter
2014-12-02 22:03     ` KY Srinivasan
2014-12-02 22:29   ` [PATCH 2/3] Drivers: hv: hv_balloon: Fix a locking bug in the balloon driver K. Y. Srinivasan
2014-12-02 22:29   ` [PATCH 3/3] Drivers: hv: hv_balloon: Don't post pressure status from interrupt context K. Y. Srinivasan
2014-12-07  8:04     ` Sitsofe Wheeler
2014-12-08  6:04       ` KY Srinivasan
2014-12-10 20:50         ` Sitsofe Wheeler
2014-12-10 23:43           ` KY Srinivasan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.