summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2015-01-07arm64: sanity checks: add missing AArch32 registersMark Rutland
We don't currently check a number of registers exposed to AArch32 guests (MVFR{0,1,2}_EL1 and ID_DFR0_EL1), despite the fact these describe AArch32 feature support exposed to userspace and KVM guests similarly to AArch64 registers which we do check. We do not expect these registers to vary across a set of CPUs. This patch adds said registers to the cpuinfo framework and sanity checks. No sanity check failures have been observed on a current ARMv8 big.LITTLE platform (Juno). Cc: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-01-07arm64: Remove unused prepare_to_copy()Tobias Klauser
prepare_to_copy() was removed from all architectures supported at that time in commit 55ccf3fe3f9a ("fork: move the real prepare_to_copy() users to arch_dup_task_struct()"). Remove it from arm64 as well. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-01-07arm64: Correct __NR_compat_syscalls for bpfMark Rutland
Commit 97b56be10352a70c (arm64: compat: Enable bpf syscall) made the usual mistake of forgetting to update __NR_compat_syscalls. Due to this, when el0_sync_compat calls el0_svc_naked, the test against sc_nr (__NR_compat_syscalls) will fail, and we'll call ni_sys, returning -ENOSYS to userspace. This patch bumps __NR_compat_syscalls appropriately, enabling the use of the bpf syscall from compat tasks. Due to the reorganisation of unistd{,32}.h as part of commit f3e5c847ec3d12b4 (arm64: Add __NR_* definitions for compat syscalls) it is not currently possible to include both headers and sanity-check the value of __NR_compat_syscalls at build-time to prevent this from happening again. Additional rework is required to make such niceties a possibility. Cc: Will Deacon <will.deacon@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-01-07s390/timex: fix get_tod_clock_ext() inline assemblyChen Gang
For C language, it treats array parameter as a pointer, so sizeof for an array parameter is equal to sizeof for a pointer, which causes compiler warning (with allmodconfig by gcc 5): ./arch/s390/include/asm/timex.h: In function 'get_tod_clock_ext': ./arch/s390/include/asm/timex.h:76:32: warning: 'sizeof' on array function parameter 'clk' will return size of 'char *' [-Wsizeof-array-argument] typedef struct { char _[sizeof(clk)]; } addrtype; ^ Can use macro CLOCK_STORE_SIZE instead of all related hard code numbers, which also can avoid this warning. And also add a tab to CLOCK_TICK_RATE definition to match coding styles. [heiko.carstens@de.ibm.com]: Chen's patch actually fixes a bug within the get_tod_clock_ext() inline assembly where we incorrectly tell the compiler that only 8 bytes of memory get changed instead of 16 bytes. This would allow gcc to generate incorrect code. Right now this doesn't seem to be the case. Also slightly changed the patch a bit. - renamed CLOCK_STORE_SIZE to STORE_CLOCK_EXT_SIZE - changed get_tod_clock_ext() to receive a char pointer parameter Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-01-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
2015-01-06Merge branches 'acpi-pm', 'acpi-processor' and 'acpi-video'Rafael J. Wysocki
* acpi-pm: ACPI / PM: Fix PM initialization for devices that are not present * acpi-processor: ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu() ACPI / processor: Convert apic_id to phys_id to make it arch agnostic * acpi-video: ACPI / video: Add disable_native_backlight quirk for Dell XPS15 L521X
2015-01-05Merge tag 'powerpc-3.19-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux Pull powerpc fixes from Michael Ellerman: - Wire up sys_execveat(). Tested on 32 & 64 bit. - Fix for kdump on LE systems with cpus hot unplugged. - Revert Anton's fix for "kernel BUG at kernel/smpboot.c:134!", this broke other platforms, we'll do a proper fix for 3.20. * tag 'powerpc-3.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux: Revert "powerpc: Secondary CPUs must set cpu_callin_map after setting active and online" powerpc/kdump: Ignore failure in enabling big endian exception during crash powerpc: Wire up sys_execveat() syscall
2015-01-05ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu()Hanjun Guo
acpi_map_lsapic() will allocate a logical CPU number and map it to physical CPU id (such as APIC id) for the hot-added CPU, it will also do some mapping for NUMA node id and etc, acpi_unmap_lsapic() will do the reverse. We can see that the name of the function is a little bit confusing and arch (IA64) dependent so rename them as acpi_(un)map_cpu() to make arch agnostic and explicit. Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-05[IA64] Enable execveat syscall for ia64Tony Luck
See commit 51f39a1f0cea1cacf8c787f652f26dfee9611874 syscalls: implement execveat() system call Signed-off-by: Tony Luck <tony.luck@intel.com>
2015-01-05crypto: sha-mb - Add avx2_supported check.Vinson Lee
This patch fixes this allyesconfig target build error with older binutils. LD arch/x86/crypto/built-in.o ld: arch/x86/crypto/sha-mb/built-in.o: No such file: No such file or directory Cc: stable@vger.kernel.org # 3.18+ Signed-off-by: Vinson Lee <vlee@twitter.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-01-05crypto: aesni - fix "by8" variant for 128 bit keysMathias Krause
The "by8" counter mode optimization is broken for 128 bit keys with input data longer than 128 bytes. It uses the wrong key material for en- and decryption. The key registers xkey0, xkey4, xkey8 and xkey12 need to be preserved in case we're handling more than 128 bytes of input data -- they won't get reloaded after the initial load. They must therefore be (a) loaded on the first iteration and (b) be preserved for the latter ones. The implementation for 128 bit keys does not comply with (a) nor (b). Fix this by bringing the implementation back to its original source and correctly load the key registers and preserve their values by *not* re-using the registers for other purposes. Kudos to James for reporting the issue and providing a test case showing the discrepancies. Reported-by: James Yonan <james@openvpn.net> Cc: Chandramouli Narayanan <mouli@linux.intel.com> Cc: <stable@vger.kernel.org> # v3.18 Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-01-04Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/umlLinus Torvalds
Pull UML fixes from Richard Weinberger: "Two fixes for UML regressions. Nothing exciting" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml: x86, um: actually mark system call tables readonly um: Skip futex_atomic_cmpxchg_inatomic() test
2015-01-04Revert "ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo"Pavel Machek
Commit 9fc2105aeaaf ("ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo") breaks audio in python, and probably elsewhere, with message FATAL: cannot locate cpu MHz in /proc/cpuinfo I'm not the first one to hit it, see for example https://theredblacktree.wordpress.com/2014/08/10/fatal-cannot-locate-cpu-mhz-in-proccpuinfo/ https://devtalk.nvidia.com/default/topic/765800/workaround-for-fatal-cannot-locate-cpu-mhz-in-proc-cpuinf/?offset=1 Reading original changelog, I have to say "Stop breaking working setups. You know who you are!". Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-01-04x86, um: actually mark system call tables readonlyDaniel Borkmann
Commit a074335a370e ("x86, um: Mark system call tables readonly") was supposed to mark the sys_call_table in UML as RO by adding the const, but it doesn't have the desired effect as it's nevertheless being placed into the data section since __cacheline_aligned enforces sys_call_table being placed into .data..cacheline_aligned instead. We need to use the ____cacheline_aligned version instead to fix this issue. Before: $ nm -v arch/x86/um/sys_call_table_64.o | grep -1 "sys_call_table" U sys_writev 0000000000000000 D sys_call_table 0000000000000000 D syscall_table_size After: $ nm -v arch/x86/um/sys_call_table_64.o | grep -1 "sys_call_table" U sys_writev 0000000000000000 R sys_call_table 0000000000000000 D syscall_table_size Fixes: a074335a370e ("x86, um: Mark system call tables readonly") Cc: H. Peter Anvin <hpa@zytor.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2015-01-04um: Skip futex_atomic_cmpxchg_inatomic() testRichard Weinberger
futex_atomic_cmpxchg_inatomic() does not work on UML because it triggers a copy_from_user() in kernel context. On UML copy_from_user() can only be used if the kernel was called by a real user space process such that UML can use ptrace() to fetch the value. Reported-by: Miklos Szeredi <miklos@szeredi.hu> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Richard Weinberger <richard@nod.at> Tested-by: Daniel Walter <d.walter@0x90.at>
2015-01-02microblaze: include the new timecounter header.Richard Cochran
The timecounter/cyclecounter code has moved, so users need the new include. Signed-off-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-01Merge tag 'pr-20141223-x86-vdso' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux into x86/urgent Pull VDSO fix from Andy Lutomirski: "This is hopefully the last vdso fix for 3.19. It should be very safe (it just adds a volatile). I don't think it fixes an actual bug (the __getcpu calls in the pvclock code may not have been needed in the first place), but discussion on that point is ongoing. It also fixes a big performance issue in 3.18 and earlier in which the lsl instructions in vclock_gettime got hoisted so far up the function that they happened even when the function they were in was never called. n 3.19, the performance issue seems to be gone due to the whims of my compiler and some interaction with a branch that's now gone. I'll hopefully have a much bigger overhaul of the pvclock code for 3.20, but it needs careful review." Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-12-31ARM: dts: rockchip: enable gmac on RK3288 evb boardRoger Chen
enable gmac in rk3288-evb-rk808.dts changes since v2: 1. add fixed regulator for PHY 2. remove power-gpio, reset-gpio, phyirq-gpio, pmu_regulator setting 3. add "snps,reset-gpio", "snps,reset-active-low;" "snps,reset-delays-us" Signed-off-by: Roger Chen <roger.chen@rock-chips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-31ARM: dts: rockchip: add gmac info for rk3288Roger Chen
add gmac info in rk3288.dtsi for GMAC driver changes since v2: 1. add drive-strength in the pinctrl settings Signed-off-by: Roger Chen <roger.chen@rock-chips.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-31ARM: dts: imx6qdl: enable FEC magic-packet featureNimrod Andy
Add FEC magic-packet feature support. Signed-off-by: Fugang Duan <B38611@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-31ARM: imx: add FEC sleep mode callback functionNimrod Andy
i.MX6q/dl, i.MX6SX SOCs enet support sleep mode that magic packet can wake up system in suspend status. For different SOCs, there have some SOC specifical GPR register to set sleep on/off mode. So add these to callback function for driver. Signed-off-by: Fugang Duan <B38611@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-31Merge tag 'nios2-fixes-v3.19-rc3' of ↵Linus Torvalds
git://git.rocketboards.org/linux-socfpga-next Pull arch/nios2 fixes from Ley Foon Tan: - fix compilation error when enable CONFIG_PREEMPT - initialize cpuinfo.mmu variable supplied by the device tree * tag 'nios2-fixes-v3.19-rc3' of git://git.rocketboards.org/linux-socfpga-next: nios2: Use preempt_schedule_irq nios2: Initialize cpuinfo.mmu
2014-12-31nios2: Use preempt_schedule_irqTobias Klauser
Follow aa0d53260596 ("ia64: Use preempt_schedule_irq") and use preempt_schedule_irq instead of enabling/disabling interrupts and messing around with PREEMPT_ACTIVE in the nios2 low-level preemption code ourselves. Also get rid of the now needless re-check for TIF_NEED_RESCHED, preempt_schedule_irq will already take care of rescheduling. This also fixes the following build error when building with CONFIG_PREEMPT: arch/nios2/kernel/built-in.o: In function `need_resched': arch/nios2/kernel/entry.S:374: undefined reference to `PREEMPT_ACTIVE' Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Acked-by: Ley Foon Tan <lftan@altera.com>
2014-12-31nios2: Initialize cpuinfo.mmuWalter Goossens
This patch initializes the mmu field of the cpuinfo structure to the value supplied by the devicetree. Signed-off-by: Walter Goossens <waltergoossens@home.nl> Acked-by: Ley Foon Tan <lftan@altera.com>
2014-12-30Merge tag 'fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Arnd Bergmann: "A very small set of fixes for 3.19, as everyone was out. The clocksource patch was something I missed for the merge window after the change that broke arm64 was merged through arm-soc. The other two patches are a fix for an undetected merge problem in mvebu and a defconfig change to make some exynos boards work with the normal multi_v7_defconfig" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: Add USB_EHCI_EXYNOS to multi_v7_defconfig ARM: mvebu: Fix pinctrl configuration for Armada 370 DB clocksource: arch_timer: Only use the virtual counter (CNTVCT) on arm64
2014-12-30arm: sa1100: move irda header to linux/platform_dataDmitry Eremin-Solenikov
In the end asm/mach/irda.h header is not used by anybody except sa1100. Move the header to the platform data includes dir and rename it to irda-sa11x0.h. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-30Add USB_EHCI_EXYNOS to multi_v7_defconfigSteev Klimaszewski
Currently we enable Exynos devices in the multi v7 defconfig, however, when testing on my ODROID-U3, I noticed that USB was not working. Enabling this option causes USB to work, which enables networking support as well since the ODROID-U3 has networking on the USB bus. [arnd] Support for odroid-u3 was added in 3.10, so it would be nice to backport this fix at least that far. Signed-off-by: Steev Klimaszewski <steev@gentoo.org> Cc: stable@vger.kernel.org # 3.10 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-12-29Revert "powerpc: Secondary CPUs must set cpu_callin_map after setting active ↵Michael Ellerman
and online" This reverts commit 7c5c92ed56d932b2c19c3f8aea86369509407d33. Although this did fix the bug it was aimed at, it also broke secondary startup on platforms that use give/take_timebase(). Unfortunately we didn't detect that while it was in next. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-12-29powerpc/kdump: Ignore failure in enabling big endian exception during crashHari Bathini
In LE kernel, we currently have a hack for kexec that resets the exception endian before starting a new kernel as the kernel that is loaded could be a big endian or a little endian kernel. In kdump case, resetting exception endian fails when one or more cpus is disabled. But we can ignore the failure and still go ahead, as in most cases crashkernel will be of same endianess as primary kernel and reseting endianess is not even needed in those cases. This patch adds a new inline function to say if this is kdump path. This function is used at places where such a check is needed. Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> [mpe: Rename to kdump_in_progress(), use bool, and edit comment] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-12-29powerpc: Wire up sys_execveat() syscallPranith Kumar
Wire up sys_execveat(). This passes the selftests for the system call. Check success of execveat(3, '../execveat', 0)... [OK] Check success of execveat(5, 'execveat', 0)... [OK] Check success of execveat(6, 'execveat', 0)... [OK] Check success of execveat(-100, '/home/pranith/linux/...ftests/exec/execveat', 0)... [OK] Check success of execveat(99, '/home/pranith/linux/...ftests/exec/execveat', 0)... [OK] Check success of execveat(8, '', 4096)... [OK] Check success of execveat(17, '', 4096)... [OK] Check success of execveat(9, '', 4096)... [OK] Check success of execveat(14, '', 4096)... [OK] Check success of execveat(14, '', 4096)... [OK] Check success of execveat(15, '', 4096)... [OK] Check failure of execveat(8, '', 0) with ENOENT... [OK] Check failure of execveat(8, '(null)', 4096) with EFAULT... [OK] Check success of execveat(5, 'execveat.symlink', 0)... [OK] Check success of execveat(6, 'execveat.symlink', 0)... [OK] Check success of execveat(-100, '/home/pranith/linux/...xec/execveat.symlink', 0)... [OK] Check success of execveat(10, '', 4096)... [OK] Check success of execveat(10, '', 4352)... [OK] Check failure of execveat(5, 'execveat.symlink', 256) with ELOOP... [OK] Check failure of execveat(6, 'execveat.symlink', 256) with ELOOP... [OK] Check failure of execveat(-100, '/home/pranith/linux/tools/testing/selftests/exec/execveat.symlink', 256) with ELOOP... [OK] Check success of execveat(3, '../script', 0)... [OK] Check success of execveat(5, 'script', 0)... [OK] Check success of execveat(6, 'script', 0)... [OK] Check success of execveat(-100, '/home/pranith/linux/...elftests/exec/script', 0)... [OK] Check success of execveat(13, '', 4096)... [OK] Check success of execveat(13, '', 4352)... [OK] Check failure of execveat(18, '', 4096) with ENOENT... [OK] Check failure of execveat(7, 'script', 0) with ENOENT... [OK] Check success of execveat(16, '', 4096)... [OK] Check success of execveat(16, '', 4096)... [OK] Check success of execveat(4, '../script', 0)... [OK] Check success of execveat(4, 'script', 0)... [OK] Check success of execveat(4, '../script', 0)... [OK] Check failure of execveat(4, 'script', 0) with ENOENT... [OK] Check failure of execveat(5, 'execveat', 65535) with EINVAL... [OK] Check failure of execveat(5, 'no-such-file', 0) with ENOENT... [OK] Check failure of execveat(6, 'no-such-file', 0) with ENOENT... [OK] Check failure of execveat(-100, 'no-such-file', 0) with ENOENT... [OK] Check failure of execveat(5, '', 4096) with EACCES... [OK] Check failure of execveat(5, 'Makefile', 0) with EACCES... [OK] Check failure of execveat(11, '', 4096) with EACCES... [OK] Check failure of execveat(12, '', 4096) with EACCES... [OK] Check failure of execveat(99, '', 4096) with EBADF... [OK] Check failure of execveat(99, 'execveat', 0) with EBADF... [OK] Check failure of execveat(8, 'execveat', 0) with ENOTDIR... [OK] Invoke copy of 'execveat' via filename of length 4093: Check success of execveat(19, '', 4096)... [OK] Check success of execveat(5, 'xxxxxxxxxxxxxxxxxxxx...yyyyyyyyyyyyyyyyyyyy', 0)... [OK] Invoke copy of 'script' via filename of length 4093: Check success of execveat(20, '', 4096)... [OK] /bin/sh: 0: Can't open /dev/fd/5/xxxxxxx(... a long line of x's and y's, 0)... [OK] Check success of execveat(5, 'xxxxxxxxxxxxxxxxxxxx...yyyyyyyyyyyyyyyyyyyy', 0)... [OK] Tested on a 32-bit powerpc system. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2014-12-28Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull KVM fixes from Paolo Bonzini: "The important fixes are for two bugs introduced by the merge window. On top of this, add a couple of WARN_ONs and stop spamming dmesg on pretty much every boot of a virtual machine" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: warn on more invariant breakage kvm: fix sorting of memslots with base_gfn == 0 kvm: x86: drop severity of "generation wraparound" message kvm: x86: vmx: reorder some msr writing
2014-12-27kvm: x86: drop severity of "generation wraparound" messagePaolo Bonzini
Since most virtual machines raise this message once, it is a bit annoying. Make it KERN_DEBUG severity. Cc: stable@vger.kernel.org Fixes: 7a2e8aaf0f6873b47bc2347f216ea5b0e4c258ab Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-12-27kvm: x86: vmx: reorder some msr writingTiejun Chen
The commit 34a1cd60d17f, "x86: vmx: move some vmx setting from vmx_init() to hardware_setup()", tried to refactor some codes specific to vmx hardware setting into hardware_setup(), but some msr writing should depend on our previous setting condition like enable_apicv, enable_ept and so on. Reported-by: Jamie Heilman <jamie@audible.transient.net> Tested-by: Jamie Heilman <jamie@audible.transient.net> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2014-12-26Merge branch 'parisc-3.19-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc build fix from Helge Deller: "This unbreaks the kernel compilation on parisc with gcc-4.9" * 'parisc-3.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: fix out-of-register compiler error in ldcw inline assembler function
2014-12-26parisc: fix out-of-register compiler error in ldcw inline assembler functionJohn David Anglin
The __ldcw macro has a problem when its argument needs to be reloaded from memory. The output memory operand and the input register operand both need to be reloaded using a register in class R1_REGS when generating 64-bit code. This fails because there's only a single register in the class. Instead, use a memory clobber. This also makes the __ldcw macro a compiler memory barrier. Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: <stable@vger.kernel.org> [3.13+] Signed-off-by: Helge Deller <deller@gmx.de>
2014-12-23x86, vdso: Use asm volatile in __getcpuAndy Lutomirski
In Linux 3.18 and below, GCC hoists the lsl instructions in the pvclock code all the way to the beginning of __vdso_clock_gettime, slowing the non-paravirt case significantly. For unknown reasons, presumably related to the removal of a branch, the performance issue is gone as of e76b027e6408 x86,vdso: Use LSL unconditionally for vgetcpu but I don't trust GCC enough to expect the problem to stay fixed. There should be no correctness issue, because the __getcpu calls in __vdso_vlock_gettime were never necessary in the first place. Note to stable maintainers: In 3.18 and below, depending on configuration, gcc 4.9.2 generates code like this: 9c3: 44 0f 03 e8 lsl %ax,%r13d 9c7: 45 89 eb mov %r13d,%r11d 9ca: 0f 03 d8 lsl %ax,%ebx This patch won't apply as is to any released kernel, but I'll send a trivial backported version if needed. Fixes: 51c19b4f5927 x86: vdso: pvclock gettime support Cc: stable@vger.kernel.org # 3.8+ Cc: Marcelo Tosatti <mtosatti@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
2014-12-23arm64: mm: Add pgd_page to support RCU fast_gupJungseok Lee
This patch adds pgd_page definition in order to keep supporting HAVE_GENERIC_RCU_GUP configuration. In addition, it changes pud_page expression to align with pmd_page for readability. An introduction of pgd_page resolves the following build breakage under 4KB + 4Level memory management combo. mm/gup.c: In function 'gup_huge_pgd': mm/gup.c:889:2: error: implicit declaration of function 'pgd_page' [-Werror=implicit-function-declaration] head = pgd_page(orig); ^ mm/gup.c:889:7: warning: assignment makes pointer from integer without a cast head = pgd_page(orig); Cc: Will Deacon <will.deacon@arm.com> Cc: Steve Capper <steve.capper@linaro.org> Signed-off-by: Jungseok Lee <jungseoklee85@gmail.com> [catalin.marinas@arm.com: remove duplicate pmd_page definition] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2014-12-23arm64: defconfig: defconfig update for 3.19Will Deacon
The usual defconfig tweaks, this time: - FHANDLE and AUTOFS4_FS to keep systemd happy - PID_NS, QUOTA and KEYS to keep LTP happy - Disable DEBUG_PREEMPT, as this *really* hurts performance Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2014-12-23arm64: kernel: fix __cpu_suspend mm switch on warm-bootLorenzo Pieralisi
On arm64 the TTBR0_EL1 register is set to either the reserved TTBR0 page tables on boot or to the active_mm mappings belonging to user space processes, it must never be set to swapper_pg_dir page tables mappings. When a CPU is booted its active_mm is set to init_mm even though its TTBR0_EL1 points at the reserved TTBR0 page mappings. This implies that when __cpu_suspend is triggered the active_mm can point at init_mm even if the current TTBR0_EL1 register contains the reserved TTBR0_EL1 mappings. Therefore, the mm save and restore executed in __cpu_suspend might turn out to be erroneous in that, if the current->active_mm corresponds to init_mm, on resume from low power it ends up restoring in the TTBR0_EL1 the init_mm mappings that are global and can cause speculation of TLB entries which end up being propagated to user space. This patch fixes the issue by checking the active_mm pointer before restoring the TTBR0 mappings. If the current active_mm == &init_mm, the code sets the TTBR0_EL1 to the reserved TTBR0 mapping instead of switching back to the active_mm, which is the expected behaviour corresponding to the TTBR0_EL1 settings when __cpu_suspend was entered. Fixes: 95322526ef62 ("arm64: kernel: cpu_{suspend/resume} implementation") Cc: <stable@vger.kernel.org> # 3.14+: 18ab7db Cc: <stable@vger.kernel.org> # 3.14+: 714f599 Cc: <stable@vger.kernel.org> # 3.14+: c3684fb Cc: <stable@vger.kernel.org> # 3.14+ Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2014-12-23x86/build: Clean auto-generated processor feature filesBjørn Mork
Commit 9def39be4e96 ("x86: Support compiling out human-friendly processor feature names") made two source file targets conditional. Such conditional targets will not be cleaned automatically by make mrproper. Fix by adding explicit clean-files targets for the two files. Fixes: 9def39be4e96 ("x86: Support compiling out human-friendly processor feature names") Signed-off-by: Bjørn Mork <bjorn@mork.no> Cc: Josh Triplett <josh@joshtriplett.org> Link: http://lkml.kernel.org/r/1419335863-10608-1-git-send-email-bjorn@mork.no Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-12-23x86: Fix mkcapflags.sh bash-ismSylvain BERTRAND
Chocked while compiling linux with dash shell instead of bash shell. See: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html Signed-off-by: Sylvain BERTRAND <sylvain.bertrand@gmail.com> Link: http://lkml.kernel.org/r/20141223123912.GA1386@localhost.localdomain Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-12-23x86: Fix step size adjustment during initial memory mappingJan Beulich
The old scheme can lead to failure in certain cases - the problem is that after bumping step_size the next (non-final) iteration is only guaranteed to make available a memory block the size of what step_size was before. E.g. for a memory block [0,3004600000) we'd have: iter start end step amount 1 3004400000 30045fffff 2M 2M 2 3004000000 30043fffff 64M 4M 3 3000000000 3003ffffff 2G 64M 4 2000000000 2fffffffff 64G 64G Yet to map 64G with 4k pages (as happens e.g. under PV Xen) we need slightly over 128M, but the first three iterations made only about 70M available. The condition (new_mapped_ram_size > mapped_ram_size) for bumping step_size is just not suitable. Instead we want to bump it when we know we have enough memory available to cover a block of the new step_size. And rather than making that condition more complicated than needed, simply adjust step_size by the largest possible factor we know we can cover at that point - which is shifting it left by one less than the difference between page table level shifts. (Interestingly the original STEP_SIZE_SHIFT definition had a comment hinting at that having been the intention, just that it should have been PUD_SHIFT-PMD_SHIFT-1 instead of (PUD_SHIFT-PMD_SHIFT)/2, and of course for non-PAE 32-bit we can't really use these two constants as they're equal there.) Furthermore the comment in get_new_step_size() didn't get updated when the bottom-down mapping logic got added. Yet while an overflow (flushing step_size to zero) of the shift doesn't matter for the top-down method, it does for bottom-up because round_up(x, 0) = 0, and an upper range boundary of zero can't really work well. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/54945C1E020000780005114E@mail.emea.novell.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-12-23x86/xen: Remove unnecessary BUG_ON(preemptible()) in xen_setup_timer()Boris Ostrovsky
There is no reason for having it and, with commit 250a1ac685f1 ("x86, smpboot: Remove pointless preempt_disable() in native_smp_prepare_cpus()"), it prevents HVM guests from booting. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
2014-12-22arm64: Replace set_arch_dma_coherent_ops with arch_setup_dma_opsCatalin Marinas
Commit a3a60f81ee6f (dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops) changes the of_dma_configure() arch dma_ops callback to arch_setup_dma_ops but only the arch/arm code is updated. Subsequent commit 97890ba9289c (dma-mapping: detect and configure IOMMU in of_dma_configure) changes the arch_setup_dma_ops() prototype further to handle iommu. The patch makes the corresponding arm64 changes. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Will Deacon <will.deacon@arm.com>
2014-12-21ARM: mvebu: Fix pinctrl configuration for Armada 370 DBGregory CLEMENT
The commit b4607572ef86 (ARM: mvebu: remove conflicting muxing on Armada 370 DB) removes the hog pins muxing. As it is explained in the commit log it solves a warning a boot time, but more important it also allows using the Giga port 0 of the board. Unfortunately in the same time the commit 4904a82a9399 (arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsi) was merged and it introduced again the hog pins muxing. Because of it, the Giga port 0 of the board is no more usable. This commit remove again the conflicting muxing (hopefully for the last time). Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> [andrew@lunn.ch: Correct commit IDs] Signed-off-by: Andrew Lunn <andrew@lunn.ch> Fixes: 4904a82a9399 ("arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsi")
2014-12-21Merge tag 'pr-20141220-x86-vdso' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux into x86/urgent Pull a VDSO fix from Andy Lutomirski: "One vdso fix for a longstanding ASLR bug that's been in the news lately. The vdso base address has always been randomized, and I don't think there's anything particularly wrong with the range over which it's randomized, but the implementation seems to have been buggy since the very beginning. This fixes the implementation to remove a large bias that caused a small fraction of possible vdso load addresess to be vastly more likely than the rest of the possible addresses." Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-12-20x86_64, vdso: Fix the vdso address randomization algorithmAndy Lutomirski
The theory behind vdso randomization is that it's mapped at a random offset above the top of the stack. To avoid wasting a page of memory for an extra page table, the vdso isn't supposed to extend past the lowest PMD into which it can fit. Other than that, the address should be a uniformly distributed address that meets all of the alignment requirements. The current algorithm is buggy: the vdso has about a 50% probability of being at the very end of a PMD. The current algorithm also has a decent chance of failing outright due to incorrect handling of the case where the top of the stack is near the top of its PMD. This fixes the implementation. The paxtest estimate of vdso "randomisation" improves from 11 bits to 18 bits. (Disclaimer: I don't know what the paxtest code is actually calculating.) It's worth noting that this algorithm is inherently biased: the vdso is more likely to end up near the end of its PMD than near the beginning. Ideally we would either nix the PMD sharing requirement or jointly randomize the vdso and the stack to reduce the bias. In the mean time, this is a considerable improvement with basically no risk of compatibility issues, since the allowed outputs of the algorithm are unchanged. As an easy test, doing this: for i in `seq 10000` do grep -P vdso /proc/self/maps |cut -d- -f1 done |sort |uniq -d used to produce lots of output (1445 lines on my most recent run). A tiny subset looks like this: 7fffdfffe000 7fffe01fe000 7fffe05fe000 7fffe07fe000 7fffe09fe000 7fffe0bfe000 7fffe0dfe000 Note the suspicious fe000 endings. With the fix, I get a much more palatable 76 repeated addresses. Reviewed-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Andy Lutomirski <luto@amacapital.net>
2014-12-20Merge tag 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux Pull ACCESS_ONCE cleanup preparation from Christian Borntraeger: "kernel: Provide READ_ONCE and ASSIGN_ONCE As discussed on LKML http://marc.info/?i=54611D86.4040306%40de.ibm.com ACCESS_ONCE might fail with specific compilers for non-scalar accesses. Here is a set of patches to tackle that problem. The first patch introduce READ_ONCE and ASSIGN_ONCE. If the data structure is larger than the machine word size memcpy is used and a warning is emitted. The next patches fix up several in-tree users of ACCESS_ONCE on non-scalar types. This does not yet contain a patch that forces ACCESS_ONCE to work only on scalar types. This is targetted for the next merge window as Linux next already contains new offenders regarding ACCESS_ONCE vs. non-scalar types" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux: s390/kvm: REPLACE barrier fixup with READ_ONCE arm/spinlock: Replace ACCESS_ONCE with READ_ONCE arm64/spinlock: Replace ACCESS_ONCE READ_ONCE mips/gup: Replace ACCESS_ONCE with READ_ONCE x86/gup: Replace ACCESS_ONCE with READ_ONCE x86/spinlock: Replace ACCESS_ONCE with READ_ONCE mm: replace ACCESS_ONCE with READ_ONCE or barriers kernel: Provide READ_ONCE and ASSIGN_ONCE
2014-12-20Merge tag 'clk-for-linus-3.19' of ↵Linus Torvalds
git://git.linaro.org/people/mike.turquette/linux Pull clk framework updates from Mike Turquette: "This is much later than usual due to several last minute bugs that had to be addressed. As usual the majority of changes are new drivers and modifications to existing drivers. The core recieved many fixes along with the groundwork for several large changes coming in the future which will better parition clock providers from clock consumers" * tag 'clk-for-linus-3.19' of git://git.linaro.org/people/mike.turquette/linux: (86 commits) clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated ARM: OMAP3: clock: fix boot breakage in legacy mode ARM: OMAP2+: clock: fix DPLL code to use new determine rate APIs clk: Really fix deadlock with mmap_sem clk: mmp: fix sparse non static symbol warning clk: Change clk_ops->determine_rate to return a clk_hw as the best parent clk: change clk_debugfs_add_file to take a struct clk_hw clk: Don't expose __clk_get_accuracy clk: Don't try to use a struct clk* after it could have been freed clk: Remove unused function __clk_get_prepare_count clk: samsung: Fix double add of syscore ops after driver rebind clk: samsung: exynos4: set parent of sclk_hdmiphy to hdmi clk: samsung: exynos4415: Fix build with PM_SLEEP disabled clk: samsung: remove unnecessary inclusion of header files from clk.h clk: samsung: remove unnecessary CONFIG_OF from clk.c clk: samsung: Spelling s/bwtween/between/ clk: rockchip: Add support for the mmc clock phases using the framework clk: rockchip: add bindings for the mmc clocks clk: rockchip: rk3288 export i2s0_clkout for use in DT clk: rockchip: use clock ID for DMC (memory controller) on rk3288 ...
2014-12-20Merge tag 'pm-config-3.19-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull CONFIG_PM_RUNTIME elimination from Rafael Wysocki: "This removes the last few uses of CONFIG_PM_RUNTIME introduced recently and makes that config option finally go away. CONFIG_PM will be available directly from the menu now and also it will be selected automatically if CONFIG_SUSPEND or CONFIG_HIBERNATION is set" * tag 'pm-config-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: Eliminate CONFIG_PM_RUNTIME tty: 8250_omap: Replace CONFIG_PM_RUNTIME with CONFIG_PM sound: sst-haswell-pcm: Replace CONFIG_PM_RUNTIME with CONFIG_PM spi: Replace CONFIG_PM_RUNTIME with CONFIG_PM