- 22 Jul, 2015 7 commits
-
-
Hendrik Brueckner authored
Improve the save and restore behavior of FPU register contents to use the vector extension within the kernel. The kernel does not use floating-point or vector registers and, therefore, saving and restoring the FPU register contents are performed for handling signals or switching processes only. To prepare for using vector instructions and vector registers within the kernel, enhance the save behavior and implement a lazy restore at return to user space from a system call or interrupt. To implement the lazy restore, the save_fpu_regs() sets a CPU information flag, CIF_FPU, to indicate that the FPU registers must be restored. Saving and setting CIF_FPU is performed in an atomic fashion to be interrupt-safe. When the kernel wants to use the vector extension or wants to change the FPU register state for a task during signal handling, the save_fpu_regs() must be called first. The CIF_FPU flag is also set at process switch. At return to user space, the FPU state is restored. In particular, the FPU state includes the floating-point or vector register contents, as well as, vector-enablement and floating-point control. The FPU state restore and clearing CIF_FPU is also performed in an atomic fashion. For KVM, the restore of the FPU register state is performed when restoring the general-purpose guest registers before the SIE instructions is started. Because the path towards the SIE instruction is interruptible, the CIF_FPU flag must be checked again right before going into SIE. If set, the guest registers must be reloaded again by re-entering the outer SIE loop. This is the same behavior as if the SIE critical section is interrupted. Signed-off-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Hendrik Brueckner authored
Older binutils versions do not include support for the vector instruction formats. Add assembler macros for vector instruction mnemonics to easily encode and generate vector instructions. Signed-off-by:
-
Hendrik Brueckner authored
Make the floating-point save area dynamically allocated and uses a flag to distinguish whether a task uses floating-point or vector registers. Signed-off-by:
-
Hendrik Brueckner authored
Introduce a new structure to manage FP and VX registers. Refactor the save and restore of floating point and vector registers with a set of helper functions in fpu-internal.h. Signed-off-by:
-
Hendrik Brueckner authored
The kvm_arch_vcpu_load() does not validate whether the floating-point control (FPC) is valid. Further, the return code of the restore is not checked too. If the FPC is invalid, the restore fails and the host FPC value might remain. The correct behavior would be to clear the FPC if it is not valid. Hence, validate the FPC value and, optionally, reset the value before restoring it. Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
-
Hendrik Brueckner authored
Use the test_fp_ctl() to test the floating-point control word for validity and use restore_fp_ctl() to set it in load_sigregs. Signed-off-by:
-
Hendrik Brueckner authored
Move the EX_TABLE macro definitions from the processor.h to the linkage.h header file. It helps to reduce circular header file dependencies. Signed-off-by:
-
- 20 Jul, 2015 1 commit
-
-
Martin Schwidefsky authored
git commit 0c8c0f03 "x86/fpu, sched: Dynamically allocate 'struct fpu'" moved the thread_struct to the end of the task_struct. This causes some of the offsets used in entry.S to overflow their instruction operand field. To fix this use aghi to create a dedicated pointer for the thread_struct. Signed-off-by:
-
- 19 Jul, 2015 2 commits
-
-
Markos Chandras authored
Commit 6134d949 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6") added support for 64-bit FPU on a 32-bit MIPS R6 processor but it missed the 64-bit CPU case leading to FPU failures when requesting FR=1 mode (which is always the case for MIPS R6 userland) when running a 32-bit kernel on a 64-bit CPU. We also fix the MIPS R2 case. Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Fixes: 6134d949 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6") Reviewed-by:
Paul Burton <paul.burton@imgtec.com> Cc: <stable@vger.kernel.org> # 4.0+ Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10734/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Christophe Jaillet authored
Commit 0e0da48d ("parisc: mm: don't count preallocated pmds") introduced a memory leak. After this commit, the 'return' statement in pmd_free is executed in all cases. Even for pmd that are not attached to the pgd. So 'free_pages' can never be called anymore, leading to a memory leak. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by:
Mikulas Patocka <mpatocka@redhat.com> Acked-by:
Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v4.0+ Signed-off-by:
-
- 18 Jul, 2015 2 commits
-
-
Ingo Molnar authored
Don't burden architectures without dynamic task_struct sizing with the overhead of dynamic sizing. Also optimize the x86 code a bit by caching task_struct_size. Acked-and-Tested-by:
Dave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1437128892-9831-3-git-send-email-mingo@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Dave Hansen authored
The FPU rewrite removed the dynamic allocations of 'struct fpu'. But, this potentially wastes massive amounts of memory (2k per task on systems that do not have AVX-512 for instance). Instead of having a separate slab, this patch just appends the space that we need to the 'task_struct' which we dynamically allocate already. This saves from doing an extra slab allocation at fork(). The only real downside here is that we have to stick everything and the end of the task_struct. But, I think the BUILD_BUG_ON()s I stuck in there should keep that from being too fragile. Signed-off-by:
-
- 17 Jul, 2015 20 commits
-
-
Laurent Dufour authored
Commit 2ae416b1 ("mm: new mm hook framework") introduced an empty header file (mm-arch-hooks.h) for every architecture, even those which doesn't need to define mm hooks. As suggested by Geert Uytterhoeven, this could be cleaned through the use of a generic header file included via each per architecture asm/include/Kbuild file. The PowerPC architecture is not impacted here since this architecture has to defined the arch_remap MM hook. Signed-off-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Vineet Gupta <vgupta@synopsys.com> Cc: Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Viresh Kumar authored
Switch to my kernel.org alias instead of a badly named gmail address, which I rarely use. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Dominik Dingel authored
On s390 we only can enable hugepages if the underlying hardware/hypervisor also does support this. Common code now would assume this to be signaled by setting HPAGE_SHIFT to 0. But on s390, where we only support one hugepage size, there is a link between HPAGE_SHIFT and pageblock_order. So instead of setting HPAGE_SHIFT to 0, we will implement the check for the hardware capability. Signed-off-by:
Dominik Dingel <dingel@linux.vnet.ibm.com> Acked-by:
-
Dominik Dingel authored
Heiko noticed that the current check for hugepage support on s390 is a little bit too harsh as systems which do not support will crash. The reason is that pageblock_order can now get negative when we set HPAGE_SHIFT to 0. To avoid all this and to avoid opening another can of worms with enabling HUGETLB_PAGE_SIZE_VARIABLE I think it would be best to simply allow architectures to define their own hugepages_supported(). Revert bea41197 ("s390/mm: make hugepages_supported a boot time decision") in preparation. Signed-off-by:
-
Dominik Dingel authored
Heiko noticed that the current check for hugepage support on s390 is a little bit too harsh as systems which do not support will crash. The reason is that pageblock_order can now get negative when we set HPAGE_SHIFT to 0. To avoid all this and to avoid opening another can of worms with enabling HUGETLB_PAGE_SIZE_VARIABLE I think it would be best to simply allow architectures to define their own hugepages_supported(). This patch (of 4): revert commit cf54e2fc ("s390/mm: change HPAGE_SHIFT type to int") in preparation. Signed-off-by:
-
Andrew Morton authored
openrisc-allnoconfig: kernel/uid16.c: In function 'SYSC_setgroups16': kernel/uid16.c:184:2: error: implicit declaration of function 'groups_alloc' kernel/uid16.c:184:13: warning: assignment makes pointer from integer without a cast openrisc shouldn't be setting CONFIG_UID16 when CONFIG_MULTIUSER=n. Fixes: 2813893f ("kernel: conditionally support non-root users, groups and capabilities") Reported-by:
Fengguang Wu <fengguang.wu@gmail.com> Cc: Iulia Manda <iulia.manda21@gmail.com> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by:
-
Russell King authored
Fengguang Wu reports that building ARM with !MMU results in the following build error: arch/arm/kernel/built-in.o: In function `__soft_restart': >> :(.text+0x1624): undefined reference to `arch_virt_to_idmap' Fix this by adding an appropriate IS_ENABLED(CONFIG_MMU) into the __virt_to_idmap() inline function. Signed-off-by:Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
We must invalidate the L1 cache before enabling coherency, otherwise secondary CPUs can inject invalid cache lines into the coherent CPU cluster, which could then be migrated to other CPUs. This fixes a recent regression with SoCFPGA randomly failing to boot. Fixes: 02b4e275 ("ARM: v7 setup function should invalidate L1 cache") Signed-off-by:
-
Marek Szyprowski authored
nr_bitmaps member of mapping structure stores the number of already allocated bitmaps and it is interpreted as loop iterator (it starts from 0 not from 1), so a comparison against number of possible bitmap extensions should include this fact. This patch fixes this by changing the extension failure condition. This issue has been introduced by commit 4d852ef8 ("arm: dma-mapping: Add support to extend DMA IOMMU mappings"). Reported-by:
Hyungwon Hwang <human.hwang@samsung.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
-
Stephen Boyd authored
It's possible, albeit unlikely, that using the of_node here will reference freed memory. Call of_node_put() after printing the name to be safe. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Vitaly Andrianov authored
This patch is to get correct physical address of the reset function for PAE systems, which use aliased physical memory for booting. See the "ARM: mm: Introduce virt_to_idmap() with an arch hook" for details. Signed-off-by:
Vitaly Andrianov <vitalya@ti.com> Signed-off-by:
-
Andy Lutomirski authored
It turns out to be rather tedious to test the NMI nesting code. Make it easier: add a new CONFIG_DEBUG_ENTRY option that causes the NMI handler to pre-emptively unmask NMIs. With this option set, errors in the repeat_nmi logic or failures to detect that we're in a nested NMI will result in quick panics under perf (especially if multiple counters are running at high frequency) instead of requiring an unusual workload that generates page faults or breakpoints inside NMIs. I called it CONFIG_DEBUG_ENTRY instead of CONFIG_DEBUG_NMI_ENTRY because I want to add new non-NMI checks elsewhere in the entry code in the future, and I'd rather not add too many new config options or add this option and then immediately rename it. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Reviewed-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Andy Lutomirski authored
Currently, "NMI executing" is one the first time an outermost NMI hits repeat_nmi and zero thereafter. Change it to be zero each time for consistency. This is intended to help NMI handling fail harder if it's buggy. Signed-off-by:
-
Andy Lutomirski authored
Replace LEA; MOV with an equivalent SUB. This saves one instruction. Signed-off-by:
-
Andy Lutomirski authored
We have a tricky bug in the nested NMI code: if we see RSP pointing to the NMI stack on NMI entry from kernel mode, we assume that we are executing a nested NMI. This isn't quite true. A malicious userspace program can point RSP at the NMI stack, issue SYSCALL, and arrange for an NMI to happen while RSP is still pointing at the NMI stack. Fix it with a sneaky trick. Set DF in the region of code that the RSP check is intended to detect. IRET will clear DF atomically. ( Note: other than paravirt, there's little need for all this complexity. We could check RIP instead of RSP. ) Signed-off-by:
-
Andy Lutomirski authored
Check the repeat_nmi .. end_repeat_nmi special case first. The next patch will rework the RSP check and, as a side effect, the RSP check will no longer detect repeat_nmi .. end_repeat_nmi, so we'll need this ordering of the checks. Note: this is more subtle than it appears. The check for repeat_nmi .. end_repeat_nmi jumps straight out of the NMI code instead of adjusting the "iret" frame to force a repeat. This is necessary, because the code between repeat_nmi and end_repeat_nmi sets "NMI executing" and then writes to the "iret" frame itself. If a nested NMI comes in and modifies the "iret" frame while repeat_nmi is also modifying it, we'll end up with garbage. The old code got this right, as does the new code, but the new code is a bit more explicit. If we were to move the check right after the "NMI executing" check, then we'd get it wrong and have random crashes. ( Because the "NMI executing" check would jump to the code that would modify the "iret" frame without checking if the interrupted NMI was currently modifying it. ) Signed-off-by:
-
Andy Lutomirski authored
I found the nested NMI documentation to be difficult to follow. Improve the comments. Signed-off-by:
-
Andy Lutomirski authored
Returning to userspace is tricky: IRET can fail, and ESPFIX can rearrange the stack prior to IRET. The NMI nesting fixup relies on a precise stack layout and atomic IRET. Rather than trying to teach the NMI nesting fixup to handle ESPFIX and failed IRET, punt: run NMIs that came from user mode on the normal kernel stack. This will make some nested NMIs visible to C code, but the C code is okay with that. As a side effect, this should speed up perf: it eliminates an RDMSR when NMIs come from user mode. Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Signed-off-by:
-
Andy Lutomirski authored
Now that do_nmi saves CR2, we don't need to save it in asm. Signed-off-by:
-
Andy Lutomirski authored
32-bit kernels handle nested NMIs in C. Enable the exact same handling on 64-bit kernels as well. This isn't currently necessary, but it will become necessary once the asm code starts allowing limited nesting. Signed-off-by:
-
- 16 Jul, 2015 3 commits
-
-
Murali Karicheri authored
Now that PCIe DT binding is disabled in SoC specific DTS, we need a way to override it in a board specific DTS. So rename the PCIe nodes accordingly. Signed-off-by:
Murali Karicheri <m-karicheri2@ti.com> Signed-off-by:
Santosh Shilimkar <ssantosh@kernel.org>
-
Murali Karicheri authored
Currently PCIe DT bindings are broken. PCIe driver can't function without having a SerDes driver that provide the phy configuration. On K2E EVM, this causes problem since the EVM has Marvell SATA controller present and with default values in the SerDes register, it seems to pass the PCIe link check, but causes issues since the configuration is not correct. The manifestation is that when EVM is booted with NFS rootfs, the boot hangs. We shouldn't enable PCIe on this EVM since to work, SerDes driver has to be present as well. So by default, the PCIe DT binding should be disabled in SoC specific DTS. It can be enabled in the board specific DTS when the SerDes device driver is also present. So fix the status of PCIe DT bindings in the SoC specific DTS to "disabled". To enable PCIe, the status should be set to "ok" in the EVM DTS file when SerDes driver support becomes available in the upstream tree. Signed-off-by:
-
Robert Jarzmik authored
Since dm9000 driver added support for a vcc regulator, platform data based platforms have their ethernet broken, as the regulator claiming returns -EPROBE_DEFER and prevents dm9000 loading. This patch fixes this for all pxa boards using dm9000, by using the specific regulator_has_full_constraints() function. This was discovered and tested on the cm-x300 board. Fixes: 7994fe55 ("dm9000: Add regulator and reset support to dm9000") Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Acked-by:
Igor Grinberg <grinberg@compulab.co.il>
-
- 15 Jul, 2015 3 commits
-
-
Adam YH Lee authored
Audio-in was incorrectly routed to Line In. It should be Mic3L as per schematic. Using mic-bias voltage at 2.0v (<0x1>) does not work for some reason. There is no voltage seen on micbias (R127). Mic-bias voltage of 2.5v (<0x2>) works. I see voltage of 2.475v across GND and micbias. With these changes, I can record audio with a pair of proliferate TRRS earbuds. Signed-off-by:
Adam YH Lee <adam.yh.lee@gmail.com> Acked-by:
Ash Charles <ashcharles@gmail.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Dave Gerlach authored
CONFIG_HAVE_ARM_SCU only gets selected if CONFIG_SMP is selected in an OMAP system, however AM43XX needs this option regardless of CONFIG_SMP and also for an AM43XX only build as it is important for controlling power in the SoC. Without this we cannot suspend the CPU for SoC suspend or cpuidle. The ARM Cortex A9 needs SCU CPU Power Status bits to be set to off mode in order for the PRCM to transition the MPU to low power modes. Signed-off-by:
Dave Gerlach <d-gerlach@ti.com> Signed-off-by:
-
Thomas Gleixner authored
Boris reported that the sparse_irq protection around __cpu_up() in the generic code causes a regression on Xen. Xen allocates interrupts and some more in the xen_cpu_up() function, so it deadlocks on the sparse_irq_lock. There is no simple fix for this and we really should have the protection for all architectures, but for now the only solution is to move it to x86 where actual wreckage due to the lack of protection has been observed. Reported-and-tested-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Fixes: a8994181 'hotplug: Prevent alloc/free of irq descriptors during cpu up/down' Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: xiao jin <jin.xiao@intel.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Borislav Petkov <bp@suse.de> Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com> Cc: xen-devel <xen-devel@lists.xenproject.org>
-
- 14 Jul, 2015 2 commits
-
-
Ralf Baechle authored
Pass 1 parts had a number of significant erratas and were only available in small numbers and under NDA. Full support also required the use of a special toolchain that kept branches properly aligned. These workarounds were never upstreamed and the only toolchain known to have them is Montavista's GCC 3.0-based toolchain which completly obsoleted if not useless these days. So now that automated testing has tripped over the user of the -msb1-pass1-workarounds option, rather than fixing it remove support for pass 1 parts. Probably nobody will notice. I seem to own the last know pass 1 board and I haven't noticed another one in the wild in the past decade, at least. Signed-off-by: -
Paul Burton authored
MIPS32r6 code requires FP64 (ie. FR=1) support. Building a kernel with support for MIPS32r6 binaries but without support for O32 with FP64 is therefore a problem which can lead to incorrectly executed userland. CONFIG_MIPS_O32_FP64_SUPPORT is already selected when the kernel is configured for MIPS32r6, but not when the kernel is configured for MIPS64r6 with O32 compat support. Select CONFIG_MIPS_O32_FP64_SUPPORT in such configurations to prevent building kernels which execute MIPS32r6 userland incorrectly. Signed-off-by:
-
