- 18 2月, 2015 1 次提交
-
-
由 Jiang Liu 提交于
Commit b568b860 ("Treat SCI interrupt as normal GSI interrupt") accidently removes support of legacy PIC interrupt when fixing a regression for Xen, which causes a nasty regression on HP/Compaq nc6000 where we fail to register the ACPI interrupt, and thus lose eg. thermal notifications leading a potentially overheated machine. So reintroduce support of legacy PIC based ACPI SCI interrupt. Reported-by: NVille Syrjälä <syrjala@sci.fi> Tested-by: NVille Syrjälä <syrjala@sci.fi> Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Acked-by: NPavel Machek <pavel@ucw.cz> Cc: <stable@vger.kernel.org> # 3.19+ Cc: H. Peter Anvin <hpa@zytor.com> Cc: Len Brown <len.brown@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Sander Eikelenboom <linux@eikelenboom.it> Cc: linux-pm@vger.kernel.org Link: http://lkml.kernel.org/r/1424052673-22974-1-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 09 2月, 2015 1 次提交
-
-
由 Chung-Ling Tang 提交于
Follow other architectures for user fault handling. Signed-off-by: NChung-Ling Tang <cltang@codesourcery.com> Acked-by: NLey Foon Tan <lftan@altera.com>
-
- 06 2月, 2015 2 次提交
-
-
由 Joonsoo Kim 提交于
Kim Phillips reported following build failure. LD init/built-in.o mm/built-in.o: In function `free_pages_prepare': mm/page_alloc.c:770: undefined reference to `.kernel_map_pages' mm/built-in.o: In function `prep_new_page': mm/page_alloc.c:933: undefined reference to `.kernel_map_pages' mm/built-in.o: In function `map_pages': mm/compaction.c:61: undefined reference to `.kernel_map_pages' make: *** [vmlinux] Error 1 Reason for this problem is that commit 031bc574 ("mm/debug-pagealloc: make debug-pagealloc boottime configurable") forgot to remove the old declaration of kernel_map_pages() for some architectures. This patch removes them to fix build failure. Reported-by: NKim Phillips <kim.phillips@freescale.com> Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: David Miller <davem@davemloft.net> Cc: David Howells <dhowells@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Sylwester Nawrocki 提交于
I2S1, I2S2 on Exynos4 SoC series have limited functionality compared to I2S0, "samsung,s3c6410-i2s" compatible should be used for them. Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
- 04 2月, 2015 3 次提交
-
-
由 Lars Persson 提交于
Register 2 is alredy overwritten by the return value when syscall_trace_leave() is called. Signed-off-by: NLars Persson <larper@axis.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9187/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
These are generated by very recent toolchains and result in an error message when attenpting to convert a kernel from ELF to ECOFF. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
The if construct was getting hard to read and would be getting even more complex with the next bug fix. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 03 2月, 2015 1 次提交
-
-
由 Will Deacon 提交于
Commit e1a5848e ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE") removed the use of the reserved TTBR0 value for LPAE systems, since the ASID is held in the TTBR and can be updated atomicly with the pgd of the next mm. Unfortunately, this patch forgot to update flush_context, which deliberately avoids marking the local active ASID as allocated, since we used to switch via ASID zero and didn't need to allocate the ASID of the previous mm. The side-effect of this is that we can allocate the same ASID to the next mm and, between flushing the local TLB and updating TTBR0, we can perform speculative TLB fills for userspace nG mappings using the page table of the previous mm. The consequence of this is that the next mm can erroneously hit some mappings of the previous mm. Note that this was made significantly harder to hit by a391263c ("ARM: 8203/1: mm: try to re-use old ASID assignments following a rollover") but is still theoretically possible. This patch fixes the problem by removing the code from flush_context that forces the allocated ASID to zero for the local CPU. Many thanks to the Broadcom guys for tracking this one down. Fixes: e1a5848e ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE") Cc: <stable@vger.kernel.org> # v3.14+ Reported-by: NRaymond Ngun <rngun@broadcom.com> Tested-by: NRaymond Ngun <rngun@broadcom.com> Reviewed-by: NGregory Fong <gregory.0xf0@gmail.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 02 2月, 2015 1 次提交
-
-
由 Charlotte Richardson 提交于
NEC OEMs the same platforms as Stratus does, which have multiple devices on some PCIe buses under downstream ports. Link: https://bugzilla.kernel.org/show_bug.cgi?id=51331 Fixes: 1278998f ("PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)") Signed-off-by: NCharlotte Richardson <charlotte.richardson@stratus.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.5+ CC: Myron Stowe <myron.stowe@redhat.com>
-
- 01 2月, 2015 3 次提交
-
-
由 Andy Lutomirski 提交于
We used to optimize rescheduling and audit on syscall exit. Now that the full slow path is reasonably fast, remove these optimizations. Syscall exit auditing is now handled exclusively by syscall_trace_leave. This adds something like 10ns to the previously optimized paths on my computer, presumably due mostly to SAVE_REST / RESTORE_REST. I think that we should eventually replace both the syscall and non-paranoid interrupt exit slow paths with a pair of C functions along the lines of the syscall entry hooks. Link: http://lkml.kernel.org/r/22f2aa4a0361707a5cfb1de9d45260b39965dead.1421453410.git.luto@amacapital.netAcked-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Andy Lutomirski 提交于
The x86_64 entry code currently jumps through complex and inconsistent hoops to try to minimize the impact of syscall exit work. For a true fast-path syscall, almost nothing needs to be done, so returning is just a check for exit work and sysret. For a full slow-path return from a syscall, the C exit hook is invoked if needed and we join the iret path. Using iret to return to userspace is very slow, so the entry code has accumulated various special cases to try to do certain forms of exit work without invoking iret. This is error-prone, since it duplicates assembly code paths, and it's dangerous, since sysret can malfunction in interesting ways if used carelessly. It's also inefficient, since a lot of useful cases aren't optimized and therefore force an iret out of a combination of paranoia and the fact that no one has bothered to write even more asm code to avoid it. I would argue that this approach is backwards. Rather than trying to avoid the iret path, we should instead try to make the iret path fast. Under a specific set of conditions, iret is unnecessary. In particular, if RIP==RCX, RFLAGS==R11, RIP is canonical, RF is not set, and both SS and CS are as expected, then movq 32(%rsp),%rsp;sysret does the same thing as iret. This set of conditions is nearly always satisfied on return from syscalls, and it can even occasionally be satisfied on return from an irq. Even with the careful checks for sysret applicability, this cuts nearly 80ns off of the overhead from syscalls with unoptimized exit work. This includes tracing and context tracking, and any return that invokes KVM's user return notifier. For example, the cost of getpid with CONFIG_CONTEXT_TRACKING_FORCE=y drops from ~360ns to ~280ns on my computer. This may allow the removal and even eventual conversion to C of a respectable amount of exit asm. This may require further tweaking to give the full benefit on Xen. It may be worthwhile to adjust signal delivery and exec to try hit the sysret path. This does not optimize returns to 32-bit userspace. Making the same optimization for CS == __USER32_CS is conceptually straightforward, but it will require some tedious code to handle the differences between sysretl and sysexitl. Link: http://lkml.kernel.org/r/71428f63e681e1b4aa1a781e3ef7c27f027d1103.1421453410.git.luto@amacapital.netSigned-off-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Andy Lutomirski 提交于
context_tracking_user_exit() has no effect if in_interrupt() returns true, so ist_enter() didn't work. Fix it by calling exception_enter(), and thus context_tracking_user_exit(), before incrementing the preempt count. This also adds an assertion that will catch the problem reliably if CONFIG_PROVE_RCU=y to help prevent the bug from being reintroduced. Link: http://lkml.kernel.org/r/261ebee6aee55a4724746d0d7024697013c40a08.1422709102.git.luto@amacapital.net Fixes: 95927475 x86, traps: Track entry into and exit from IST context Reported-and-tested-by: NSasha Levin <sasha.levin@oracle.com> Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
-
- 31 1月, 2015 5 次提交
-
-
由 James Hogan 提交于
There is a race in the MIPS fork code which allows the child to get a stale copy of parent MSA/FPU/DSP state that is active in hardware registers when the fork() is called. This is because copy_thread() saves the live register state into the child context only if the hardware is currently in use, apparently on the assumption that the hardware state cannot have been saved and disabled since the initial duplication of the task_struct. However preemption is certainly possible during this window. An example sequence of events is as follows: 1) The parent userland process puts important data into saved floating point registers ($f20-$f31), which are then dirty compared to the process' stored context. 2) The parent process calls fork() which does a clone system call. 3) In the kernel, do_fork() -> copy_process() -> dup_task_struct() -> arch_dup_task_struct() (which uses the weakly defined default implementation). This duplicates the parent process' task context, which includes a stale version of its FP context from when it was last saved, probably some time before (1). 4) At some point before copy_process() calls copy_thread(), such as when duplicating the memory map, the process is desceduled. Perhaps it is preempted asynchronously, or perhaps it sleeps while blocked on a mutex. The dirty FP state in the FP registers is saved to the parent process' context and the FPU is disabled. 5) When the process is rescheduled again it continues copying state until it gets to copy_thread(), which checks whether the FPU is in use, so that it can copy that dirty state to the child process' task context. Because of the deschedule however the FPU is not in use, so the child process' context is left with stale FP context from the last time the parent saved it (some time before (1)). 6) When the new child process is scheduled it reads the important data from the saved floating point register, and ends up doing a NULL pointer dereference as a result of the stale data. This use of saved floating point registers across function calls can be triggered fairly easily by explicitly using inline asm with a current (MIPS R2) compiler, but is far more likely to happen unintentionally with a MIPS R6 compiler where the FP registers are more likely to get used as scratch registers for storing non-fp data. It is easily fixed, in the same way that other architectures do it, by overriding the implementation of arch_dup_task_struct() to sync the dirty hardware state to the parent process' task context *prior* to duplicating it, rather than copying straight to the child process' task context in copy_thread(). Note, the FPU hardware is not disabled so the parent process may continue executing with the live register context, but now the child process is guaranteed to have an identical copy of it at that point. Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Reported-by: NMatthew Fortune <matthew.fortune@imgtec.com> Tested-by: NMarkos Chandras <markos.chandras@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9075/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 David Daney 提交于
The following commits: 5890f70f (MIPS: Use dedicated exception handler if CPU supports RI/XI exceptions) 6575b1d4 (MIPS: kernel: cpu-probe: Detect unique RI/XI exceptions) break the kernel for *all* existing MIPS CPUs that implement the CP0_PageGrain[IEC] bit. They cause the TLB exception handlers to be generated without the legacy execute-inhibit handling, but never set the CP0_PageGrain[IEC] bit to activate the use of dedicated exception vectors for execute-inhibit exceptions. The result is that upon detection of an execute-inhibit violation, we loop forever in the TLB exception handlers instead of sending SIGSEGV to the task. If we are generating TLB exception handlers expecting separate vectors, we must also enable the CP0_PageGrain[IEC] feature. The bug was introduced in kernel version 3.17. Signed-off-by: NDavid Daney <david.daney@cavium.com> Cc: <stable@vger.kernel.org> Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/8880/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 James Hogan 提交于
Commit 842dfc11 ("MIPS: Fix build with binutils 2.24.51+") in v3.18 enabled -msoft-float and sprinkled ".set hardfloat" where necessary to use FP instructions. However it missed enable_restore_fp_context() which since v3.17 does a ctc1 with inline assembly, causing the following assembler errors on Mentor's 2014.05 toolchain: {standard input}: Assembler messages: {standard input}:2913: Error: opcode not supported on this processor: mips32r2 (mips32r2) `ctc1 $2,$31' scripts/Makefile.build:257: recipe for target 'arch/mips/kernel/traps.o' failed Fix that to use the new write_32bit_cp1_register() macro so that ".set hardfloat" is automatically added when -msoft-float is in use. Fixes 842dfc11 ("MIPS: Fix build with binutils 2.24.51+") Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.18+, depends on "MIPS: mipsregs.h: Add write_32bit_cp1_register()" Patchwork: https://patchwork.linux-mips.org/patch/9173/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 James Hogan 提交于
Add a write_32bit_cp1_register() macro to compliment the read_32bit_cp1_register() macro. This is to abstract whether .set hardfloat needs to be used based on GAS_HAS_SET_HARDFLOAT. The implementation of _read_32bit_cp1_register() .sets mips1 due to failure of gas v2.19 to assemble cfc1 for Octeon (see commit 25c30003 ("MIPS: Override assembler target architecture for octeon.")). I haven't copied this over to _write_32bit_cp1_register() as I'm uncertain whether it applies to ctc1 too, or whether anybody cares about that version of binutils any longer. Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9172/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Guenter Roeck 提交于
Fix misspelled define. Fixes: 33692f27 ("vm: add VM_FAULT_SIGSEGV handling support") Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 30 1月, 2015 8 次提交
-
-
由 Radim Krčmář 提交于
We forgot to re-check LAPIC after splitting the loop in commit 173beedc (KVM: x86: Software disabled APIC should still deliver NMIs, 2014-11-02). Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com> Fixes: 173beedcSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Hemmo Nieminen 提交于
As printk() invocation can cause e.g. a TLB miss, printk() cannot be called before the exception handlers have been properly initialized. This can happen e.g. when netconsole has been loaded as a kernel module and the TLB table has been cleared when a CPU was offline. Call cpu_report() in start_secondary() only after the exception handlers have been initialized to fix this. Without the patch the kernel will randomly either lockup or crash after a CPU is onlined and the console driver is a module. Signed-off-by: NHemmo Nieminen <hemmo.nieminen@iki.fi> Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi> Cc: stable@vger.kernel.org Cc: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/8953/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Aaro Koskinen 提交于
octeon_cpu_disable() will unconditionally enable interrupts when called. We can assume that the routine is always called with interrupts disabled, so just delete the incorrect local_irq_disable/enable(). The patch fixes the following crash when offlining a CPU: [ 93.818785] ------------[ cut here ]------------ [ 93.823421] WARNING: CPU: 1 PID: 10 at kernel/smp.c:231 flush_smp_call_function_queue+0x1c4/0x1d0() [ 93.836215] Modules linked in: [ 93.839287] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.19.0-rc4-octeon-los_b5f0 #1 [ 93.847212] Stack : 0000000000000001 ffffffff81b2cf90 0000000000000004 ffffffff81630000 0000000000000000 0000000000000000 0000000000000000 000000000000004a 0000000000000006 ffffffff8117e550 0000000000000000 0000000000000000 ffffffff81b30000 ffffffff81b26808 8000000032c77748 ffffffff81627e07 ffffffff81595ec8 ffffffff81b26808 000000000000000a 0000000000000001 0000000000000001 0000000000000003 0000000010008ce1 ffffffff815030c8 8000000032cbbb38 ffffffff8113d42c 0000000010008ce1 ffffffff8117f36c 8000000032c77300 8000000032cbba50 0000000000000001 ffffffff81503984 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ffffffff81121668 0000000000000000 0000000000000000 ... [ 93.912819] Call Trace: [ 93.915273] [<ffffffff81121668>] show_stack+0x68/0x80 [ 93.920335] [<ffffffff81503984>] dump_stack+0x6c/0x90 [ 93.925395] [<ffffffff8113d58c>] warn_slowpath_common+0x94/0xd8 [ 93.931324] [<ffffffff811a402c>] flush_smp_call_function_queue+0x1c4/0x1d0 [ 93.938208] [<ffffffff811a4128>] hotplug_cfd+0xf0/0x108 [ 93.943444] [<ffffffff8115bacc>] notifier_call_chain+0x5c/0xb8 [ 93.949286] [<ffffffff8113d704>] cpu_notify+0x24/0x60 [ 93.954348] [<ffffffff81501738>] take_cpu_down+0x38/0x58 [ 93.959670] [<ffffffff811b343c>] multi_cpu_stop+0x154/0x180 [ 93.965250] [<ffffffff811b3768>] cpu_stopper_thread+0xd8/0x160 [ 93.971093] [<ffffffff8115ea4c>] smpboot_thread_fn+0x1ec/0x1f8 [ 93.976936] [<ffffffff8115ab04>] kthread+0xd4/0xf0 [ 93.981735] [<ffffffff8111c4f0>] ret_from_kernel_thread+0x14/0x1c [ 93.987835] [ 93.989326] ---[ end trace c9e3815ee655bda9 ]--- [ 93.993951] Kernel bug detected[#1]: [ 93.997533] CPU: 1 PID: 10 Comm: migration/1 Tainted: G W 3.19.0-rc4-octeon-los_b5f0 #1 [ 94.006591] task: 8000000032c77300 ti: 8000000032cb8000 task.ti: 8000000032cb8000 [ 94.014081] $ 0 : 0000000000000000 0000000010000ce1 0000000000000001 ffffffff81620000 [ 94.022146] $ 4 : 8000000002c72ac0 0000000000000000 00000000000001a7 ffffffff813b06f0 [ 94.030210] $ 8 : ffffffff813b20d8 0000000000000000 0000000000000000 ffffffff81630000 [ 94.038275] $12 : 0000000000000087 0000000000000000 0000000000000086 0000000000000000 [ 94.046339] $16 : ffffffff81623168 0000000000000001 0000000000000000 0000000000000008 [ 94.054405] $20 : 0000000000000001 0000000000000001 0000000000000001 0000000000000003 [ 94.062470] $24 : 0000000000000038 ffffffff813b7f10 [ 94.070536] $28 : 8000000032cb8000 8000000032cbbc20 0000000010008ce1 ffffffff811bcaf4 [ 94.078601] Hi : 0000000000f188e8 [ 94.082179] Lo : d4fdf3b646c09d55 [ 94.085760] epc : ffffffff811bc9d0 irq_work_run_list+0x8/0xf8 [ 94.091686] Tainted: G W [ 94.095613] ra : ffffffff811bcaf4 irq_work_run+0x34/0x60 [ 94.101192] Status: 10000ce3 KX SX UX KERNEL EXL IE [ 94.106235] Cause : 40808034 [ 94.109119] PrId : 000d9301 (Cavium Octeon II) [ 94.113653] Modules linked in: [ 94.116721] Process migration/1 (pid: 10, threadinfo=8000000032cb8000, task=8000000032c77300, tls=0000000000000000) [ 94.127168] Stack : 8000000002c74c80 ffffffff811a4128 0000000000000001 ffffffff81635720 fffffffffffffff2 ffffffff8115bacc 80000000320fbce0 80000000320fbca4 80000000320fbc80 0000000000000002 0000000000000004 ffffffff8113d704 80000000320fbce0 ffffffff81501738 0000000000000003 ffffffff811b343c 8000000002c72aa0 8000000002c72aa8 ffffffff8159cae8 ffffffff8159caa0 ffffffff81650000 80000000320fbbf0 80000000320fbc80 ffffffff811b32e8 0000000000000000 ffffffff811b3768 ffffffff81622b80 ffffffff815148a8 8000000032c77300 8000000002c73e80 ffffffff815148a8 8000000032c77300 ffffffff81622b80 ffffffff815148a8 8000000032c77300 ffffffff81503f48 ffffffff8115ea0c ffffffff81620000 0000000000000000 ffffffff81174d64 ... [ 94.192771] Call Trace: [ 94.195222] [<ffffffff811bc9d0>] irq_work_run_list+0x8/0xf8 [ 94.200802] [<ffffffff811bcaf4>] irq_work_run+0x34/0x60 [ 94.206036] [<ffffffff811a4128>] hotplug_cfd+0xf0/0x108 [ 94.211269] [<ffffffff8115bacc>] notifier_call_chain+0x5c/0xb8 [ 94.217111] [<ffffffff8113d704>] cpu_notify+0x24/0x60 [ 94.222171] [<ffffffff81501738>] take_cpu_down+0x38/0x58 [ 94.227491] [<ffffffff811b343c>] multi_cpu_stop+0x154/0x180 [ 94.233072] [<ffffffff811b3768>] cpu_stopper_thread+0xd8/0x160 [ 94.238914] [<ffffffff8115ea4c>] smpboot_thread_fn+0x1ec/0x1f8 [ 94.244757] [<ffffffff8115ab04>] kthread+0xd4/0xf0 [ 94.249555] [<ffffffff8111c4f0>] ret_from_kernel_thread+0x14/0x1c [ 94.255654] [ 94.257146] Code: a2423c40 40026000 30420001 <00020336> dc820000 10400037 00000000 0000010f 0000010f [ 94.267183] ---[ end trace c9e3815ee655bdaa ]--- [ 94.271804] Fatal exception: panic in 5 seconds Reported-by: NHemmo Nieminen <hemmo.nieminen@iki.fi> Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi> Acked-by: NDavid Daney <david.daney@cavium.com> Cc: stable@vger.kernel.org # v3.18+ Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/8952/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Marc Zyngier 提交于
When handling a fault in stage-2, we need to resync I$ and D$, just to be sure we don't leave any old cache line behind. That's very good, except that we do so using the *user* address. Under heavy load (swapping like crazy), we may end up in a situation where the page gets mapped in stage-2 while being unmapped from userspace by another CPU. At that point, the DC/IC instructions can generate a fault, which we handle with kvm->mmu_lock held. The box quickly deadlocks, user is unhappy. Instead, perform this invalidation through the kernel mapping, which is guaranteed to be present. The box is much happier, and so am I. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com> Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
-
由 Marc Zyngier 提交于
Let's assume a guest has created an uncached mapping, and written to that page. Let's also assume that the host uses a cache-coherent IO subsystem. Let's finally assume that the host is under memory pressure and starts to swap things out. Before this "uncached" page is evicted, we need to make sure we invalidate potential speculated, clean cache lines that are sitting there, or the IO subsystem is going to swap out the cached view, loosing the data that has been written directly into memory. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com> Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
-
由 Marc Zyngier 提交于
Trying to emulate the behaviour of set/way cache ops is fairly pointless, as there are too many ways we can end-up missing stuff. Also, there is some system caches out there that simply ignore set/way operations. So instead of trying to implement them, let's convert it to VA ops, and use them as a way to re-enable the trapping of VM ops. That way, we can detect the point when the MMU/caches are turned off, and do a full VM flush (which is what the guest was trying to do anyway). This allows a 32bit zImage to boot on the APM thingy, and will probably help bootloaders in general. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com> Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>
-
由 Laurent Pinchart 提交于
Commit 4bb25789 ("arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops") moved the setting of the DMA operations from arm_iommu_attach_device() to arch_setup_dma_ops() where the DMA operations to be used are selected based on whether the device is connected to an IOMMU. However, the IOMMU detection scheme requires the IOMMU driver to be ported to the new IOMMU of_xlate API. As no driver has been ported yet, this effectively breaks all IOMMU ARM users that depend on the IOMMU being handled transparently by the DMA mapping API. Fix this by restoring the setting of DMA IOMMU ops in arm_iommu_attach_device() and splitting the rest of the function into a new internal __arm_iommu_attach_device() function, called by arch_setup_dma_ops(). Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: NWill Deacon <will.deacon@arm.com> Tested-by: NHeiko Stuebner <heiko@sntech.de> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Linus Torvalds 提交于
The core VM already knows about VM_FAULT_SIGBUS, but cannot return a "you should SIGSEGV" error, because the SIGSEGV case was generally handled by the caller - usually the architecture fault handler. That results in lots of duplication - all the architecture fault handlers end up doing very similar "look up vma, check permissions, do retries etc" - but it generally works. However, there are cases where the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV. In particular, when accessing the stack guard page, libsigsegv expects a SIGSEGV. And it usually got one, because the stack growth is handled by that duplicated architecture fault handler. However, when the generic VM layer started propagating the error return from the stack expansion in commit fee7e49d ("mm: propagate error from stack expansion even for guard page"), that now exposed the existing VM_FAULT_SIGBUS result to user space. And user space really expected SIGSEGV, not SIGBUS. To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those duplicate architecture fault handlers about it. They all already have the code to handle SIGSEGV, so it's about just tying that new return value to the existing code, but it's all a bit annoying. This is the mindless minimal patch to do this. A more extensive patch would be to try to gather up the mostly shared fault handling logic into one generic helper routine, and long-term we really should do that cleanup. Just from this patch, you can generally see that most architectures just copied (directly or indirectly) the old x86 way of doing things, but in the meantime that original x86 model has been improved to hold the VM semaphore for shorter times etc and to handle VM_FAULT_RETRY and other "newer" things, so it would be a good idea to bring all those improvements to the generic case and teach other architectures about them too. Reported-and-tested-by: NTakashi Iwai <tiwai@suse.de> Tested-by: NJan Engelhardt <jengelh@inai.de> Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots" Cc: linux-arch@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 29 1月, 2015 8 次提交
-
-
由 Arnd Bergmann 提交于
The recently added ARM_KERNMEM_PERMS feature works by manipulating the kernel page tables, which obviously requires an MMU. Trying to enable this feature when the MMU is disabled results in a lot of compile errors in mm/init.c, so let's add a Kconfig dependency to avoid that case. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Rob Herring 提交于
Minimal builds for v7M are broken when printk is disabled. The caller is assembly so add the necessary ifdef around the call. Signed-off-by: NRob Herring <robh@kernel.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nicolas Pitre 提交于
There is currently a hardcoded limit of 64KB for the DTB to live in and be extended with ATAG info. Some DTBs have outgrown that limit: $ du -b arch/arm/boot/dts/omap3-n900.dtb 70212 arch/arm/boot/dts/omap3-n900.dtb Furthermore, the actual size passed to atags_to_fdt() included the stack size which is obviously wrong. The initial DTB size is known, so use it to size the allocated workspace with a 50% growth assumption and relocate the temporary stack above that. This is also clamped to 32KB min / 1MB max for robustness against bad DTB data. Reported-by: NPali Rohár <pali.rohar@gmail.com> Tested-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Will Deacon 提交于
When tearing down the DMA ops for a device via of_dma_deconfigure, we unconditionally detach the device from its IOMMU domain. For devices that aren't actually behind an IOMMU, this produces a "Not attached" warning message on the console. This patch changes the teardown code so that we don't detach from the IOMMU domain when there isn't an IOMMU dma mapping to start with. Reported-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Magnus Damm 提交于
As of commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain."), the Lager legacy board support is known to be broken. The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code. To fix this issue specific to non-multiplatform r8a7790 and Lager: 1) Instantiate the GIC from platform board code and also 2) Skip over the DT arch timer as well as 3) Force delay setup based on DT CPU frequency With these 3 fixes in place interrupts on Lager are now unbroken. Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work. Signed-off-by: NMagnus Damm <damm+renesas@opensource.se> Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
-
由 Andrey Skvortsov 提交于
After 'make clean' vdso64.so and vdso64.dbg.so were left in arch/x86/vdso/. Link: http://lkml.kernel.org/r/1422453867-17326-1-git-send-email-andrej.skvortzov@gmail.comSigned-off-by: NAndrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
-
由 Magnus Damm 提交于
As of commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain."), the APE6EVM legacy board support is known to be broken. The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code. To fix this issue specific to non-muliplatform r8a73a4 and APE6EVM: 1) Instantiate the GIC from platform board code and also 2) Skip over the DT arch timer as well as 3) Force delay setup based on DT CPU frequency With these 3 fixes in place interrupts on APE6EVM are now unbroken. Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work. Signed-off-by: NMagnus Damm <damm+renesas@opensource.se> Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
-
由 Thomas Petazzoni 提交于
Since commit f2c3c67f (merge commit that adds commit "ARM: mvebu: completely disable hardware I/O coherency"), we disable I/O coherency on Armada EBU platforms. However, we continue to initialize the coherency fabric, because this coherency fabric is needed on Armada XP for inter-CPU coherency. Unfortunately, due to this, we also continued to execute the coherency fabric initialization code for Armada 375/38x, which switched the PL310 into I/O coherent mode. This has the effect of disabling the outer cache sync operation: this is needed when I/O coherency is enabled to work around a PCIe/L2 deadlock. But obviously, when I/O coherency is disabled, having the outer cache sync operation is crucial. Therefore, this commit fixes the armada_375_380_coherency_init() so that the PL310 is switched to I/O coherent mode only if I/O coherency is enabled. Without this fix, all devices using DMA are broken on Armada 375/38x. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Cc: <stable@vger.kernel.org> # v3.8+
-
- 28 1月, 2015 4 次提交
-
-
由 Kan Liang 提交于
Intel Airmont supports the same architectural and non-architectural performance monitoring events as Silvermont. Signed-off-by: NKan Liang <kan.liang@intel.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1421913053-99803-1-git-send-email-kan.liang@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Stephane Eranian 提交于
This patch fixes a systematic crash in rapl_scale() due to an invalid pointer. The bug was introduced by commit: 89cbc767 ("x86: Replace __get_cpu_var uses") The fix is simple. Just put the parenthesis where it needs to be, i.e., around rapl_pmu. To my surprise, the compiler was not complaining about passing an integer instead of a pointer. Reported-by: NVince Weaver <vincent.weaver@maine.edu> Tested-by: NVince Weaver <vincent.weaver@maine.edu> Fixes: 89cbc767 ("x86: Replace __get_cpu_var uses") Signed-off-by: NStephane Eranian <eranian@google.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: cl@linux.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20150122203834.GA10228@thinkpadSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Kan Liang 提交于
There were some issues about the uncore driver tried to access non-existing boxes, which caused boot crashes. These issues have been all fixed. But we should avoid boot failures if that ever happens again. This patch intends to prevent this kind of potential issues. It moves uncore_box_init out of driver initialization. The box will be initialized when it's first enabled. Signed-off-by: NKan Liang <kan.liang@intel.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Link: http://lkml.kernel.org/r/1421729665-5912-1-git-send-email-kan.liang@intel.com Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Stephane Eranian <eranian@google.com> Cc: Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Boris Ostrovsky 提交于
Commits 65cef131 ("x86, microcode: Add a disable chicken bit") and a18a0f68 ("x86, microcode: Don't initialize microcode code on paravirt") allow microcode driver skip initialization when microcode loading is not permitted. However, they don't prevent the driver from being loaded since the init code returns 0. If at some point later the driver gets unloaded this will result in an oops while trying to deregister the (never registered) device. To avoid this, make init code return an error on paravirt or when microcode loading is disabled. The driver will then never be loaded. Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com> Link: http://lkml.kernel.org/r/1422411669-25147-1-git-send-email-boris.ostrovsky@oracle.comReported-by: NJames Digwall <james@dingwall.me.uk> Cc: stable@vger.kernel.org # 3.18 Signed-off-by: NBorislav Petkov <bp@suse.de>
-
- 27 1月, 2015 1 次提交
-
-
由 Kees Cook 提交于
Commit e6023367 ("x86, kaslr: Prevent .bss from overlaping initrd") added Perl to the required build environment. This reimplements in shell the Perl script used to find the size of the kernel with bss and brk added. Signed-off-by: NKees Cook <keescook@chromium.org> Reported-by: NRob Landley <rob@landley.net> Acked-by: NRob Landley <rob@landley.net> Cc: Anca Emanuel <anca.emanuel@gmail.com> Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Junjie Mao <eternal.n08@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 26 1月, 2015 1 次提交
-
-
由 Maxime Ripard 提交于
Commit f77d55a3 ("serial: 8250_dw: get index of serial line from DT aliases") made the serial driver now use the serial aliases to get the tty number, pointing out that our aliases have been wrong all along. Remove them from the DTSI and add custom ones in the relevant boards. Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
-
- 25 1月, 2015 1 次提交
-
-
由 Nimrod Andy 提交于
The commit (3d125f9c) cause i.MX6SX sdb enet cannot work. The cause is the commit add mdio node with un-correct phy address. The patch just correct i.MX6sx sdb board enet phy address. V2: * As Shawn's suggestion that unit-address should match 'reg' property, so update ethernet-phy unit-address. Acked-by: NStefan Agner <stefan@agner.ch> Signed-off-by: NFugang Duan <B38611@freescale.com> Acked-by: NShawn Guo <shawn.guo@linaro.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-