28 Aug, 2015
2 commits
-
Pull powerpc fixes from Michael Ellerman:
"Fix MSI/MSI-X on pseries from Guilherme"* tag 'powerpc-4.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case
PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code -
Pull amr64 kvm fix from Will Deacon:
"We've uncovered a nasty bug in the arm64 KVM code which allows a badly
behaved 32-bit guest to bring down the host. The fix is simple (it's
what I believe we call a "brown paper bag" bug) and I don't think it
makes sense to sit on this, particularly as Russell ended up
triggering this rather than just somebody noticing a potential problem
by inspection.Usually arm64 KVM changes would go via Paolo's tree, but he's on
holiday at the moment and the deal is that anything urgent gets
shuffled via the arch trees, so here it is.Summary:
Fix arm64 KVM issue when injecting an abort into a 32-bit guest, which
would lead to an illegal exception return at EL2 and a subsequent host
crash"* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: KVM: Fix host crash when injecting a fault into a 32bit guest
27 Aug, 2015
1 commit
-
When injecting a fault into a misbehaving 32bit guest, it seems
rather idiotic to also inject a 64bit fault that is only going
to corrupt the guest state. This leads to a situation where we
perform an illegal exception return at EL2 causing the host
to crash instead of killing the guest.Just fix the stupid bug that has been there from day 1.
Cc:
Reported-by: Russell King
Tested-by: Russell King
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
26 Aug, 2015
2 commits
-
Since commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if
kernel doesn't support MSI"), the setup of dev->msi_cap/msix_cap and the
disable of MSI/MSI-X interrupts isn't being done at PCI probe time, as
the logic responsible for this was moved in the aforementioned commit
from pci_device_add() to pci_setup_device(). The latter function is not
reachable on PowerPC pseries platform during Open Firmware PCI probing
time.This exhibits as drivers not being able to enable MSI, eg:
bnx2x 0000:01:00.0: no msix capability found
This patch calls pci_msi_setup_pci_dev() explicitly to disable MSI/MSI-X
during PCI probe time on pSeries platform.Fixes: 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
[mpe: Flesh out change log and clarify comment]
Signed-off-by: Guilherme G. Piccoli
Signed-off-by: Michael Ellerman -
Pull x86 fix from Thomas Gleixner:
"A single fix for a APIC regression introduced in 4.0 which went
undetected until now.I screwed up the x2apic cleanup in a subtle way. The screwup is only
visible on systems which have x2apic preenabled in the BIOS and need
to disable it during boot"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/apic: Fix fallout from x2apic cleanup
23 Aug, 2015
2 commits
-
Pull MIPS bug fixes from Ralf Baechle:
"Two more fixes for 4.2.One fixes a build issue with the LLVM assembler - LLVM assembler macro
names are case sensitive, GNU as macro names are insensitive; the
other corrects a license string (GPL v2, not GPLv2) such that the
module loader will recognice the license correctly"* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
FIRMWARE: bcm47xx_nvram: Fix module license.
MIPS: Fix LLVM build issue. -
Pull ARM fixes from Russell King:
"Another couple of small ARM fixes.A patch from Masahiro Yamada who noticed that "make -jN all zImage"
would end up generating bad images where N > 1, and a patch from
Nicolas to fix the Marvell CPU user access optimisation code when page
faults are disabled"* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
ARM: 8418/1: add boot image dependencies to not generate invalid images
ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usage
22 Aug, 2015
5 commits
-
Pull x86 fixes from Ingo Molnar:
"Various low level fixes: fix more fallout from the FPU rework and the
asm entry code rework, plus an MSI rework fix, and an idle-tracing fix"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/fpu/math-emu: Fix crash in fork()
x86/fpu/math-emu: Fix math-emu boot crash
x86/idle: Restore trace_cpu_idle to mwait_idle() calls
x86/irq: Build correct vector mapping for multiple MSI interrupts
Revert "sched/x86_64: Don't save flags on context switch" -
In the recent x2apic cleanup I got two things really wrong:
1) The safety check in __disable_x2apic which allows the function to
be called unconditionally is backwards. The check is there to
prevent access to the apic MSR in case that the machine has no
apic. Though right now it returns if the machine has an apic and
therefor the disabling of x2apic is never invoked.2) x2apic_disable() sets x2apic_mode to 0 after registering the local
apic. That's wrong, because register_lapic_address() checks x2apic
mode and therefor takes the wrong code path.This results in boot failures on machines with x2apic preenabled by
BIOS and can also lead to an fatal MSR access on machines without
apic.The solutions are simple:
1) Correct the sanity check for apic availability
2) Clear x2apic_mode _before_ calling register_lapic_address()Fixes: 659006bf3ae3 'x86/x2apic: Split enable and setup function'
Reported-and-tested-by: Javier Monteagudo
Signed-off-by: Thomas Gleixner
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1224764
Cc: stable@vger.kernel.org # 4.0+
Cc: Laura Abbott
Cc: Jiang Liu
Cc: Joerg Roedel
Cc: Tony Luck
Cc: Borislav Petkov -
Pull irq fixes from Thomas Gleixner:
"A series of small fixlets for a regression visible on OMAP devices
caused by the conversion of the OMAP interrupt chips to hierarchical
interrupt domains. Mostly one liners on the driver side plus a small
helper function in the core to avoid open coded mess in the drivers"* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/crossbar: Restore set_wake functionality
irqchip/crossbar: Restore the mask on suspend behaviour
ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism
irqchip/crossbar: Restore the irq_set_type() mechanism
genirq: Introduce irq_chip_set_type_parent() helper
genirq: Don't return ENOSYS in irq_chip_retrigger_hierarchy -
During later stages of math-emu bootup the following crash triggers:
math_emulate: 0060:c100d0a8
Kernel panic - not syncing: Math emulation needed in kernel
CPU: 0 PID: 1511 Comm: login Not tainted 4.2.0-rc7+ #1012
[...]
Call Trace:
[] dump_stack+0x41/0x52
[] panic+0x77/0x189
[] ? math_error+0x140/0x140
[] math_emulate+0xba7/0xbd0
[] ? fpu__copy+0x138/0x1c0
[] ? __alloc_pages_nodemask+0x12c/0x870
[] ? proc_clear_tty+0x40/0x70
[] ? session_clear_tty+0x1e/0x30
[] ? math_error+0x140/0x140
[] do_device_not_available+0x45/0x70
[] ? fpu__copy+0x138/0x1c0
[] error_code+0x5a/0x60
[] ? math_error+0x140/0x140
[] ? fpu__copy+0x138/0x1c0
[] arch_dup_task_struct+0x25/0x30
[] copy_process.part.51+0xea/0x1480
[] ? dput+0x175/0x200
[] ? no_tty+0x30/0x30
[] ? do_vfs_ioctl+0x322/0x540
[] _do_fork+0xca/0x340
[] ? SyS_rt_sigaction+0x66/0x90
[] SyS_clone+0x27/0x30
[] sysenter_do_call+0x12/0x12The reason is the incorrect assumption in fpu_copy(), that FNSAVE
can be executed from math-emu kernels as well.Don't try to copy the registers, the soft state will be copied
by fork anyway, so the child task inherits the parent task's
soft math state.With this fix applied math-emu kernels boot up fine on modern
hardware and the 'no387 nofxsr' boot options.Cc: Andy Lutomirski
Cc: Bobby Powers
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: Fenghua Yu
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Quentin Casasnovas
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar -
On a math-emu bootup the following crash occurs:
Initializing CPU#0
------------[ cut here ]------------
kernel BUG at arch/x86/kernel/traps.c:779!
invalid opcode: 0000 [#1] SMP
[...]
EIP is at do_device_not_available+0xe/0x70
[...]
Call Trace:
[] error_code+0x5a/0x60
[] ? math_error+0x140/0x140
[] ? fpu__init_cpu+0x59/0xa0
[] cpu_init+0x202/0x330
[] ? __native_set_fixmap+0x1f/0x30
[] trap_init+0x305/0x346
[] start_kernel+0x1a5/0x35d
[] i386_start_kernel+0x82/0x86The reason is that in the following commit:
b1276c48e91b ("x86/fpu: Initialize fpregs in fpu__init_cpu_generic()")
I failed to consider math-emu's limitation that it cannot execute the
FNINIT instruction in kernel mode.The long term fix might be to allow math-emu to execute (certain) kernel
mode FPU instructions, but for now apply the safe (albeit somewhat ugly)
fix: initialize the emulation state explicitly without trapping out to
the FPU emulator.Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Dave Hansen
Cc: Denys Vlasenko
Cc: Fenghua Yu
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Quentin Casasnovas
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar
21 Aug, 2015
2 commits
-
Commit b253149b843f ("sched/idle/x86: Restore mwait_idle() to fix boot
hangs, to improve power savings and to improve performance") restores
mwait_idle(), but the trace_cpu_idle related calls are missing. This
causes powertop on my old desktop powered by Intel Core2 E6550 to
report zero wakeups and zero events.Add them back to restore the proper behaviour.
Fixes: b253149b843f ("sched/idle/x86: Restore mwait_idle() to ...")
Signed-off-by: Jisheng Zhang
Cc:
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1440046479-4262-1-git-send-email-jszhang@marvell.com
Signed-off-by: Thomas Gleixner -
Pull xen build fix from David Vrabel:
"Fix i386 build with an (uncommon) configuration"* tag 'for-linus-4.2-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
x86/xen: make CONFIG_XEN depend on CONFIG_X86_LOCAL_APIC
20 Aug, 2015
2 commits
-
Since commit feb44f1f7a4ac299d1ab1c3606860e70b9b89d69 (x86/xen:
Provide a "Xen PV" APIC driver to support >255 VCPUs) Xen guests need
a full APIC driver and thus should depend on X86_LOCAL_APIC.This fixes an i386 build failure with !SMP && !CONFIG_X86_UP_APIC by
disabling Xen support in this configuration.Users needing Xen support in a non-SMP i386 kernel will need to enable
CONFIG_X86_UP_APIC.Signed-off-by: David Vrabel
Cc: -
The conversion of the wakeupgen irqchip to hierarchical irq domains
failed to provide a mechanism to properly set the trigger type of an
interrupt.The wakeupgen irq chip itself has no mechanism and therefor no
irq_set_type() callback. The code before the conversion relayed the
trigger configuration directly to the underlying GIC.Restore the correct behaviour by setting the wakeupgen irq_set_type
callback to irq_chip_set_type_parent(). This propagates the
set_trigger() call to the underlying GIC irqchip.[ tglx: Massaged changelog ]
Fixes: 7136d457f365 ('ARM: omap: convert wakeupgen to stacked domains')
Signed-off-by: Grygorii Strashko
Acked-by: Tony Lindgren
Cc: Sudeep Holla
Cc:
Cc:
Cc:
Cc:
Cc:
Cc:
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1439554830-19502-5-git-send-email-grygorii.strashko@ti.com
Signed-off-by: Thomas Gleixner
19 Aug, 2015
2 commits
-
Signed-off-by: Ingo Molnar
-
Alex Deucher, Mark Rustad and Alexander Holler reported a regression
with the latest v4.2-rc4 kernel, which breaks some SATA controllers.
With multi-MSI capable SATA controllers, only the first port works,
all other ports time out when executing SATA commands.This happens because the first argument to assign_irq_vector_policy()
is always the base linux irq number of the multi MSI interrupt block,
so all subsequent vector assignments operate on the base linux irq
number, so all MSI irqs are handled as the first irq number. Therefor
the other MSI irqs of a device are never set up correctly and never
fire.Add the loop iterator to the base irq number so all vectors are
assigned correctly.Fixes: b5dc8e6c21e7 "x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors"
Reported-and-tested-by: Alex Deucher
Reported-and-tested-by: Mark Rustad
Reported-and-tested-by: Alexander Holler
Signed-off-by: Jiang Liu
Cc: Tony Luck
Link: http://lkml.kernel.org/r/1439911228-9880-1-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner
18 Aug, 2015
4 commits
-
U-Boot is often used to boot the kernel on ARM boards, but uImage
is not built by "make all", so we are often inclined to do
"make all uImage" to generate DTBs, modules and uImage in a single
command, but we should notice a pitfall behind it. In fact,
"make all uImage" could generate an invalid uImage if it is run with
the parallel option (-j).You can reproduce this problem with the following procedure:
[1] First, build "all" and "uImage" separately.
You will get a valid uImage$ git clean -f -x -d
$ export CROSS_COMPILE=
$ make -s -j8 ARCH=arm multi_v7_defconfig
$ make -s -j8 ARCH=arm all
$ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CHK include/generated/timeconst.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d
Created: Sat Aug 8 23:21:35 2015
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6138648 Bytes = 5994.77 kB = 5.85 MB
Load Address: 80208000
Entry Point: 80208000
Image arch/arm/boot/uImage is ready
$ ls -l arch/arm/boot/*Image
-rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:20 arch/arm/boot/Image
-rw-rw-r-- 1 masahiro masahiro 6138712 Aug 8 23:21 arch/arm/boot/uImage
-rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:20 arch/arm/boot/zImage[2] Update some source file(s)
$ touch init/main.c
[3] Then, re-build "all" and "uImage" simultaneously.
You will get an invalid uImage at random.$ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CHK include/generated/timeconst.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CC init/main.o
CHK include/generated/compile.h
LD init/built-in.o
LINK vmlinux
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
OBJCOPY arch/arm/boot/Image
Building modules, stage 2.
Kernel: arch/arm/boot/Image is ready
GZIP arch/arm/boot/compressed/piggy.gzip
AS arch/arm/boot/compressed/piggy.gzip.o
Kernel: arch/arm/boot/Image is ready
LD arch/arm/boot/compressed/vmlinux
GZIP arch/arm/boot/compressed/piggy.gzip
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-4.2.0-rc5-00156-gdd2384a-d
Created: Sat Aug 8 23:23:14 2015
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 26472 Bytes = 25.85 kB = 0.03 MB
Load Address: 80208000
Entry Point: 80208000
Image arch/arm/boot/uImage is ready
MODPOST 192 modules
AS arch/arm/boot/compressed/piggy.gzip.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
$ ls -l arch/arm/boot/*Image
-rwxrwxr-x 1 masahiro masahiro 13766656 Aug 8 23:23 arch/arm/boot/Image
-rw-rw-r-- 1 masahiro masahiro 26536 Aug 8 23:23 arch/arm/boot/uImage
-rwxrwxr-x 1 masahiro masahiro 6138648 Aug 8 23:23 arch/arm/boot/zImagePlease notice the uImage is extremely small when this issue is
encountered. Besides, "Kernel: arch/arm/boot/zImage is ready" is
displayed twice, before and after the uImage log.The root cause of this is the race condition between zImage and
uImage. Actually, uImage depends on zImage, but the dependency
between the two is only described in arch/arm/boot/Makefile.
Because arch/arm/boot/Makefile is not included from the top-level
Makefile, it cannot know the dependency between zImage and uImage.Consequently, when we run make with the parallel option, Kbuild
updates vmlinux first, and then two different threads descends into
the arch/arm/boot/Makefile almost at the same time, one for updating
zImage and the other for uImage. While one thread is re-generating
zImage, the other also tries to update zImage before creating uImage
on top of that. zImage is overwritten by the slower thread and then
uImage is created based on the half-written zImage.This is the reason why "Kernel: arch/arm/boot/zImage is ready" is
displayed twice, and a broken uImage is created.The same problem could happen on bootpImage.
This commit adds dependencies among Image, zImage, uImage, and
bootpImage to arch/arm/Makefile, which is included from the
top-level Makefile.Signed-off-by: Masahiro Yamada
Signed-off-by: Russell King -
The mmap semaphore should not be taken when page faults are disabled.
Since pagefault_disable() no longer disables preemption, we now need
to use faulthandler_disabled() in place of in_atomic().Signed-off-by: Nicolas Pitre
Tested-by: Mark Salter
Signed-off-by: Russell King -
Matthew Fortune reports:
The genex.S file appears to mix the case of a macro between its definition and
use. A cut down example of this is below. The macro __build_clear_none has
lower case 'build' but ends up being instantiated with upper case BUILD. Can
this be fixed on master. It has been picked up by the LLVM integrated assembler
which is currently case sensitive. We are likely to fix the assembler as well
but the code is currently inconsistent in the kernel..macro __build_clear_none
.endm.macro __BUILD_HANDLER exception handler clear verbose ext
.align 5
.globl handle_\exception; .align 2; .type handle_\exception, @function; .ent
handle_\exception, 0; handle_\exception: .frame $29, 184, $29
.set noat
.globl handle_\exception\ext; .type handle_\exception\ext, @function;
handle_\exception\ext:
__BUILD_clear_\clear
.endm.macro BUILD_HANDLER exception handler clear verbose
__BUILD_HANDLER \exception \handler \clear \verbose _int
.endmBUILD_HANDLER ftlb ftlb none silent
Signed-off-by: Ralf Baechle
Reported-by: Matthew Fortune -
This reverts commit:
2c7577a75837 ("sched/x86_64: Don't save flags on context switch")
It was a nice speedup. It's also not quite correct: SYSENTER
enables interrupts too early.We can re-add this optimization once the SYSENTER code is beaten
into shape, which should happen in 4.3 or 4.4.Signed-off-by: Andy Lutomirski
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: stable@vger.kernel.org # v3.19
Link: http://lkml.kernel.org/r/85f56651f59f76624e80785a8fd3bdfdd089a818.1439838962.git.luto@kernel.org
Signed-off-by: Ingo Molnar
17 Aug, 2015
5 commits
-
Pull ARM SoC fixes from Olof Johansson:
"A smallish batch of fixes, a little more than expected this late, but
all fixes are contained to their platforms and seem reasonably low
risk:- a somewhat large SMP fix for ux500 that still seemed warranted to
include here
- OMAP DT fixes for pbias regulator specification that broke due to
some DT reshuffling
- PCIe IRQ routing bugfix for i.MX
- networking fixes for keystone
- runtime PM for OMAP GPMC
- a couple of error path bug fixes for exynos"* tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: dts: keystone: Fix the mdio bindings by moving it to soc specific file
ARM: dts: keystone: fix the clock node for mdio
memory: omap-gpmc: Don't try to save uninitialized GPMC context
ARM: imx6: correct i.MX6 PCIe interrupt routing
ARM: ux500: add an SMP enablement type and move cpu nodes
ARM: dts: dra7: Fix broken pbias device creation
ARM: dts: OMAP5: Fix broken pbias device creation
ARM: dts: OMAP4: Fix broken pbias device creation
ARM: dts: omap243x: Fix broken pbias device creation
ARM: EXYNOS: fix double of_node_put() on error path
ARM: EXYNOS: Fix potentian kfree() of ro memory -
Pull MIPS bugfix from Ralf Baechle:
"Only a single MIPS fix - the math when invoking syscall_trace_enter
was wrong"* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: Fix seccomp syscall argument for MIPS64 -
Merge x86 fixes from Ingo Molnar:
"Two followup fixes related to the previous LDT fix"Also applied a further FPU emulation fix from Andy Lutomirski to the
branch before actually merging it.* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
x86/ldt: Further fix FPU emulation
x86/ldt: Correct FPU emulation access to LDT
x86/ldt: Correct LDT access in single stepping logic -
The previous fix confused a selector with a segment prefix. Fix it.
Compile-tested only.
Cc: stable@vger.kernel.org
Cc: Juergen Gross
Reported-by: Linus Torvalds
Fixes: 4809146b86c3 ("x86/ldt: Correct FPU emulation access to LDT")
Signed-off-by: Andy Lutomirski
Signed-off-by: Linus Torvalds -
…nel/git/ssantosh/linux-keystone into fixes
ARM: Couple of Keysyone MDIO DTS fixes for 4.2-rc6+
These are necessary to get the NIC card working on all Keystone
EVMs. Couple of boards are broken without these two fixes.* tag 'keystone-dts-late-fixes-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone:
ARM: dts: keystone: Fix the mdio bindings by moving it to soc specific file
ARM: dts: keystone: fix the clock node for mdioSigned-off-by: Olof Johansson <olof@lixom.net>
16 Aug, 2015
1 commit
-
Commit 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)")
fixed indirect system calls on O32 but it also introduced a bug for MIPS64
where it erroneously modified the v0 (syscall) register with the assumption
that the sycall offset hasn't been taken into consideration. This breaks
seccomp on MIPS64 n64 and n32 ABIs. We fix this by replacing the addition
with a move instruction.Fixes: 4c21b8fd8f14 ("MIPS: seccomp: Handle indirect system calls (o32)")
Cc: # 3.15+
Reviewed-by: James Hogan
Signed-off-by: Markos Chandras
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10951/
Signed-off-by: Ralf Baechle
15 Aug, 2015
2 commits
-
Pull KVM fixes from Paolo Bonzini:
"Just two very small & simple patches"* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST
KVM: x86: zero IDT limit on entry to SMM -
Pull perf fixes from Ingo Molnar:
"Misc fixes: PMU driver corner cases, tooling fixes, and an 'AUX'
(Intel PT) race related core fix"* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel/cqm: Do not access cpu_data() from CPU_UP_PREPARE handler
perf/x86/intel: Fix memory leak on hot-plug allocation fail
perf: Fix PERF_EVENT_IOC_PERIOD migration race
perf: Fix double-free of the AUX buffer
perf: Fix fasync handling on inherited events
perf tools: Fix test build error when bindir contains double slash
perf stat: Fix transaction lenght metrics
perf: Fix running time accounting
14 Aug, 2015
6 commits
-
Pull ARM fixes from Russell King:
"Another few small ARM fixes, mostly addressing some VDSO issues"* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
ARM: 8410/1: VDSO: fix coarse clock monotonicity regression
ARM: 8409/1: Mark ret_fast_syscall as a function
ARM: 8408/1: Fix the secondary_startup function in Big Endian case
ARM: 8405/1: VDSO: fix regression with toolchains lacking ld.bfd executable -
Commit 3f5159a9221f ("x86/asm/entry/32: Update -ENOSYS handling to match
the 64-bit logic") broke the ENOSYS handling for the 32-bit compat case.
The proper error return value was never loaded into %rax, except if
things just happened to go through the audit paths, which ended up
reloading the return value.This moves the loading or %rax into the normal system call path, just to
make sure the error case triggers it. It's kind of sad, since it adds a
useless instruction to reload the register to the fast path, but it's
not like that single load from the stack is going to be noticeable.Reported-by: David Drysdale
Tested-by: Kees Cook
Acked-by: Andy Lutomirski
Cc: Denys Vlasenko
Cc: Ingo Molnar
Signed-off-by: Linus Torvalds -
Pull xen bug fixes from David Vrabel:
- revert a fix from 4.2-rc5 that was causing lots of WARNING spam.
- fix a memory leak affecting backends in HVM guests.
- fix PV domU hang with certain configurations.
* tag 'for-linus-4.2-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/xenbus: Don't leak memory when unmapping the ring on HVM backend
Revert "xen/events/fifo: Handle linked events when closing a port"
x86/xen: build "Xen PV" APIC driver for domU as well -
This reverts commits 9a036b93a344 ("x86/signal/64: Remove 'fs' and 'gs'
from sigcontext") and c6f2062935c8 ("x86/signal/64: Fix SS handling for
signals delivered to 64-bit programs").They were cleanups, but they break dosemu by changing the signal return
behavior (and removing 'fs' and 'gs' from the sigcontext struct - while
not actually changing any behavior - causes build problems).Reported-and-tested-by: Stas Sergeev
Acked-by: Andy Lutomirski
Cc: Ingo Molnar
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds -
Currently mdio bindings are defined in keystone.dtsi and this results
in incorrect unit address for the node on K2E and K2L SoCs. Fix this
by moving them to SoC specific DTS file.Signed-off-by: Murali Karicheri
Signed-off-by: Santosh Shilimkar -
Currently the MDIO clock is pointing to clkpa instead of clkcpgmac.
MDIO is part of the ethss and the clock should be clkcpgmac.Signed-off-by: Murali Karicheri
Signed-off-by: Santosh Shilimkar
13 Aug, 2015
2 commits
-
…wnguo/linux into fixes
The i.MX fixes for 4.2, 3rd round:
- Fix i.MX6 PCIe interrupt routing which gets missed from stacked IRQ
domain conversion. The PCIe wakeup support is currently broken
because of this.* tag 'imx-fixes-4.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: imx6: correct i.MX6 PCIe interrupt routingSigned-off-by: Olof Johansson <olof@lixom.net>
-
Two fixes for bugs in Exynos power domain error exit path:
1. kfree() of read-only memory (name of power domain returned
by kstrdup_const()),
2. Doubled of_node_put() leading to invalid ref count for OF node.* tag 'samsung-mach-fixes-4.2' of https://github.com/krzk/linux:
ARM: EXYNOS: fix double of_node_put() on error path
ARM: EXYNOS: Fix potentian kfree() of ro memorySigned-off-by: Olof Johansson
12 Aug, 2015
2 commits
-
Tony reports that booting his 144-cpu machine with maxcpus=10 triggers
the following WARN_ON():[ 21.045727] WARNING: CPU: 8 PID: 647 at arch/x86/kernel/cpu/perf_event_intel_cqm.c:1267 intel_cqm_cpu_prepare+0x75/0x90()
[ 21.045744] CPU: 8 PID: 647 Comm: systemd-udevd Not tainted 4.2.0-rc4 #1
[ 21.045745] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRHSXSD1.86B.0066.R00.1506021730 06/02/2015
[ 21.045747] 0000000000000000 0000000082771b09 ffff880856333ba8 ffffffff81669b67
[ 21.045748] 0000000000000000 0000000000000000 ffff880856333be8 ffffffff8107b02a
[ 21.045750] ffff88085b789800 ffff88085f68a020 ffffffff819e2470 000000000000000a
[ 21.045750] Call Trace:
[ 21.045757] [] dump_stack+0x45/0x57
[ 21.045759] [] warn_slowpath_common+0x8a/0xc0
[ 21.045761] [] warn_slowpath_null+0x1a/0x20
[ 21.045762] [] intel_cqm_cpu_prepare+0x75/0x90
[ 21.045764] [] intel_cqm_cpu_notifier+0x42/0x160
[ 21.045767] [] notifier_call_chain+0x4d/0x80
[ 21.045769] [] __raw_notifier_call_chain+0xe/0x10
[ 21.045770] [] _cpu_up+0xe8/0x190
[ 21.045771] [] cpu_up+0x7a/0xa0
[ 21.045774] [] cpu_subsys_online+0x40/0x90
[ 21.045777] [] device_online+0x67/0x90
[ 21.045778] [] online_store+0x8a/0xa0
[ 21.045782] [] dev_attr_store+0x18/0x30
[ 21.045785] [] sysfs_kf_write+0x3a/0x50
[ 21.045786] [] kernfs_fop_write+0x120/0x170
[ 21.045789] [] __vfs_write+0x37/0x100
[ 21.045791] [] ? __sb_start_write+0x58/0x110
[ 21.045795] [] ? security_file_permission+0x3d/0xc0
[ 21.045796] [] vfs_write+0xa9/0x190
[ 21.045797] [] SyS_write+0x55/0xc0
[ 21.045800] [] ? do_page_fault+0x30/0x80
[ 21.045804] [] entry_SYSCALL_64_fastpath+0x12/0x71
[ 21.045805] ---[ end trace fe228b836d8af405 ]---The root cause is that CPU_UP_PREPARE is completely the wrong notifier
action from which to access cpu_data(), because smp_store_cpu_info()
won't have been executed by the target CPU at that point, which in turn
means that ->x86_cache_max_rmid and ->x86_cache_occ_scale haven't been
filled out.Instead let's invoke our handler from CPU_STARTING and rename it
appropriately.Reported-by: Tony Luck
Signed-off-by: Matt Fleming
Signed-off-by: Peter Zijlstra (Intel)
Cc: Ashok Raj
Cc: Kanaka Juvva
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Vikas Shivappa
Link: http://lkml.kernel.org/r/1438863163-14083-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar -
We fail to free the shared_regs allocation if the constraint_list
allocation fails.Cure this and be more consistent in NULL-ing the pointers after free.
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar
