linux.git/arch, branch v4.4.57

powerpc/boot: Fix zImage TOC alignment

2017-03-26T10:13:19+00:00

commit 97ee351b50a49717543533cfb85b4bf9d88c9680 upstream.

Recent toolchains force the TOC to be 256 byte aligned. We need to
enforce this alignment in the zImage linker script, otherwise pointers
to our TOC variables (__toc_start) could be incorrect. If the actual
start of the TOC and __toc_start don't have the same value we crash
early in the zImage wrapper.

Suggested-by: Alan Modra 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

s390/pci: fix use after free in dma_init

2017-03-26T10:13:18+00:00

commit dba599091c191d209b1499511a524ad9657c0e5a upstream.

After a failure during registration of the dma_table (because of the
function being in error state) we free its memory but don't reset the
associated pointer to zero.

When we then receive a notification from firmware (about the function
being in error state) we'll try to walk and free the dma_table again.

Fix this by resetting the dma_table pointer. In addition to that make
sure that we free the iommu_bitmap when appropriate.

Signed-off-by: Sebastian Ott 
Reviewed-by: Gerald Schaefer 
Signed-off-by: Martin Schwidefsky 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

KVM: PPC: Book3S PR: Fix illegal opcode emulation

2017-03-26T10:13:18+00:00

commit 708e75a3ee750dce1072134e630d66c4e6eaf63c upstream.

If kvmppc_handle_exit_pr() calls kvmppc_emulate_instruction() to emulate
one instruction (in the BOOK3S_INTERRUPT_H_EMUL_ASSIST case), it calls
kvmppc_core_queue_program() afterwards if kvmppc_emulate_instruction()
returned EMULATE_FAIL, so the guest gets an program interrupt for the
illegal opcode.
However, the kvmppc_emulate_instruction() also tried to inject a
program exception for this already, so the program interrupt gets
injected twice and the return address in srr0 gets destroyed.
All other callers of kvmppc_emulate_instruction() are also injecting
a program interrupt, and since the callers have the right knowledge
about the srr1 flags that should be used, it is the function
kvmppc_emulate_instruction() that should _not_ inject program
interrupts, so remove the kvmppc_core_queue_program() here.

This fixes the issue discovered by Laurent Vivier with kvm-unit-tests
where the logs are filled with these messages when the test tries
to execute an illegal instruction:

     Couldn't emulate instruction 0x00000000 (op 0 xop 0)
     kvmppc_handle_exit_pr: emulation at 700 failed (00000000)

Signed-off-by: Thomas Huth 
Reviewed-by: Alexander Graf 
Tested-by: Laurent Vivier 
Signed-off-by: Paul Mackerras 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

xen/qspinlock: Don't kick CPU if IRQ is not initialized

2017-03-26T10:13:18+00:00

commit 707e59ba494372a90d245f18b0c78982caa88e48 upstream.

The following commit:

  1fb3a8b2cfb2 ("xen/spinlock: Fix locking path engaging too soon under PVHVM.")

... moved the initalization of the kicker interrupt until after
native_cpu_up() is called.

However, when using qspinlocks, a CPU may try to kick another CPU that is
spinning (because it has not yet initialized its kicker interrupt), resulting
in the following crash during boot:

  kernel BUG at /build/linux-Ay7j_C/linux-4.4.0/drivers/xen/events/events_base.c:1210!
  invalid opcode: 0000 [#1] SMP
  ...
  RIP: 0010:[]  [] xen_send_IPI_one+0x59/0x60
  ...
  Call Trace:
   [] xen_qlock_kick+0xe/0x10
   [] __pv_queued_spin_unlock+0xb2/0xf0
   [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
   [] ? check_tsc_warp+0x76/0x150
   [] check_tsc_sync_source+0x96/0x160
   [] native_cpu_up+0x3d8/0x9f0
   [] xen_hvm_cpu_up+0x35/0x80
   [] _cpu_up+0x13c/0x180
   [] cpu_up+0x7a/0xa0
   [] smp_init+0x7f/0x81
   [] kernel_init_freeable+0xef/0x212
   [] ? rest_init+0x80/0x80
   [] kernel_init+0xe/0xe0
   [] ret_from_fork+0x3f/0x70
   [] ? rest_init+0x80/0x80

To fix this, only send the kick if the target CPU's interrupt has been
initialized. This check isn't racy, because the target is waiting for
the spinlock, so it won't have initialized the interrupt in the
meantime.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Boris Ostrovsky 
Cc: David Vrabel 
Cc: Juergen Gross 
Cc: Konrad Rzeszutek Wilk 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Ingo Molnar 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

crypto: ghash-clmulni - Fix load failure

2017-03-26T10:13:17+00:00

commit 3a020a723c65eb8ffa7c237faca26521a024e582 upstream.

ghash_clmulni_intel fails to load on Linux 4.3+ with the following message:
"modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument"

After 8996eafdc ("crypto: ahash - ensure statesize is non-zero") all ahash
drivers are required to implement import()/export(), and must have a non-
zero statesize.

This patch has been tested with the algif_hash interface. The calculated
digest values, after several rounds of import()s and export()s, match those
calculated by tcrypt.

Signed-off-by: Rui Wang 
Signed-off-by: Herbert Xu 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

x86/perf: Fix CR4.PCE propagation to use active_mm instead of mm

2017-03-22T11:04:18+00:00

commit 5dc855d44c2ad960a86f593c60461f1ae1566b6d upstream.

If one thread mmaps a perf event while another thread in the same mm
is in some context where active_mm != mm (which can happen in the
scheduler, for example), refresh_pce() would write the wrong value
to CR4.PCE.  This broke some PAPI tests.

Reported-and-tested-by: Vince Weaver 
Signed-off-by: Andy Lutomirski 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: stable@vger.kernel.org
Fixes: 7911d3f7af14 ("perf/x86: Only allow rdpmc if a perf_event is mapped")
Link: http://lkml.kernel.org/r/0c5b38a76ea50e405f9abe07a13dfaef87c173a1.1489694270.git.luto@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/kasan: Fix boot with KASAN=y and PROFILE_ANNOTATED_BRANCHES=y

2017-03-22T11:04:18+00:00

commit be3606ff739d1c1be36389f8737c577ad87e1f57 upstream.

The kernel doesn't boot with both PROFILE_ANNOTATED_BRANCHES=y and KASAN=y
options selected. With branch profiling enabled we end up calling
ftrace_likely_update() before kasan_early_init(). ftrace_likely_update() is
built with KASAN instrumentation, so calling it before kasan has been
initialized leads to crash.

Use DISABLE_BRANCH_PROFILING define to make sure that we don't call
ftrace_likely_update() from early code before kasan_early_init().

Fixes: ef7f0d6a6ca8 ("x86_64: add KASan support")
Reported-by: Fengguang Wu 
Signed-off-by: Andrey Ryabinin 
Cc: kasan-dev@googlegroups.com
Cc: Alexander Potapenko 
Cc: Andrew Morton 
Cc: lkp@01.org
Cc: Dmitry Vyukov 
Link: http://lkml.kernel.org/r/20170313163337.1704-1-aryabinin@virtuozzo.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

s390/kdump: Use "LINUX" ELF note name instead of "CORE"

2017-03-18T11:09:58+00:00

commit a4a81d8eebdc1d209d034f62a082a5131e4242b5 upstream.

In binutils/libbfd (bfd/elf.c) it is enforced that all s390 specific ELF
notes like e.g. NT_S390_PREFIX or NT_S390_CTRS have "LINUX" specified
as note name. Otherwise the notes are ignored.

For /proc/vmcore we currently use "CORE" for these notes.

Up to now this has not been a real problem because the dump analysis tool
"crash" does not check the note name. But it will break all programs that
use libbfd for processing ELF notes.

So fix this and use "LINUX" for all s390 specific notes to comply with
libbfd.

Reported-by: Philipp Rudo 
Reviewed-by: Philipp Rudo 
Signed-off-by: Michael Holzheu 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

KVM: s390: Fix guest migration for huge guests resulting in panic

2017-03-18T11:09:58+00:00

commit 2e4d88009f57057df7672fa69a32b5224af54d37 upstream.

While we can technically not run huge page guests right now, we can
setup a guest with huge pages. Trying to migrate it will trigger a
VM_BUG_ON and, if the kernel is not configured to panic on a BUG, it
will happily try to work on non-existing page table entries.

With this patch, we always return "dirty" if we encounter a large page
when migrating. This at least fixes the immediate problem until we
have proper handling for both kind of pages.

Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
Cc:  # 3.16+

Signed-off-by: Janosch Frank 
Acked-by: Christian Borntraeger 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

powerpc: Emulation support for load/store instructions on LE

2017-03-18T11:09:57+00:00

commit e148bd17f48bd17fca2f4f089ec879fa6e47e34c upstream.

emulate_step() uses a number of underlying kernel functions that were
initially not enabled for LE. This has been rectified since. So, fix
emulate_step() for LE for the corresponding instructions.

Reported-by: Anton Blanchard 
Signed-off-by: Ravi Bangoria 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman