linux/arch, branch v3.8.5

ARM: DMA-mapping: add missing GFP_DMA flag for atomic buffer allocation

2013-03-28T19:18:14Z

commit 9d1400cf79afb49584b4873eb22cd5130cb341db upstream. Atomic pool should always be allocated from DMA zone if such zone is available in the system to avoid issues caused by limited dma mask of any of the devices used for making an atomic allocation. Reported-by: Krzysztof Halasa Signed-off-by: Marek Szyprowski Signed-off-by: Greg Kroah-Hartman

x86-64: Fix the failure case in copy_user_handle_tail()

2013-03-28T19:18:02Z

commit 66db3feb486c01349f767b98ebb10b0c3d2d021b upstream. The increment of "to" in copy_user_handle_tail() will have incremented before a failure has been noted. This causes us to skip a byte in the failure case. Only do the increment when assured there is no failure. Signed-off-by: CQ Tang Link: http://lkml.kernel.org/r/20130318150221.8439.993.stgit@phlsvslse11.ph.intel.com Signed-off-by: Mike Marciniszyn Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

ARM: tegra: fix register address of slink controller

2013-03-28T19:17:48Z

commit 57471c8d3c22873f70813820e6b4d2d1fea9629d upstream. Fix typo on register address of slink3 controller where register address is wrongly set as 0x7000d480 but it is 0x7000d800. Signed-off-by: Laxman Dewangan Signed-off-by: Stephen Warren Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

s390/mm: fix flush_tlb_kernel_range()

2013-03-20T20:10:56Z

commit f6a70a07079518280022286a1dceb797d12e1edf upstream. Our flush_tlb_kernel_range() implementation calls __tlb_flush_mm() with &init_mm as argument. __tlb_flush_mm() however will only flush tlbs for the passed in mm if its mm_cpumask is not empty. For the init_mm however its mm_cpumask has never any bits set. Which in turn means that our flush_tlb_kernel_range() implementation doesn't work at all. This can be easily verified with a vmalloc/vfree loop which allocates a page, writes to it and then frees the page again. A crash will follow almost instantly. To fix this remove the cpumask_empty() check in __tlb_flush_mm() since there shouldn't be too many mms with a zero mm_cpumask, besides the init_mm of course. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman

s390: critical section cleanup vs. machine checks

2013-03-20T20:10:56Z

commit 6551fbdfd8b85d1ab5822ac98abb4fb449bcfae0 upstream. The current machine check code uses the registers stored by the machine in the lowcore at __LC_GPREGS_SAVE_AREA as the registers of the interrupted context. The registers 0-7 of a user process can get clobbered if a machine checks interrupts the execution of a critical section in entry[64].S. The reason is that the critical section cleanup code may need to modify the PSW and the registers for the previous context to get to the end of a critical section. If registers 0-7 have to be replaced the relevant copy will be in the registers, which invalidates the copy in the lowcore. The machine check handler needs to explicitly store registers 0-7 to the stack. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman

perf,x86: fix wrmsr_on_cpu() warning on suspend/resume

2013-03-20T20:10:56Z

commit 2a6e06b2aed6995af401dcd4feb5e79a0c7ea554 upstream. Commit 1d9d8639c063 ("perf,x86: fix kernel crash with PEBS/BTS after suspend/resume") fixed a crash when doing PEBS performance profiling after resuming, but in using init_debug_store_on_cpu() to restore the DS_AREA mtrr it also resulted in a new WARN_ON() triggering. init_debug_store_on_cpu() uses "wrmsr_on_cpu()", which in turn uses CPU cross-calls to do the MSR update. Which is not really valid at the early resume stage, and the warning is quite reasonable. Now, it all happens to _work_, for the simple reason that smp_call_function_single() ends up just doing the call directly on the CPU when the CPU number matches, but we really should just do the wrmsr() directly instead. This duplicates the wrmsr() logic, but hopefully we can just remove the wrmsr_on_cpu() version eventually. Reported-and-tested-by: Parag Warudkar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ARM: davinci: edma: fix dmaengine induced null pointer dereference on da830

2013-03-20T20:10:55Z

commit 069552777a121eb39da29de4bc0383483dbe1f7e upstream. This adds additional error checking to the private edma api implementation to catch the case where the edma_alloc_slot() has an invalid controller parameter. The edma dmaengine wrapper driver relies on this condition being handled in order to avoid setting up a second edma dmaengine instance on DA830. Verfied using a DA850 with the second EDMA controller platform instance removed to simulate a DA830 which only has a single EDMA controller. Reported-by: Tomas Novotny Signed-off-by: Matt Porter Tested-by: Tomas Novotny Signed-off-by: Sekhar Nori Signed-off-by: Greg Kroah-Hartman

powerpc: Rename USER_ESID_BITS* to ESID_BITS*

2013-03-20T20:10:55Z

commit af81d7878c641629f2693ae3fdaf74b4af14dfca upstream. Now we use ESID_BITS of kernel address to build proto vsid. So rename USER_ESIT_BITS to ESID_BITS Acked-by: Paul Mackerras Signed-off-by: Aneesh Kumar K.V Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc: Update kernel VSID range

2013-03-20T20:10:55Z

commit c60ac5693c47df32a2b4b18af97fca5635def015 upstream. This patch change the kernel VSID range so that we limit VSID_BITS to 37. This enables us to support 64TB with 65 bit VA (37+28). Without this patch we have boot hangs on platforms that only support 65 bit VA. With this patch we now have proto vsid generated as below: We first generate a 37-bit "proto-VSID". Proto-VSIDs are generated from mmu context id and effective segment id of the address. For user processes max context id is limited to ((1ul << 19) - 5) for kernel space, we use the top 4 context ids to map address as below 0x7fffc - [ 0xc000000000000000 - 0xc0003fffffffffff ] 0x7fffd - [ 0xd000000000000000 - 0xd0003fffffffffff ] 0x7fffe - [ 0xe000000000000000 - 0xe0003fffffffffff ] 0x7ffff - [ 0xf000000000000000 - 0xf0003fffffffffff ] Acked-by: Paul Mackerras Signed-off-by: Aneesh Kumar K.V Tested-by: Geoff Levand Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc: Make VSID_BITS* dependency explicit

2013-03-20T20:10:55Z

commit e39d1a471484662620651cd9520250d33843f235 upstream. VSID_BITS and VSID_BITS_1T depends on the context bits and user esid bits. Make the dependency explicit Acked-by: Paul Mackerras Signed-off-by: Aneesh Kumar K.V Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman