[PATCH] Xen bug-fixes for 2.6.39 (already in 2.6.40)

[PATCH] Xen bug-fixes for 2.6.39 (already in 2.6.40)

[Konrad, Rzeszutek, Wilk]

Hey stable-tree maintainer(s).

The follow four patches are in the 2.6.40 tree and should be back-ported to 2.6.39 (only).
I forgot to CC:stable on them, so manually doing it here.

The four patches in question have the following git commits:

8c5950881c3b5e6e350e4b0438a8ccc513d90df9
    xen/p2m: Create entries in the P2M_MFN trees's to track 1-1 mappings
0f16d0dfcdb5aab97d9e368f008b070b5b3ec6d3
    xen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit
15bfc094517db2ddf38ca7ed47f3a1c0ad24f7c4
    xen/setup: Ignore E820_UNUSABLE when setting 1-1 mappings.
7899891c7d161752f29abcc9bc0a9c6c3a3af26c
    xen mmu: fix a race window causing leave_mm BUG()

And are part of this email chain. Please apply them to 2.6.39.1 tree.

Thank you.

[PATCH] xen mmu: fix a race window causing leave_mm BUG()

[Konrad, Rzeszutek, Wilk]

From: Tian, Kevin <kevin.tian@intel.com>

There's a race window in xen_drop_mm_ref, where remote cpu may exit
dirty bitmap between the check on this cpu and the point where remote
cpu handles drop request. So in drop_other_mm_ref we need check
whether TLB state is still lazy before calling into leave_mm. This
bug is rarely observed in earlier kernel, but exaggerated by the
commit 831d52bc153971b70e64eccfbed2b232394f22f8
("x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm")
which clears bitmap after changing the TLB state. the call trace is as below:

---------------------------------
kernel BUG at arch/x86/mm/tlb.c:61!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
CPU 1
Modules linked in: 8021q garp xen_netback xen_blkback blktap blkback_pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sbs sbshc parport_pc lp parport ses enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device serio_raw bnx2 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iTCO_wdt snd soundcore snd_page_alloc i2c_i801 iTCO_vendor_support i2c_core pcs pkr pata_acpi ata_generic ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table]
Pid: 25581, comm: khelper Not tainted 2.6.32.36fixxen #1 Tecal RH2285
RIP: e030:[<ffffffff8103a3cb>]  [<ffffffff8103a3cb>] leave_mm+0x15/0x46
RSP: e02b:ffff88002805be48  EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88015f8e2da0
RDX: ffff88002805be78 RSI: 0000000000000000 RDI: 0000000000000001
RBP: ffff88002805be48 R08: ffff88009d662000 R09: dead000000200200
R10: dead000000100100 R11: ffffffff814472b2 R12: ffff88009bfc1880
R13: ffff880028063020 R14: 00000000000004f6 R15: 0000000000000000
FS:  00007f62362d66e0(0000) GS:ffff880028058000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000003aabc11909 CR3: 000000009b8ca000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000 00
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process khelper (pid: 25581, threadinfo ffff88007691e000, task ffff88009b92db40)
Stack:
 ffff88002805be68 ffffffff8100e4ae 0000000000000001 ffff88009d733b88
<0> ffff88002805be98 ffffffff81087224 ffff88002805be78 ffff88002805be78
<0> ffff88015f808360 00000000000004f6 ffff88002805bea8 ffffffff81010108
Call Trace:
 <IRQ>
 [<ffffffff8100e4ae>] drop_other_mm_ref+0x2a/0x53
 [<ffffffff81087224>] generic_smp_call_function_single_interrupt+0xd8/0xfc
 [<ffffffff81010108>] xen_call_function_single_interrupt+0x13/0x28
 [<ffffffff810a936a>] handle_IRQ_event+0x66/0x120
 [<ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e
 [<ffffffff8128c1c0>] __xen_evtchn_do_upcall+0x1ab/0x27d
 [<ffffffff8128dd11>] xen_evtchn_do_upcall+0x33/0x46
 [<ffffffff81013efe>] xen_do_hyper visor_callback+0x1e/0x30
 <EOI>
 [<ffffffff814472b2>] ? _spin_unlock_irqrestore+0x15/0x17
 [<ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff81113f71>] ? flush_old_exec+0x3ac/0x500
 [<ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
 [<ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
 [<ffffffff8115115d>] ? load_elf_binary+0x398/0x17ef
 [<ffffffff81042fcf>] ? need_resched+0x23/0x2d
 [<ffffffff811f4648>] ? process_measurement+0xc0/0xd7
 [<ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
 [<ffffffff81113094>] ? search_binary_handler+0xc8/0x255
 [<ffffffff81114362>] ? do_execve+0x1c3/0x29e
 [<ffffffff8101155d>] ? sys_execve+0x43/0x5d
 [<ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
 [<ffffffff81013e28>] ? kernel_execve+0x68/0xd0
 [<ffffffff 8106fc45>] ? __call_usermodehelper+0x0/0x6f
 [<ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff8106fb64>] ? ____call_usermodehelper+0x113/0x11e
 [<ffffffff81013daa>] ? child_rip+0xa/0x20
 [<ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
 [<ffffffff81012f91>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8101371d>] ? retint_restore_args+0x5/0x6
 [<ffffffff81013da0>] ? child_rip+0x0/0x20
Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8
RIP  [<ffffffff8103a3cb>] leave_mm+0x15/0x46
 RSP <ffff88002805be48>
---[ end trace ce9cee6832a9c503 ]---

Tested-by: Maoxiaoyun<tinnycloud@hotmail.com>
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
[v1: Fleshed out the git description a bit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5e92b61..4fd7387 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1140,7 +1140,7 @@ static void drop_other_mm_ref(void *info)
 
 	active_mm = percpu_read(cpu_tlbstate.active_mm);
 
-	if (active_mm == mm)
+	if (active_mm == mm && percpu_read(cpu_tlbstate.state) != TLBSTATE_OK)
 		leave_mm(smp_processor_id());
 
 	/* If this cpu still has a stale cr3 reference, then make sure
-- 
1.7.4.1

[PATCH] xen/p2m: Create entries in the P2M_MFN trees's to track 1-1 mappings

[Konrad, Rzeszutek, Wilk]

From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

.. when applicable. We need to track in the p2m_mfn and
p2m_mfn_p the MFNs and pointers, respectivly, for the P2M entries
that are allocated for the identity mappings. Without this,
a PV domain with an E820 that triggers the 1-1 mapping to kick in,
won't be able to be restored as the P2M won't have the identity
mappings.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c |   30 ++++++++++++++++++++++++++++--
 1 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 141eb0d..a01e653 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -522,11 +522,20 @@ static bool __init __early_alloc_p2m(unsigned long pfn)
 	/* Boundary cross-over for the edges: */
 	if (idx) {
 		unsigned long *p2m = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		unsigned long *mid_mfn_p;
 
 		p2m_init(p2m);
 
 		p2m_top[topidx][mididx] = p2m;
 
+		/* For save/restore we need to MFN of the P2M saved */
+		
+		mid_mfn_p = p2m_top_mfn_p[topidx];
+		WARN(mid_mfn_p[mididx] != virt_to_mfn(p2m_missing),
+			"P2M_TOP_P[%d][%d] != MFN of p2m_missing!\n",
+			topidx, mididx);
+		mid_mfn_p[mididx] = virt_to_mfn(p2m);
+
 	}
 	return idx != 0;
 }
@@ -549,12 +558,29 @@ unsigned long __init set_phys_range_identity(unsigned long pfn_s,
 		pfn += P2M_MID_PER_PAGE * P2M_PER_PAGE)
 	{
 		unsigned topidx = p2m_top_index(pfn);
-		if (p2m_top[topidx] == p2m_mid_missing) {
-			unsigned long **mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
+		unsigned long *mid_mfn_p;
+		unsigned long **mid;
+
+		mid = p2m_top[topidx];
+		mid_mfn_p = p2m_top_mfn_p[topidx];
+		if (mid == p2m_mid_missing) {
+			mid = extend_brk(PAGE_SIZE, PAGE_SIZE);
 
 			p2m_mid_init(mid);
 
 			p2m_top[topidx] = mid;
+
+			BUG_ON(mid_mfn_p != p2m_mid_missing_mfn);
+		}
+		/* And the save/restore P2M tables.. */
+		if (mid_mfn_p == p2m_mid_missing_mfn) {
+			mid_mfn_p = extend_brk(PAGE_SIZE, PAGE_SIZE);
+			p2m_mid_mfn_init(mid_mfn_p);
+
+			p2m_top_mfn_p[topidx] = mid_mfn_p;
+			p2m_top_mfn[topidx] = virt_to_mfn(mid_mfn_p);
+			/* Note: we don't set mid_mfn_p[midix] here,
+		 	 * look in __early_alloc_p2m */
 		}
 	}
 
-- 
1.7.4.1

[PATCH 1/2] xen/setup: Ignore E820_UNUSABLE when setting 1-1 mappings.

[Konrad, Rzeszutek, Wilk]

From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

When we parse the raw E820, the Xen hypervisor can set "E820_RAM"
to "E820_UNUSABLE" if the mem=X argument is used. As such we
should _not_ consider the E820_UNUSABLE as an 1-1 identity
mapping, but instead use the same case as for E820_RAM.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 90bac0a..fba4a6c 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -166,7 +166,7 @@ static unsigned long __init xen_set_identity(const struct e820entry *list,
 		if (last > end)
 			continue;
 
-		if (entry->type == E820_RAM) {
+		if ((entry->type == E820_RAM) || (entry->type == E820_UNUSABLE)) {
 			if (start > start_pci)
 				identity += set_phys_range_identity(
 						PFN_UP(start_pci), PFN_DOWN(start));
-- 
1.7.4.1

[PATCH 2/2] xen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit

[Konrad, Rzeszutek, Wilk]

From: Daniel Kiper <dkiper@net-space.pl>

git commit 24bdb0b62cc82120924762ae6bc85afc8c3f2b26 (xen: do not create
the extra e820 region at an addr lower than 4G) does not take into
account that ifdef CONFIG_X86_32 instead of e820_end_of_low_ram_pfn()
find_low_pfn_range() is called (both calls are from arch/x86/kernel/setup.c).
find_low_pfn_range() behaves correctly and does not require change in
xen_extra_mem_start initialization. Additionally, if xen_extra_mem_start
is initialized in the same way as ifdef CONFIG_X86_64 then memory hotplug
support for Xen balloon driver (under development) is broken.

Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index fba4a6c..ca6297b 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -227,7 +227,11 @@ char * __init xen_memory_setup(void)
 
 	memcpy(map_raw, map, sizeof(map));
 	e820.nr_map = 0;
+#ifdef CONFIG_X86_32
+	xen_extra_mem_start = mem_end;
+#else
 	xen_extra_mem_start = max((1ULL << 32), mem_end);
+#endif
 	for (i = 0; i < memmap.nr_entries; i++) {
 		unsigned long long end;
 
-- 
1.7.4.1

Re: [stable] [PATCH] Xen bug-fixes for 2.6.39 (already in 2.6.40)

[Greg KH]

On Wed, May 25, 2011 at 05:37:32PM -0400, Konrad@dumpdata.com wrote:
> Hey stable-tree maintainer(s).
> 
> The follow four patches are in the 2.6.40 tree and should be back-ported to 2.6.39 (only).
> I forgot to CC:stable on them, so manually doing it here.
> 
> The four patches in question have the following git commits:
> 
> 8c5950881c3b5e6e350e4b0438a8ccc513d90df9
>     xen/p2m: Create entries in the P2M_MFN trees's to track 1-1 mappings
> 0f16d0dfcdb5aab97d9e368f008b070b5b3ec6d3
>     xen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit
> 15bfc094517db2ddf38ca7ed47f3a1c0ad24f7c4
>     xen/setup: Ignore E820_UNUSABLE when setting 1-1 mappings.
> 7899891c7d161752f29abcc9bc0a9c6c3a3af26c
>     xen mmu: fix a race window causing leave_mm BUG()
> 
> And are part of this email chain. Please apply them to 2.6.39.1 tree.

I need an ack from the Xen maintainer and the original patch author
before I can accept these.  Please get them to provide this and I will
be glad to queue them up.

thanks,

greg k-h

Re: [stable] [PATCH] Xen bug-fixes for 2.6.39 (already in 2.6.40)

[Konrad Rzeszutek Wilk]

On Thu, May 26, 2011 at 12:02:39AM -0700, Greg KH wrote:
> On Wed, May 25, 2011 at 05:37:32PM -0400, Konrad@dumpdata.com wrote:
> > Hey stable-tree maintainer(s).
> > 
> > The follow four patches are in the 2.6.40 tree and should be back-ported to 2.6.39 (only).
> > I forgot to CC:stable on them, so manually doing it here.
> > 
> > The four patches in question have the following git commits:
> > 
> > 8c5950881c3b5e6e350e4b0438a8ccc513d90df9
> >     xen/p2m: Create entries in the P2M_MFN trees's to track 1-1 mappings
> > 0f16d0dfcdb5aab97d9e368f008b070b5b3ec6d3
> >     xen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit
> > 15bfc094517db2ddf38ca7ed47f3a1c0ad24f7c4
> >     xen/setup: Ignore E820_UNUSABLE when setting 1-1 mappings.
> > 7899891c7d161752f29abcc9bc0a9c6c3a3af26c
> >     xen mmu: fix a race window causing leave_mm BUG()
> > 
> > And are part of this email chain. Please apply them to 2.6.39.1 tree.
> 
> I need an ack from the Xen maintainer and the original patch author
> before I can accept these.  Please get them to provide this and I will

OK

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

(who is the Xen maintainer)

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
(who is also the original patch author on some of the patches)

Daniel and Kevin, can you guys Ack them please?

> be glad to queue them up.
> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

RE: [stable] [PATCH] Xen bug-fixes for 2.6.39 (already in 2.6.40)

[Tian, Kevin]

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Thursday, May 26, 2011 8:39 PM
> 
> On Thu, May 26, 2011 at 12:02:39AM -0700, Greg KH wrote:
> > On Wed, May 25, 2011 at 05:37:32PM -0400, Konrad@dumpdata.com wrote:
> > > Hey stable-tree maintainer(s).
> > >
> > > The follow four patches are in the 2.6.40 tree and should be back-ported to
> 2.6.39 (only).
> > > I forgot to CC:stable on them, so manually doing it here.
> > >
> > > The four patches in question have the following git commits:
> > >
> > > 8c5950881c3b5e6e350e4b0438a8ccc513d90df9
> > >     xen/p2m: Create entries in the P2M_MFN trees's to track 1-1
> mappings
> > > 0f16d0dfcdb5aab97d9e368f008b070b5b3ec6d3
> > >     xen/setup: Fix for incorrect xen_extra_mem_start initialization under
> 32-bit
> > > 15bfc094517db2ddf38ca7ed47f3a1c0ad24f7c4
> > >     xen/setup: Ignore E820_UNUSABLE when setting 1-1 mappings.
> > > 7899891c7d161752f29abcc9bc0a9c6c3a3af26c
> > >     xen mmu: fix a race window causing leave_mm BUG()
> > >
> > > And are part of this email chain. Please apply them to 2.6.39.1 tree.
> >
> > I need an ack from the Xen maintainer and the original patch author
> > before I can accept these.  Please get them to provide this and I will
> 
> OK
> 
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> (who is the Xen maintainer)
> 
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> (who is also the original patch author on some of the patches)
> 
> Daniel and Kevin, can you guys Ack them please?
> 

Acked-by: Kevin Tian <kevin.tian@intel.com>

Thanks
Kevin

Re: [stable] [PATCH] Xen bug-fixes for 2.6.39 (already in 2.6.40)

[Daniel Kiper]

On Thu, May 26, 2011 at 08:39:21AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, May 26, 2011 at 12:02:39AM -0700, Greg KH wrote:
> > On Wed, May 25, 2011 at 05:37:32PM -0400, Konrad@dumpdata.com wrote:
> > > Hey stable-tree maintainer(s).
> > >
> > > The follow four patches are in the 2.6.40 tree and should be back-ported to 2.6.39 (only).
> > > I forgot to CC:stable on them, so manually doing it here.
> > >
> > > The four patches in question have the following git commits:
> > >
> > > 8c5950881c3b5e6e350e4b0438a8ccc513d90df9
> > >     xen/p2m: Create entries in the P2M_MFN trees's to track 1-1 mappings
> > > 0f16d0dfcdb5aab97d9e368f008b070b5b3ec6d3
> > >     xen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit

Acked-by: Daniel Kiper <dkiper@net-space.pl>
(author of xen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit patch)

Daniel

Re: [stable] [PATCH] Xen bug-fixes for 2.6.39 (already in 2.6.40)

[Greg KH]

On Thu, May 26, 2011 at 08:39:21AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, May 26, 2011 at 12:02:39AM -0700, Greg KH wrote:
> > On Wed, May 25, 2011 at 05:37:32PM -0400, Konrad@dumpdata.com wrote:
> > > Hey stable-tree maintainer(s).
> > > 
> > > The follow four patches are in the 2.6.40 tree and should be back-ported to 2.6.39 (only).
> > > I forgot to CC:stable on them, so manually doing it here.
> > > 
> > > The four patches in question have the following git commits:
> > > 
> > > 8c5950881c3b5e6e350e4b0438a8ccc513d90df9
> > >     xen/p2m: Create entries in the P2M_MFN trees's to track 1-1 mappings
> > > 0f16d0dfcdb5aab97d9e368f008b070b5b3ec6d3
> > >     xen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit
> > > 15bfc094517db2ddf38ca7ed47f3a1c0ad24f7c4
> > >     xen/setup: Ignore E820_UNUSABLE when setting 1-1 mappings.
> > > 7899891c7d161752f29abcc9bc0a9c6c3a3af26c
> > >     xen mmu: fix a race window causing leave_mm BUG()
> > > 
> > > And are part of this email chain. Please apply them to 2.6.39.1 tree.
> > 
> > I need an ack from the Xen maintainer and the original patch author
> > before I can accept these.  Please get them to provide this and I will
> 
> OK
> 
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> (who is the Xen maintainer)
> 
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> (who is also the original patch author on some of the patches)

Thanks, as you didn't send the original request from your maintainer
address, how was I to know that you were the same Konrad Rzeszutek Wilk?  :)

thanks,

greg k-h

Re: [stable] [PATCH] Xen bug-fixes for 2.6.39 (already in 2.6.40)

[Konrad Rzeszutek Wilk]

> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > (who is the Xen maintainer)
> > 
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > (who is also the original patch author on some of the patches)
> 
> Thanks, as you didn't send the original request from your maintainer
> address, how was I to know that you were the same Konrad Rzeszutek Wilk?  :)

Sorry, I somehow mangled the git-send-email and managed to have my name
be split up and the domain name of machine I was on inserted. Ended up with
'Konrad@dumpdata.com', and 'Rzeszutek@dumpdata.com',.. <sigh>

Anyhow, thank you for taking the git commits.