11 Feb, 2015
12 commits
-
commit 7fb08eca45270d0ae86e1ad9d39c40b7a55d0190 upstream.
This replaces four copies in various stages of mm_fault_error() handling
with just a single one. It will also allow for more natural placement
of the unlocking after some further cleanup.Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit da63865a01c6384d459464e5165d95d4f04878d8 upstream.
Commits 65cef1311d5d ("x86, microcode: Add a disable chicken bit") and
a18a0f6850d4 ("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: Boris Ostrovsky
Link: http://lkml.kernel.org/r/1422411669-25147-1-git-send-email-boris.ostrovsky@oracle.com
Reported-by: James Digwall
Signed-off-by: Borislav Petkov
Signed-off-by: Greg Kroah-Hartman -
commit fddcd300732dad5b822d27de7aa78998dca43162 upstream.
I2S1, I2S2 on Exynos4 SoC series have limited functionality compared
to I2S0, "samsung,s3c6410-i2s" compatible should be used for them.Signed-off-by: Sylwester Nawrocki
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 44b82b7700d05a52cd983799d3ecde1a976b3bed upstream.
Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").There are two major issues with the arm64 /proc/cpuinfo format
currently:* The "Features" line describes (only) the 64-bit hwcaps, which is
problematic for some 32-bit applications which attempt to parse it. As
the same names are used for analogous ISA features (e.g. aes) despite
these generally being architecturally unrelated, it is not possible to
simply append the 64-bit and 32-bit hwcaps in a manner that might not
be misleading to some applications.Various potential solutions have appeared in vendor kernels. Typically
the format of the Features line varies depending on whether the task
is 32-bit.* Information is only printed regarding a single CPU. This does not
match the ARM format, and does not provide sufficient information in
big.LITTLE systems where CPUs are heterogeneous. The CPU information
printed is queried from the current CPU's registers, which is racy
w.r.t. cross-cpu migration.This patch attempts to solve these issues. The following changes are
made:* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
the "Features" line contains the decoded 32-bit hwcaps, as with the
arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
the absense of compat support, the Features line is empty.The set of hwcaps injected into a task's auxval are unaffected.
* Properties are printed per-cpu, as with the ARM port. The per-cpu
information is queried from pre-recorded cpu information (as used by
the sanity checks).* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
field is removed. The only users so far are 32-bit applications tied
to particular boards, so no portable applications should be affected,
and this should prevent future tying to particular boards.The following differences remain:
* No model_name is printed, as this cannot be queried from the hardware
and cannot be provided in a stable fashion. Use of the CPU
{implementor,variant,part,revision} fields is sufficient to identify a
CPU and is portable across arm and arm64.* The following system-wide properties are not provided, as they are not
possible to provide generally. Programs relying on these are already
tied to particular (32-bit only) boards:
- Hardware
- Revision
- SerialNo software has yet been identified for which these remaining
differences are problematic.Cc: Greg Hackmann
Cc: Ian Campbell
Cc: Serban Constantinescu
Cc: Will Deacon
Cc: cross-distro@lists.linaro.org
Cc: linux-api@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas
Signed-off-by: Mark Rutland
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 8e64806672466392acf19e14427d1c29df3e58b9 upstream.
Commit e1a5848e3398 ("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 a391263cd84e ("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: e1a5848e3398 ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE")
Reported-by: Raymond Ngun
Tested-by: Raymond Ngun
Reviewed-by: Gregory Fong
Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit d76e9b9fc5de7e8fc4fd0e72a94e8c723929ffea upstream.
Commit 842dfc11ea9a ("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' failedFix that to use the new write_32bit_cp1_register() macro so that ".set
hardfloat" is automatically added when -msoft-float is in use.Fixes 842dfc11ea9a ("MIPS: Fix build with binutils 2.24.51+")
Signed-off-by: James Hogan
Cc: Ralf Baechle
Cc: Paul Burton
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9173/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit 5e32033e14ca9c7f7341cb383f5a05699b0b5382 upstream.
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
25c300030016 ("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: James Hogan
Cc: Ralf Baechle
Cc: Paul Burton
Cc: David Daney
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9172/
Signed-off-by: Ralf Baechle
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit c7754e75100ed5e3068ac5085747f2bfc386c8d6 upstream.
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: Hemmo Nieminen
Signed-off-by: Aaro Koskinen
Cc: David Daney
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/8953/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit 63a87fe0d0de2ce126a8cec9a299a133cfd5658e upstream.
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] [] show_stack+0x68/0x80
[ 93.920335] [] dump_stack+0x6c/0x90
[ 93.925395] [] warn_slowpath_common+0x94/0xd8
[ 93.931324] [] flush_smp_call_function_queue+0x1c4/0x1d0
[ 93.938208] [] hotplug_cfd+0xf0/0x108
[ 93.943444] [] notifier_call_chain+0x5c/0xb8
[ 93.949286] [] cpu_notify+0x24/0x60
[ 93.954348] [] take_cpu_down+0x38/0x58
[ 93.959670] [] multi_cpu_stop+0x154/0x180
[ 93.965250] [] cpu_stopper_thread+0xd8/0x160
[ 93.971093] [] smpboot_thread_fn+0x1ec/0x1f8
[ 93.976936] [] kthread+0xd4/0xf0
[ 93.981735] [] 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] [] irq_work_run_list+0x8/0xf8
[ 94.200802] [] irq_work_run+0x34/0x60
[ 94.206036] [] hotplug_cfd+0xf0/0x108
[ 94.211269] [] notifier_call_chain+0x5c/0xb8
[ 94.217111] [] cpu_notify+0x24/0x60
[ 94.222171] [] take_cpu_down+0x38/0x58
[ 94.227491] [] multi_cpu_stop+0x154/0x180
[ 94.233072] [] cpu_stopper_thread+0xd8/0x160
[ 94.238914] [] smpboot_thread_fn+0x1ec/0x1f8
[ 94.244757] [] kthread+0xd4/0xf0
[ 94.249555] [] ret_from_kernel_thread+0x14/0x1c
[ 94.255654]
[ 94.257146]
Code: a2423c40 40026000 30420001 dc820000 10400037 00000000 0000010f 0000010f
[ 94.267183] ---[ end trace c9e3815ee655bdaa ]---
[ 94.271804] Fatal exception: panic in 5 secondsReported-by: Hemmo Nieminen
Signed-off-by: Aaro Koskinen
Acked-by: David Daney
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/8952/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit a3e6c1eff54878506b2dddcc202df9cc8180facb upstream.
If the irq_chip does not define .irq_disable, any call to disable_irq
will defer disabling the IRQ until it fires while marked as disabled.
This assumes that the handler function checks for this condition, which
handle_percpu_irq does not. In this case, calling disable_irq leads to
an IRQ storm, if the interrupt fires while disabled.This optimization is only useful when disabling the IRQ is slow, which
is not true for the MIPS CPU IRQ.Disable this optimization by implementing .irq_disable and .irq_enable
Signed-off-by: Felix Fietkau
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8949/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit 9ead8632bbf454cfc709b6205dc9cd8582fb0d64 upstream.
The following commits:
5890f70f15c52d (MIPS: Use dedicated exception handler if CPU supports RI/XI exceptions)
6575b1d4173eae (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: David Daney
Cc: Leonid Yegoshin
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/8880/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit 51ac3d2f0c505ca36ffc9715ffd518d756589ef8 upstream.
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: 1278998f8ff6 ("PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)")
Signed-off-by: Charlotte Richardson
Signed-off-by: Bjorn Helgaas
CC: Myron Stowe
Signed-off-by: Greg Kroah-Hartman
06 Feb, 2015
8 commits
-
commit a4dba130891271084344c12537731542ec77cb85 upstream.
Introduce an arch specific function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache maintenance operations (we don't know how to
find the pfn from the mfn).No change of behaviour for x86.
Signed-off-by: Stefano Stabellini
Reviewed-by: David Vrabel
Reviewed-by: Catalin Marinas
Acked-by: Ian Campbell
Acked-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit 98b008dff8452653909d9263efda925873e8d8bb upstream.
This patch fixes a systematic crash in rapl_scale()
due to an invalid pointer.The bug was introduced by commit:
89cbc76768c2 ("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: Vince Weaver
Tested-by: Vince Weaver
Fixes: 89cbc76768c2 ("x86: Replace __get_cpu_var uses")
Signed-off-by: Stephane Eranian
Signed-off-by: Peter Zijlstra (Intel)
Cc: Arnaldo Carvalho de Melo
Cc: cl@linux.com
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/20150122203834.GA10228@thinkpad
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit ef454caeb740ee4e1b89aeb7f7692d5ddffb6830 upstream.
Intel Airmont supports the same architectural and non-architectural
performance monitoring events as Silvermont.Signed-off-by: Kan Liang
Signed-off-by: Peter Zijlstra (Intel)
Cc: Arnaldo Carvalho de Melo
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/1421913053-99803-1-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit dcad68876c21bac709b01eda24e39d4410dc36a8 upstream.
Since commit f2c3c67f00 (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: Thomas Petazzoni
Acked-by: Gregory CLEMENT
Tested-by: Gregory CLEMENT
Signed-off-by: Andrew Lunn
Signed-off-by: Greg Kroah-Hartman -
commit e6eb2eba494d6f99e69ca3c3748cd37a2544ab38 upstream.
The commit 3b8a3c010969 ("powerpc/pseries: Fix endiannes issue in RTAS
call from xmon") was fixing an endianness issue in the call made from
xmon to RTAS.However, as Michael Ellerman noticed, this fix was not complete, the
token value was not byte swapped. This lead to call an unexpected and
most of the time unexisting RTAS function, which is silently ignored by
RTAS.This fix addresses this hole.
Reported-by: Michael Ellerman
Signed-off-by: Laurent Dufour
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit e262eb9381ad51b5de7a9e762ee773bbd25ce650 upstream.
Fix misspelled define.
Fixes: 33692f27597f ("vm: add VM_FAULT_SIGSEGV handling support")
Signed-off-by: Guenter Roeck
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.
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 fee7e49d4514 ("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: Takashi Iwai
Tested-by: Jan Engelhardt
Acked-by: Heiko Carstens # "s390 still compiles and boots"
Cc: linux-arch@vger.kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit d69911a68c865b152a067feaa45e98e6bb0f655b upstream.
Commit e6023367d779 ("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: Kees Cook
Reported-by: Rob Landley
Acked-by: Rob Landley
Cc: Anca Emanuel
Cc: Fengguang Wu
Cc: Junjie Mao
Cc: Kees Cook
Cc: Thomas Gleixner
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
30 Jan, 2015
15 commits
-
commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf upstream.
Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.Even though commit 5d26a105b5a7 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook
Signed-off-by: Mathias Krause
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 4943ba16bbc2db05115707b3ff7b4874e9e3c560 upstream.
This adds the module loading prefix "crypto-" to the template lookup
as well.For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the "crypto-" prefix at every level, correctly rejecting "vfat":net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfatReported-by: Mathias Krause
Signed-off-by: Kees Cook
Acked-by: Mathias Krause
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 38a1dfda8e77d7ba74c94d06d8bc41ba98a4bc8c upstream.
Commit 0dbc6078c06bc0 ('x86, build, pci: Fix PCI_MSI build on !SMP')
introduced the dependency that X86_UP_APIC is only available when
PCI_MSI is false. This effectively prevents PCI_MSI support on 32bit
UP systems because it disables both APIC and IO-APIC. But APIC support
is architecturally required for PCI_MSI.The intention of the patch was to enforce APIC support when PCI_MSI is
enabled, but failed to do so.Remove the !PCI_MSI dependency from X86_UP_APIC and enforce
X86_UP_APIC when PCI_MSI support is enabled on 32bit UP systems.[ tglx: Massaged changelog ]
Fixes 0dbc6078c06bc0 'x86, build, pci: Fix PCI_MSI build on !SMP'
Signed-off-by: Bryan O'Donoghue
Suggested-by: Thomas Gleixner
Reviewed-by: Andy Shevchenko
Cc: Thomas Petazzoni
Link: http://lkml.kernel.org/r/1421967529-9037-1-git-send-email-pure.logic@nexus-software.ie
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 3669ef9fa7d35f573ec9c0e0341b29251c2734a7 upstream.
The Witcher 2 did something like this to allocate a TLS segment index:
struct user_desc u_info;
bzero(&u_info, sizeof(u_info));
u_info.entry_number = (uint32_t)-1;syscall(SYS_set_thread_area, &u_info);
Strictly speaking, this code was never correct. It should have set
read_exec_only and seg_not_present to 1 to indicate that it wanted
to find a free slot without putting anything there, or it should
have put something sensible in the TLS slot if it wanted to allocate
a TLS entry for real. The actual effect of this code was to
allocate a bogus segment that could be used to exploit espfix.The set_thread_area hardening patches changed the behavior, causing
set_thread_area to return -EINVAL and crashing the game.This changes set_thread_area to interpret this as a request to find
a free slot and to leave it empty, which isn't *quite* what the game
expects but should be close enough to keep it working. In
particular, using the code above to allocate two segments will
allocate the same segment both times.According to FrostbittenKing on Github, this fixes The Witcher 2.
If this somehow still causes problems, we could instead allocate
a limit==0 32-bit data segment, but that seems rather ugly to me.Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
Signed-off-by: Andy Lutomirski
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.net
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit e30ab185c490e9a9381385529e0fd32f0a399495 upstream.
32-bit programs don't have an lm bit in their ABI, so they can't
reliably cause LDT_empty to return true without resorting to memset.
They shouldn't need to do this.This should fix a longstanding, if minor, issue in all 64-bit kernels
as well as a potential regression in the TLS hardening code.Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
Signed-off-by: Andy Lutomirski
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.net
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 63ea0a49ae0b145b91ff2b070c01b66fc75854b9 upstream.
STR and SLDT with rip-relative operand can cause a host kernel oops.
Mark them as DstMem as well.Signed-off-by: Nadav Amit
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit f3747379accba8e95d70cec0eae0582c8c182050 upstream.
SYSENTER emulation is broken in several ways:
1. It misses the case of 16-bit code segments completely (CVE-2015-0239).
2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can
still be set without causing #GP).
3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in
legacy-mode.
4. There is some unneeded code.Fix it.
Signed-off-by: Nadav Amit
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit f285f4a21c3253887caceed493089ece17579d59 upstream.
On 64-bit, relocation is not required unless the load address gets
changed. Without this, relocations do unexpected things when the kernel
is above 4G.Reported-by: Baoquan He
Signed-off-by: Kees Cook
Tested-by: Thomas D.
Cc: Vivek Goyal
Cc: Jan Beulich
Cc: Junjie Mao
Cc: Andi Kleen
Link: http://lkml.kernel.org/r/20150116005146.GA4212@www.outflux.net
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 520452172e6b318f3a8bd9d4fe1e25066393de25 upstream.
Many users see this message when booting without knowning that it is
of no importance and that TSC calibration may have succeeded by
another way.As explained by Paul Bolle in
http://lkml.kernel.org/r/1348488259.1436.22.camel@x61.thuisdomein"Fast TSC calibration failed" should not be considered as an error
since other calibration methods are being tried afterward. At most,
those send a warning if they fail (not an error). So let's change
the message from error to warning.[ tglx: Make if pr_info. It's really not important at all ]
Fixes: c767a54ba065 x86/debug: Add KERN_ to bare printks, convert printks to pr_
Signed-off-by: Alexandre Demers
Link: http://lkml.kernel.org/r/1418106470-6906-1-git-send-email-alexandre.f.demers@gmail.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 32c6590d126836a062b3140ed52d898507987017 upstream.
The Hyper-V clocksource is continuous; mark it accordingly.
Signed-off-by: K. Y. Srinivasan
Acked-by: jasowang@redhat.com
Cc: gregkh@linuxfoundation.org
Cc: devel@linuxdriverproject.org
Cc: olaf@aepfle.de
Cc: apw@canonical.com
Link: http://lkml.kernel.org/r/1421108762-3331-1-git-send-email-kys@microsoft.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f upstream.
The mis-naming likely was a copy-and-paste effect.
Signed-off-by: Jan Beulich
Link: http://lkml.kernel.org/r/54B9408B0200007800055E8B@mail.emea.novell.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 8f1e8ee28660018a935c7576b9af8ffe1feab54c upstream.
The current hardware I/O coherency is known to cause problems with DMA
coherent buffers, as it still requires explicit I/O synchronization
barriers, which is not compatible with the semantics expected by the
Linux DMA coherent buffers API.So, in order to have enough time to validate a new solution based on
automatic I/O synchronization barriers, this commit disables hardware
I/O coherency entirely. Future patches will re-enable it.Signed-off-by: Thomas Petazzoni
Signed-off-by: Andrew Lunn
Signed-off-by: Greg Kroah-Hartman -
commit 7ecd0bde5bfea524a843ad8fa8cb66ccbce68779 upstream.
Currently PWM functionality is broken on mx25 due to the wrong assignment of the
PWM "per" clock.According to Documentation/devicetree/bindings/clock/imx25-clock.txt:
pwm_ipg_per 52,so update the pwm "per" to use 'pwm_ipg_per' instead of 'per10' clock.
With this change PWM can work fine on mx25.
Reported-by: Carlos Soto
Signed-off-by: Fabio Estevam
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman -
commit 851b09369255a91e77f56d83e3643439ac5b209a upstream.
Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge. If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Tested-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu
Signed-off-by: Bjorn Helgaas
CC: Thomas Gleixner
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: x86@kernel.org
Signed-off-by: Greg Kroah-Hartman
28 Jan, 2015
5 commits
-
commit 78051e3b7e35722ad3f31dd611f1b34770bddab8 upstream.
If L0 has disabled EPT, don't advertise unrestricted
mode at all since it depends on EPT to run real mode code.Fixes: 92fbc7b195b824e201d9f06f2b93105f72384d65
Reviewed-by: Jan Kiszka
Signed-off-by: Bandan Das
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit b485342bd79af363c77ef1a421c4a0aef2de9812 upstream.
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_sizeAfter:
$ 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_sizeFixes: a074335a370e ("x86, um: Mark system call tables readonly")
Cc: H. Peter Anvin
Cc: Andrew Morton
Signed-off-by: Daniel Borkmann
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman -
commit f911d731054ab3d82ee72a16b889e17ca3a2332a upstream.
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
Suggested-by: Geert Uytterhoeven
Signed-off-by: Richard Weinberger
Tested-by: Daniel Walter
Signed-off-by: Greg Kroah-Hartman -
commit 69d2626f97b7f017ee4416b7dc071e9499c2c944 upstream.
64KiB is allocated for qspi dtb partition which is not
sufficient, so updating the partition table size to 512KiB
for device tree partition.This also aligns the QSPI partition definitions between
kernel and U-Boot.Fixes: dc2dd5b8 ("ARM: dts: dra7: Add qspi device")
Signed-off-by: Mugunthan V N
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit b0ddb319db3d7a1943445f0de0a45c07a7f3457a upstream.
The sh73a0 INTC can't mask interrupts properly most likely due to a
hardware bug. Set the .control_parent flag to delegate masking to the
parent interrupt controller, like was already done for irqpin1.Without this, accessing the three-axis digital accelerometer ADXL345
on kzm9g through /dev/input/event1 causes an interrupt storm, which
requires a power-cycle to recover from.This was inspired by a patch for arch/arm/boot/dts/sh73a0.dtsi from
Laurent Pinchart .Signed-off-by: Geert Uytterhoeven
Fixes: 341eb5465f67437a ("ARM: shmobile: INTC External IRQ pin driver on sh73a0")
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman
