12 Jan, 2017
23 commits
-
commit 6b7df3ce92ac82ec3f4a2953b6fed77da7b38aaa upstream.
__s390_dma_map_sg maps a dma-contiguous area. Although we only map
whole pages we have to take into account that the area doesn't start
or stop at a page boundary because we use the dma address to loop
over the individual sg entries. Failing to do that might lead to an
access of the wrong sg entry.Fixes: ee877b81c6b9 ("s390/pci_dma: improve map_sg")
Reported-and-tested-by: Christoph Raisch
Signed-off-by: Sebastian Ott
Reviewed-by: Gerald Schaefer
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit ebb299a51059017ec253bd30781a83d1f6e11b24 upstream.
The s390 specific sched_domain_topology_level should always be used,
not only if the machine provides topology information. Luckily this
odd behaviour, that was by accident introduced with git commit
d05d15da18f5 ("s390/topology: delay initialization of topology cpu
masks") has currently no side effect.Fixes: d05d15da18f5 ("s390/topology: delay initialization of topology cpumasks")
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit 1803b9a52c4e5a5dbb8a27126f6bc06939359753 upstream.
The core AES cipher implementation that uses ARMv8 Crypto Extensions
instructions erroneously loads the round keys as 64-bit quantities,
which causes the algorithm to fail when built for big endian. In
addition, the key schedule generation routine fails to take endianness
into account as well, when loading the combining the input key with
the round constants. So fix both issues.Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit caf4b9e2b326cc2a5005a5c557274306536ace61 upstream.
Emit the XTS tweak literal constants in the appropriate order for a
single 128-bit scalar literal load.Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit ee71e5f1e7d25543ee63a80451871f8985b8d431 upstream.
The SHA1 digest is an array of 5 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x4 vector
ones where appropriate.Fixes: 2c98833a42cd ("arm64/crypto: SHA-1 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit a2c435cc99862fd3d165e1b66bf48ac72c839c62 upstream.
The AES implementation using pure NEON instructions relies on the generic
AES key schedule generation routines, which store the round keys as arrays
of 32-bit quantities stored in memory using native endianness. This means
we should refer to these round keys using 4x4 loads rather than 16x1 loads.
In addition, the ShiftRows tables are loading using a single scalar load,
which is also affected by endianness, so emit these tables in the correct
order depending on whether we are building for big endian or not.Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 56e4e76c68fcb51547b5299e5b66a135935ff414 upstream.
The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions
refers to the AES round keys as pairs of 64-bit quantities, which causes
failures when building the code for big endian. In addition, it byte swaps
the input counter unconditionally, while this is only required for little
endian builds. So fix both issues.Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 58010fa6f71c9577922b22e46014b95a4ec80fa0 upstream.
The AES key schedule generation is mostly endian agnostic, with the
exception of the rotation and the incorporation of the round constant
at the start of each round. So implement a big endian specific version
of that part to make the whole routine big endian compatible.Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 9c433ad5083fd4a4a3c721d86cbfbd0b2a2326a5 upstream.
The GHASH key and digest are both pairs of 64-bit quantities, but the
GHASH code does not always refer to them as such, causing failures when
built for big endian. So replace the 16x1 loads and stores with 2x8 ones.Fixes: b913a6404ce2 ("arm64/crypto: improve performance of GHASH algorithm")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 174122c39c369ed924d2608fc0be0171997ce800 upstream.
The SHA256 digest is an array of 8 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x32 vector
ones where appropriate.Fixes: 6ba6c74dfc6b ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 9e6e7c74315095fd40f41003850690c711e44420 upstream.
We added some new locking but forgot to unlock on error.
Fixes: 57127645d79d ("s390/zcrypt: Introduce new SHA-512 based Pseudo Random Generator.")
Signed-off-by: Dan Carpenter
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit 3df8d9208569ef0b2313e516566222d745f3b94b upstream.
A typo (or mis-merge?) resulted in leaf 6 only being probed if
cpuid_level >= 7.Fixes: 2ccd71f1b278 ("x86/cpufeature: Move some of the scattered feature bits to x86_capability")
Signed-off-by: Andy Lutomirski
Acked-by: Borislav Petkov
Cc: Brian Gerst
Link: http://lkml.kernel.org/r/6ea30c0e9daec21e488b54761881a6dfcf3e04d0.1481825597.git.luto@kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit a01aa6c9f40fe03c82032e7f8b3bcf1e6c93ac0e upstream.
As userspace knows nothing about kernel config, thus #ifdefs
around ABI prctl constants makes them invisible to userspace.Let it be clean'n'simple: remove #ifdefs.
If kernel has CONFIG_CHECKPOINT_RESTORE disabled, sys_prctl()
will return -EINVAL for those prctls.Reported-by: Paul Bolle
Signed-off-by: Dmitry Safonov
Acked-by: Andy Lutomirski
Cc: 0x7f454c46@gmail.com
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Cyrill Gorcunov
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-mm@kvack.org
Cc: oleg@redhat.com
Fixes: 2eefd8789698 ("x86/arch_prctl/vdso: Add ARCH_MAP_VDSO_*")
Link: http://lkml.kernel.org/r/20161027141516.28447-2-dsafonov@virtuozzo.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 328cf6927bb72cadefddebbc9a23c793108147a2 upstream.
If CONFIG_ETRAX_AXISFLASHMAP is not configured, the flash rescue image
object file is empty. With recent versions of binutils, this results
in the following build error.cris-linux-objcopy: error:
the input file 'arch/cris/boot/rescue/rescue.o' has no sectionsThis is seen, for example, when trying to build cris:allnoconfig
with recently generated toolchains.Since it does not make sense to build a flash rescue image if there is
no flash, only build it if CONFIG_ETRAX_AXISFLASHMAP is enabled.Reported-by: kbuild test robot
Fixes: 66ab3a74c5ce ("CRIS: Merge machine dependent boot/compressed ..")
Signed-off-by: Guenter Roeck
Signed-off-by: Jesper Nilsson
Signed-off-by: Greg Kroah-Hartman -
commit 0cff18cbab4f55581d9da86e4286655d9723d7d2 upstream.
The 2 USB host ports are directly tied to the 2 USB hosts in the SoC.
The 2 host pairs were already enabled, but the USB PHY wasn't.
VBUS on the 2 ports are always on.Enable the USB PHY.
Fixes: 04c85ecad32a ("ARM: dts: sun7i: Add dts file for Bananapi M1 Plus
board")
Signed-off-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
Signed-off-by: Greg Kroah-Hartman -
commit 4d75a171b67ffc3f4dadbd654c9d281091300eb2 upstream.
The ohci/ehci hardware pin number should be 640/641, correct them.
Fixes: commit aa8d3e74f54d ("arm64: dts: Add initial dts for Hisilicon Hip06 D03 board")
Signed-off-by: Kefeng Wang
Signed-off-by: Wei Xu
Signed-off-by: Greg Kroah-Hartman -
commit dc8ee9dbdba509fb58e23ba79f2e6059fe5d8b3b upstream.
The parent clock of the HSUSB clock is the HP clock, not the MP clock.
Fixes: c7bab9f929e51761 ("ARM: shmobile: r8a7794: Add USB clocks to device tree")
Signed-off-by: Geert Uytterhoeven
Acked-by: Yoshihiro Shimoda
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman -
commit 32eb12a6c11034867401d56b012e3c15d5f8141e upstream.
Flush the KVM entry code from the icache on all CPUs, not just the one
that built the entry code.Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Radim Krčmář
Signed-off-by: Greg Kroah-Hartman -
commit 4c881451d3017033597ea186cf79ae41a73e1ef8 upstream.
On 64-bit kernels, MIPS KVM will clear CP0_Status.UX to prevent the
guest (running in user mode) from accessing the 64-bit memory segments.
However the previous value of CP0_Status.UX is never restored when
exiting from the guest.If the user process uses 64-bit addressing (the n64 ABI) this can result
in address error exceptions from the kernel if it needs to deliver a
signal before returning to user mode, as the kernel will need to write a
sigframe to high user addresses on the user stack which are disallowed
by CP0_Status.UX=0.This is fixed by explicitly setting SX and UX again when exiting from
the guest, and explicitly clearing those bits when returning to the
guest. Having the SX and UX bits set when handling guest exits (rather
than only when exiting to userland) will be helpful when we support VZ,
since we shouldn't need to directly read or write guest memory, so it
will be valid for cache management IPIs to access host user addresses.Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Radim Krčmář
Signed-off-by: Greg Kroah-Hartman -
commit 6ef4e07ecd2db21025c446327ecf34414366498b upstream.
Otherwise, mismatch between the smm bit in hflags and the MMU role
can cause a NULL pointer dereference.Signed-off-by: Xiao Guangrong
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit ef37427ac5677331145ab27a17e6f5f1b43f0c11 upstream.
Similarly to the aemif clock - this screws up the linked list of clock
children. Create a separate clock for mdio inheriting the rate from
emac_clk.Signed-off-by: Bartosz Golaszewski
[nsekhar@ti.com: add a comment over mdio_clk to explaing its existence +
commit headline updates]
Signed-off-by: Sekhar Nori
Signed-off-by: Greg Kroah-Hartman -
commit 41744213602a206f24adcb4a2b7551db3c700e72 upstream.
The cr16 interval timer of each CPU is not syncronized to other cr16
timers in other CPUs in a SMP system. So, delay the registration of the
cr16 clocksource until all CPUs have been detected and then - if we are
on a SMP machine - mark the cr16 clocksource as unstable and lower it's
rating before registering it at the clocksource framework.This patch fixes the stalled CPU warnings which we have seen since
introduction of the cr16 clocksource.Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
commit b4a9eb4cd5966c8aad3d007d206a2cbda97d6928 upstream.
Add a leading line break else printed line gets too long.
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
09 Jan, 2017
14 commits
-
commit ff45000fcb56b5b0f1a14a865d3541746d838a0a upstream.
The boot wrapper performs its own relocations and does not require
PT_INTERP segment. However currently we don't tell the linker that.Prior to binutils 2.28 that works OK. But since binutils commit
1a9ccd70f9a7 ("Fix the linker so that it will not silently generate ELF
binaries with invalid program headers. Fix readelf to report such
invalid binaries.") binutils tries to create a program header segment
due to PT_INTERP, and the link fails because there is no space for it:ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, try linking with -N
ld: final link failed: Bad valueSo tell the linker not to do that, by passing --no-dynamic-linker.
Reported-by: Anton Blanchard
Signed-off-by: Nicholas Piggin
[mpe: Drop dependency on ld-version.sh and massage change log]
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 upstream.
GCC 5 generates different code for this bootwrapper null check that
causes the PS3 to hang very early in its bootup. This check is of
limited value, so just get rid of it.Signed-off-by: Geoff Levand
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit f87f253bac3ce4a4eb2a60a1ae604d74e65f9042 upstream.
From 80f23935cadb ("powerpc: Convert cmp to cmpd in idle enter sequence"):
PowerPC's "cmp" instruction has four operands. Normally people write
"cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
people forget, and write "cmp" with just three operands.With older binutils this is silently accepted as if this was "cmpw",
while often "cmpd" is wanted. With newer binutils GAS will complain
about this for 64-bit code. For 32-bit code it still silently assumes
"cmpw" is what is meant.In this case, cmpwi is called for, so this is just a build fix for
new toolchains.Signed-off-by: Nicholas Piggin
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 9d85eb9119f4eeeb48e87adfcd71f752655700e9 upstream.
The logical package management has several issues:
- The APIC ids provided by ACPI are not required to be the same as the
initial APIC id which can be retrieved by CPUID. The APIC ids provided
by ACPI are those which are written by the BIOS into the APIC. The
initial id is set by hardware and can not be changed. The hardware
provided ids contain the real hardware package information.Especially AMD sets the effective APIC id different from the hardware id
as they need to reserve space for the IOAPIC ids starting at id 0.As a consequence those machines trigger the currently active firmware
bug printouts in dmesg, These are obviously wrong.- Virtual machines have their own interesting of enumerating APICs and
packages which are not reliably covered by the current implementation.The sizing of the mapping array has been tweaked to be generously large to
handle systems which provide a wrong core count when HT is disabled so the
whole magic which checks for space in the physical hotplug case is not
needed anymore.Simplify the whole machinery and do the mapping when the CPU starts and the
CPUID derived physical package information is available. This solves the
observed problems on AMD machines and works for the virtualization issues
as well.Remove the extra call from XEN cpu bringup code as it is not longer
required.Fixes: d49597fd3bc7 ("x86/cpu: Deal with broken firmware (VMWare/XEN)")
Reported-and-tested-by: Borislav Petkov
Tested-by: Boris Ostrovsky
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: Peter Zijlstra
Cc: M. Vefa Bicakci
Cc: xen-devel
Cc: Charles (Chas) Williams
Cc: Borislav Petkov
Cc: Alok Kataria
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1612121102260.3429@nanos
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 upstream.
With new binutils, gcc may get smart with its optimization and change a jmp
from a 5 byte jump to a 2 byte one even though it was jumping to a global
function. But that global function existed within a 2 byte radius, and gcc
was able to optimize it. Unfortunately, that jump was also being modified
when function graph tracing begins. Since ftrace expected that jump to be 5
bytes, but it was only two, it overwrote code after the jump, causing a
crash.This was fixed for x86_64 with commit 8329e818f149, with the same subject as
this commit, but nothing was done for x86_32.Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls")
Reported-by: Colin Ian King
Tested-by: Colin Ian King
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit ef85b67385436ddc1998f45f1d6a210f935b3388 upstream.
When L2 exits to L0 due to "exception or NMI", software exceptions
(#BP and #OF) for which L1 has requested an intercept should be
handled by L1 rather than L0. Previously, only hardware exceptions
were forwarded to L1.Signed-off-by: Jim Mattson
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit f064a0de1579fabded8990bed93971e30deb9ecb upstream.
The hashed page table MMU in POWER processors can update the R
(reference) and C (change) bits in a HPTE at any time until the
HPTE has been invalidated and the TLB invalidation sequence has
completed. In kvmppc_h_protect, which implements the H_PROTECT
hypercall, we read the HPTE, modify the second doubleword,
invalidate the HPTE in memory, do the TLB invalidation sequence,
and then write the modified value of the second doubleword back
to memory. In doing so we could overwrite an R/C bit update done
by hardware between when we read the HPTE and when the TLB
invalidation completed. To fix this we re-read the second
doubleword after the TLB invalidation and OR in the (possibly)
new values of R and C. We can use an OR since hardware only ever
sets R and C, never clears them.This race was found by code inspection. In principle this bug could
cause occasional guest memory corruption under host memory pressure.Fixes: a8606e20e41a ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29)
Signed-off-by: Paul Mackerras
Signed-off-by: Greg Kroah-Hartman -
commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 upstream.
When switching from/to a guest that has a transaction in progress,
we need to save/restore the checkpointed register state. Although
XER is part of the CPU state that gets checkpointed, the code that
does this saving and restoring doesn't save/restore XER.This fixes it by saving and restoring the XER. To allow userspace
to read/write the checkpointed XER value, we also add a new ONE_REG
specifier.The visible effect of this bug is that the guest may see its XER
value being corrupted when it uses transactions.Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support")
Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit")
Signed-off-by: Paul Mackerras
Reviewed-by: Thomas Huth
Signed-off-by: Paul Mackerras
Signed-off-by: Greg Kroah-Hartman -
commit 21cbe3cc8a48ff17059912e019fbde28ed54745a upstream.
The ARMv8 architecture allows the cycle counter to be configured
by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0,
hence accessing PMCCFILTR_EL0. But it disallows the use of
PMSELR_EL0.SEL==0x1f to access the cycle counter itself through
PMXEVCNTR_EL0.Linux itself doesn't violate this rule, but we may end up with
PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that
guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1,
despite the guest not having done anything wrong.In order to avoid this unfortunate course of events (haha!), let's
sanitize PMSELR_EL0 on guest entry. This ensures that the guest
won't explode unexpectedly.Acked-by: Will Deacon
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman -
commit 9f88eb4df728aebcd2ddd154d99f1d75b428b897 upstream.
When re-adding crash kernel memory within setup_resources() the
function memblock_add() is used. That function will add memory by
default to node "MAX_NUMNODES" instead of node 0, like the memory
detection code does. In case of !NUMA this will trigger this warning
when the kernel generates the vmemmap:Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead
WARNING: CPU: 0 PID: 0 at mm/memblock.c:1261 memblock_virt_alloc_internal+0x76/0x220
CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc6 #16
Call Trace:
[] memblock_virt_alloc_try_nid+0x88/0xc8
[] __earlyonly_bootmem_alloc.constprop.1+0x42/0x50
[] vmemmap_populate+0x1ac/0x1e0
[] sparse_mem_map_populate+0x46/0x68
[] sparse_init+0x184/0x238
[] paging_init+0xbe/0xf8
[] setup_arch+0xa02/0xae0
[] start_kernel+0x72/0x450
[] _stext+0x20/0x80If NUMA is selected numa_setup_memory() will fix the node assignments
before the vmemmap will be populated; so this warning will only appear
if NUMA is not selected.To fix this simply use memblock_add_node() and re-add crash kernel
memory explicitly to node 0.Reported-and-tested-by: Christian Borntraeger
Fixes: 4e042af463f8 ("s390/kexec: fix crash on resize of reserved memory")
Signed-off-by: Heiko Carstens
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit 08fe007968b2b45e831daf74899f79a54d73f773 upstream.
An ARC700 customer reported linux boot crashes when upgrading to bigger
L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and
current code only assumed 2 colours, while theirs had 4. So default to 4
colours and complain if there are fewer. Ideally this needs to be a
Kconfig option, but heck that's too much of hassle for a single user.Signed-off-by: Vineet Gupta
Signed-off-by: Greg Kroah-Hartman -
commit 5e6b9a89afceadb1ee45472098f7d20af260335c upstream.
Add the VDD_GPU regulator (a GPIO-enabled PWM regulator) to the Jetson
TX1 board. This addition allows the GPU to be used provided the
bootloader properly enabled the GPU node.Signed-off-by: Alexandre Courbot
Signed-off-by: Thierry Reding
[as pointed out by Thierry on IRC, nobody has reported a bug
in the field, but using a new bootloader with a .dtb that
has the incorrect data, it will crash on boot]
Fixes: 336f79c7b6d7 ("arm64: tegra: Add NVIDIA Jetson TX1 Developer Kit support")
Signed-off-by: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman -
commit 834fcd298003c10ce450e66960c78893cb1cc4b5 upstream.
If the pmu registration fails the registered hotplug callbacks are not
removed. Wrong in any case, but fatal in case of a modular driver.Replace the nonsensical state names with proper ones while at it.
Fixes: 77c34ef1c319 ("perf/x86/intel/cstate: Convert Intel CSTATE to hotplug state machine")
Signed-off-by: Thomas Gleixner
Cc: Sebastian Siewior
Cc: Peter Zijlstra
Signed-off-by: Greg Kroah-Hartman -
commit b0c1ef52959582144bbea9a2b37db7f4c9e399f7 upstream.
An earlier patch allowed enabling PT and LBR at the same
time on Goldmont. However it also allowed enabling BTS and LBR
at the same time, which is still not supported. Fix this by
bypassing the check only for PT.Signed-off-by: Andi Kleen
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: alexander.shishkin@intel.com
Cc: kan.liang@intel.com
Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it")
Link: http://lkml.kernel.org/r/20161209001417.4713-1-andi@firstfloor.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
06 Jan, 2017
3 commits
-
commit 334bb773876403eae3457d81be0b8ea70f8e4ccc upstream.
Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
modversion support for symbols exported from asm files. Architectures
must include C-style declarations for those symbols in asm/asm-prototypes.h
in order for them to be versioned.Add these declarations for x86, and an architecture-independent file that
can be used for common symbols.With f27c2f6 reverting 8ab2ae6 ("default exported asm symbols to zero") we
produce a scary warning on x86, this commit fixes that.Signed-off-by: Adam Borowski
Tested-by: Kalle Valo
Acked-by: Nicholas Piggin
Tested-by: Peter Wu
Tested-by: Oliver Hartkopp
Signed-off-by: Michal Marek
Signed-off-by: Greg Kroah-Hartman -
commit 24d5373dda7c00a438d26016bce140299fae675e upstream.
The function xen_guest_init is using __alloc_percpu with an alignment
which are not power of two.However, the percpu allocator never supported alignments which are not power
of two and has always behaved incorectly in thise case.Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
introduced a check which trigger a warning [1] when booting linux-next
on Xen. But in reality this bug was always present.This can be fixed by replacing the call to __alloc_percpu with
alloc_percpu. The latter will use an alignment which are a power of two.[1]
[ 0.023921] illegal size (48) or align (48) for percpu allocation
[ 0.024167] ------------[ cut here ]------------
[ 0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
[ 0.024584] Modules linked in:
[ 0.024708]
[ 0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.9.0-rc7-next-20161128 #473
[ 0.025012] Hardware name: Foundation-v8A (DT)
[ 0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
[ 0.025351] PC is at pcpu_alloc+0x88/0x6c0
[ 0.025490] LR is at pcpu_alloc+0x88/0x6c0
[ 0.025624] pc : [] lr : []
pstate: 60000045
[ 0.025830] sp : ffff80003d847cd0
[ 0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
[ 0.026147] x27: 0000000000000000 x26: 0000000000000000
[ 0.026348] x25: 0000000000000000 x24: 0000000000000000
[ 0.026549] x23: 0000000000000000 x22: 00000000024000c0
[ 0.026752] x21: ffff000008e97000 x20: 0000000000000000
[ 0.026953] x19: 0000000000000030 x18: 0000000000000010
[ 0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
[ 0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
[ 0.027573] x13: ffff000008f79c4d x12: 0000000000000041
[ 0.027782] x11: 0000000000000006 x10: 0000000000000042
[ 0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
[ 0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
[ 0.028419] x5 : 0000000000000005 x4 : 0000000000000000
[ 0.028628] x3 : 0000000000000000 x2 : 000000000000017f
[ 0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
[ 0.029056]
[ 0.029152] ---[ end trace 0000000000000000 ]---
[ 0.029297] Call trace:
[ 0.029403] Exception stack(0xffff80003d847b00 to
0xffff80003d847c30)
[ 0.029621] 7b00: 0000000000000030 0001000000000000
ffff80003d847cd0 ffff00000818e678
[ 0.029901] 7b20: 0000000000000002 0000000000000004
ffff000008f7c060 0000000000000035
[ 0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
ffff80003d847bf0 ffff000008101778
[ 0.030402] 7b60: 0000000000000030 0000000000000000
ffff000008e97000 00000000024000c0
[ 0.030647] 7b80: 0000000000000000 0000000000000000
0000000000000000 0000000000000000
[ 0.030895] 7ba0: 0000000000000035 ffff80003d870000
000000000000017f 0000000000000000
[ 0.031144] 7bc0: 0000000000000000 0000000000000005
ffff000008f79c84 6120757063726570
[ 0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
0000000000000042 0000000000000006
[ 0.031643] 7c00: 0000000000000041 ffff000008f79c4d
ffff000088f79c3f 0000000000000006
[ 0.031877] 7c20: 00000000deadbeef 0000000000000a3f
[ 0.032051] [] pcpu_alloc+0x88/0x6c0
[ 0.032229] [] __alloc_percpu+0x18/0x20
[ 0.032409] [] xen_guest_init+0x174/0x2f4
[ 0.032591] [] do_one_initcall+0x38/0x130
[ 0.032783] [] kernel_init_freeable+0xe0/0x248
[ 0.032995] [] kernel_init+0x10/0x100
[ 0.033172] [] ret_from_fork+0x10/0x50Reported-by: Wei Chen
Link: https://lkml.org/lkml/2016/11/28/669
Signed-off-by: Julien Grall
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
Signed-off-by: Greg Kroah-Hartman -
commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3 upstream.
It is the reasonable expectation that if an executable file is not
readable there will be no way for a user without special privileges to
read the file. This is enforced in ptrace_attach but if ptrace
is already attached before exec there is no enforcement for read-only
executables.As the only way to read such an mm is through access_process_vm
spin a variant called ptrace_access_vm that will fail if the
target process is not being ptraced by the current process, or
the current process did not have sufficient privileges when ptracing
began to read the target processes mm.In the ptrace implementations replace access_process_vm by
ptrace_access_vm. There remain several ptrace sites that still use
access_process_vm as they are reading the target executables
instructions (for kernel consumption) or register stacks. As such it
does not appear necessary to add a permission check to those calls.This bug has always existed in Linux.
Fixes: v1.0
Reported-by: Andy Lutomirski
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman
