linux/arch, branch v2.6.37.2

ARM: Keep exit text/data around for SMP_ON_UP

2011-02-24T22:54:37Z

commit a9ad21fed09cb95d34af9474be0831525b30c4c6 upstream. When SMP_ON_UP is used and the spinlocks are inlined, we end up with inline spinlocks in the exit code, with references from the SMP alternatives section to the exit sections. This causes link time errors. Avoid this by placing the exit sections in the init-discarded region. Tested-by: Dave Martin Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: Ensure predictable endian state on signal handler entry

2011-02-24T22:54:37Z

commit 53399053eb505cf541b2405bd9d9bca5ecfb96fb upstream. Ensure a predictable endian state when entering signal handlers. This avoids programs which use SETEND to momentarily switch their endian state from having their signal handlers entered with an unpredictable endian state. Acked-by: Dave Martin Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

x86, mrst: Set correct APB timer IRQ affinity for secondary cpu

2011-02-24T22:54:31Z

This is a backport for 2.6.37 stable. The original commit ID is 6550904ddbc3c286798a87edf95eeebcc62bc58a Offlining the secondary CPU causes the timer irq affinity to be set to CPU 0. When the secondary CPU is back online again, the wrong irq affinity will be used. This patch ensures secondary per CPU timer always has the correct IRQ affinity when enabled. Signed-off-by: Jacob Pan LKML-Reference: <1294963604-18111-1-git-send-email-jacob.jun.pan@linux.intel.com> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

s390: remove task_show_regs

2011-02-24T22:54:30Z

commit 261cd298a8c363d7985e3482946edb4bfedacf98 upstream. task_show_regs used to be a debugging aid in the early bringup days of Linux on s390. /proc//status is a world readable file, it is not a good idea to show the registers of a process. The only correct fix is to remove task_show_regs. Reported-by: Al Viro Signed-off-by: Martin Schwidefsky Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86, hotplug: Fix powersavings with offlined cores on AMD

2011-02-24T22:54:30Z

Upstream commits: 93789b32dbf355e70f18b17a82e8661677a7f7fb, 1c9d16e35911090dee3f9313e6af13af623d66ee ea53069231f9317062910d6e772cca4ce93de8c8 made a CPU use monitor/mwait when offline. This is not the optimal choice for AMD wrt to powersavings and we'd prefer our cores to halt (i.e. enter C1) instead. For this, the same selection whether to use monitor/mwait has to be used as when we select the idle routine for the machine. With this patch, offlining cores 1-5 on a X6 machine allows core0 to boost again. [ hpa: putting this in urgent since it is a (power) regression fix ] Reported-by: Andreas Herrmann Cc: H. Peter Anvin Cc: Arjan van de Ven Cc: Len Brown Cc: Venkatesh Pallipadi Cc: Peter Zijlstra Signed-off-by: Borislav Petkov LKML-Reference: <1295534572-10730-1-git-send-email-bp@amd64.org> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

xen/p2m: Mark INVALID_P2M_ENTRY the mfn_list past max_pfn.

2011-02-24T22:54:26Z

commit cf04d120d9413de581437cf9a29f138ec1178f65 upstream. In case the mfn_list does not have enough entries to fill a p2m page we do not want the entries from max_pfn up to the boundary to be filled with unknown values. Hence set them to INVALID_P2M_ENTRY. Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Stefan Bader Signed-off-by: Greg Kroah-Hartman

xen: p2m: correctly initialize partial p2m leaf

2011-02-24T22:54:26Z

commit 8e1b4cf2108488ccfb9a3e7ed7cd85a435e01d4b upstream. After changing the p2m mapping to a tree by commit 58e05027b530ff081ecea68e38de8d59db8f87e0 xen: convert p2m to a 3 level tree and trying to boot a DomU with 615MB of memory, the following crash was observed in the dump: kernel direct mapping tables up to 26f00000 @ 1ec4000-1fff000 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] xen_set_pte+0x27/0x60 *pdpt = 0000000000000000 *pde = 0000000000000000 Adding further debug statements showed that when trying to set up pfn=0x26700 the returned mapping was invalid. pfn=0x266ff calling set_pte(0xc1fe77f8, 0x6b3003) pfn=0x26700 calling set_pte(0xc1fe7800, 0x3) Although the last_pfn obtained from the startup info is 0x26700, which should in turn not be hit, the additional 8MB which are added as extra memory normally seem to be ok. This lead to looking into the initial p2m tree construction, which uses the smaller value and assuming that there is other code handling the extra memory. When the p2m tree is set up, the leaves are directly pointed to the array which the domain builder set up. But if the mapping is not on a boundary that fits into one p2m page, this will result in the last leaf being only partially valid. And as the invalid entries are not initialized in that case, things go badly wrong. I am trying to fix that by checking whether the current leaf is a complete map and if not, allocate a completely new page and copy only the valid pointers there. This may not be the most efficient or elegant solution, but at least it seems to allow me booting DomUs with memory assignments all over the range. BugLink: http://bugs.launchpad.net/bugs/686692 [v2: Redid a bit of commit wording and fixed a compile warning] Signed-off-by: Stefan Bader Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

x86: Clear irqstack thread_info

2011-02-24T22:54:26Z

commit 7b698ea377e10b074ceef0d79218e6622d618421 upstream. Mathias Merz reported that v2.6.37 failed to boot on his system. Make sure that the thread_info part of the irqstack is initialized to zeroes. Reported-and-Tested-by: Matthias Merz Signed-off-by: Brian Gerst Acked-by: Pekka Enberg Cc: Arjan van de Ven Cc: Linus Torvalds LKML-Reference: Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

ARM: 6606/1: sa1100: Fix platform device registration

2011-02-24T22:54:25Z

commit 4f444e2b59dd4255d121b57ec41a4a8c5d6bce46 upstream. Since commit 7a5b4e16c880f8350d255dc188f81622905618c1, simpad devices don't boot anymore, since platform devices are registered too early. Fix by moving the registration from map_io to arch_initcall as done on other sa1100 boards. Signed-off-by: Jochen Friedrich Acked-by: Kristoffer Ericson Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm

2011-02-17T23:15:20Z

commit 831d52bc153971b70e64eccfbed2b232394f22f8 upstream. Clearing the cpu in prev's mm_cpumask early will avoid the flush tlb IPI's while the cr3 is still pointing to the prev mm. And this window can lead to the possibility of bogus TLB fills resulting in strange failures. One such problematic scenario is mentioned below. T1. CPU-1 is context switching from mm1 to mm2 context and got a NMI etc between the point of clearing the cpu from the mm_cpumask(mm1) and before reloading the cr3 with the new mm2. T2. CPU-2 is tearing down a specific vma for mm1 and will proceed with flushing the TLB for mm1. It doesn't send the flush TLB to CPU-1 as it doesn't see that cpu listed in the mm_cpumask(mm1). T3. After the TLB flush is complete, CPU-2 goes ahead and frees the page-table pages associated with the removed vma mapping. T4. CPU-2 now allocates those freed page-table pages for something else. T5. As the CR3 and TLB caches for mm1 is still active on CPU-1, CPU-1 can potentially speculate and walk through the page-table caches and can insert new TLB entries. As the page-table pages are already freed and being used on CPU-2, this page walk can potentially insert a bogus global TLB entry depending on the (random) contents of the page that is being used on CPU-2. T6. This bogus TLB entry being global will be active across future CR3 changes and can result in weird memory corruption etc. To avoid this issue, for the prev mm that is handing over the cpu to another mm, clear the cpu from the mm_cpumask(prev) after the cr3 is changed. Marking it for -stable, though we haven't seen any reported failure that can be attributed to this. Signed-off-by: Suresh Siddha Acked-by: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman