1. 20 Dec, 2018 1 commit
  2. 17 Dec, 2018 6 commits
    • Yi Wang's avatar
      x86/kvm/vmx: fix old-style function declaration · 0c4d57aa
      Yi Wang authored
      [ Upstream commit 1e4329ee2c52692ea42cc677fb2133519718b34a ]
      
      The inline keyword which is not at the beginning of the function
      declaration may trigger the following build warnings, so let's fix it:
      
      arch/x86/kvm/vmx.c:1309:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      arch/x86/kvm/vmx.c:5947:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      arch/x86/kvm/vmx.c:5985:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      arch/x86/kvm/vmx.c:6023:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
      Signed-off-by: 's avatarYi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      0c4d57aa
    • Yi Wang's avatar
      KVM: x86: fix empty-body warnings · eadd5357
      Yi Wang authored
      [ Upstream commit 354cb410d87314e2eda344feea84809e4261570a ]
      
      We get the following warnings about empty statements when building
      with 'W=1':
      
      arch/x86/kvm/lapic.c:632:53: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      arch/x86/kvm/lapic.c:1907:42: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      arch/x86/kvm/lapic.c:1936:65: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      arch/x86/kvm/lapic.c:1975:44: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
      
      Rework the debug helper macro to get rid of these warnings.
      Signed-off-by: 's avatarYi Wang <wang.yi59@zte.com.cn>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      eadd5357
    • Thomas Richter's avatar
      s390/cpum_cf: Reject request for sampling in event initialization · 696c3ede
      Thomas Richter authored
      [ Upstream commit 613a41b0d16e617f46776a93b975a1eeea96417c ]
      
      On s390 command perf top fails
      [root@s35lp76 perf] # ./perf top -F100000  --stdio
         Error:
         cycles: PMU Hardware doesn't support sampling/overflow-interrupts.
         	Try 'perf stat'
      [root@s35lp76 perf] #
      
      Using event -e rb0000 works as designed.  Event rb0000 is the event
      number of the sampling facility for basic sampling.
      
      During system start up the following PMUs are installed in the kernel's
      PMU list (from head to tail):
         cpum_cf --> s390 PMU counter facility device driver
         cpum_sf --> s390 PMU sampling facility device driver
         uprobe
         kprobe
         tracepoint
         task_clock
         cpu_clock
      
      Perf top executes following functions and calls perf_event_open(2) system
      call with different parameters many times:
      
      cmd_top
      --> __cmd_top
          --> perf_evlist__add_default
              --> __perf_evlist__add_default
                  --> perf_evlist__new_cycles (creates event type:0 (HW)
      			    		config 0 (CPU_CYCLES)
      	        --> perf_event_attr__set_max_precise_ip
      		    Uses perf_event_open(2) to detect correct
      		    precise_ip level. Fails 3 times on s390 which is ok.
      
      Then functions cmd_top
      --> __cmd_top
          --> perf_top__start_counters
              -->perf_evlist__config
      	   --> perf_can_comm_exec
                     --> perf_probe_api
      	           This functions test support for the following events:
      		   "cycles:u", "instructions:u", "cpu-clock:u" using
      		   --> perf_do_probe_api
      		       --> perf_event_open_cloexec
      		           Test the close on exec flag support with
      			   perf_event_open(2).
      	               perf_do_probe_api returns true if the event is
      		       supported.
      		       The function returns true because event cpu-clock is
      		       supported by the PMU cpu_clock.
      	               This is achieved by many calls to perf_event_open(2).
      
      Function perf_top__start_counters now calls perf_evsel__open() for every
      event, which is the default event cpu_cycles (config:0) and type HARDWARE
      (type:0) which a predfined frequence of 4000.
      
      Given the above order of the PMU list, the PMU cpum_cf gets called first
      and returns 0, which indicates support for this sampling. The event is
      fully allocated in the function perf_event_open (file kernel/event/core.c
      near line 10521 and the following check fails:
      
              event = perf_event_alloc(&attr, cpu, task, group_leader, NULL,
      		                 NULL, NULL, cgroup_fd);
      	if (IS_ERR(event)) {
      		err = PTR_ERR(event);
      		goto err_cred;
      	}
      
              if (is_sampling_event(event)) {
      		if (event->pmu->capabilities & PERF_PMU_CAP_NO_INTERRUPT) {
      			err = -EOPNOTSUPP;
      			goto err_alloc;
      		}
      	}
      
      The check for the interrupt capabilities fails and the system call
      perf_event_open() returns -EOPNOTSUPP (-95).
      
      Add a check to return -ENODEV when sampling is requested in PMU cpum_cf.
      This allows common kernel code in the perf_event_open() system call to
      test the next PMU in above list.
      
      Fixes: 97b1198f (" "s390, perf: Use common PMU interrupt disabled code")
      Signed-off-by: 's avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: 's avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Signed-off-by: 's avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      696c3ede
    • Janusz Krzysztofik's avatar
      ARM: OMAP1: ams-delta: Fix possible use of uninitialized field · e0242093
      Janusz Krzysztofik authored
      [ Upstream commit cec83ff1241ec98113a19385ea9e9cfa9aa4125b ]
      
      While playing with initialization order of modem device, it has been
      discovered that under some circumstances (early console init, I
      believe) its .pm() callback may be called before the
      uart_port->private_data pointer is initialized from
      plat_serial8250_port->private_data, resulting in NULL pointer
      dereference.  Fix it by checking for uninitialized pointer before using
      it in modem_pm().
      
      Fixes: aabf3173 ("ARM: OMAP1: ams-delta: update the modem to use regulator API")
      Signed-off-by: 's avatarJanusz Krzysztofik <jmkrzyszt@gmail.com>
      Signed-off-by: 's avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      e0242093
    • Adam Ford's avatar
      ARM: dts: logicpd-somlv: Fix interrupt on mmc3_dat1 · 2e6ef7e3
      Adam Ford authored
      [ Upstream commit 3d8b804bc528d3720ec0c39c212af92dafaf6e84 ]
      
      The interrupt on mmc3_dat1 is wrong which prevents this from
      appearing in /proc/interrupts.
      
      Fixes: ab8dd3ae ("ARM: DTS: Add minimal Support for Logic PD
      DM3730 SOM-LV") #Kernel 4.9+
      Signed-off-by: 's avatarAdam Ford <aford173@gmail.com>
      Signed-off-by: 's avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      2e6ef7e3
    • Nathan Chancellor's avatar
      ARM: OMAP2+: prm44xx: Fix section annotation on omap44xx_prm_enable_io_wakeup · e6b4f360
      Nathan Chancellor authored
      [ Upstream commit eef3dc34a1e0b01d53328b88c25237bcc7323777 ]
      
      When building the kernel with Clang, the following section mismatch
      warning appears:
      
      WARNING: vmlinux.o(.text+0x38b3c): Section mismatch in reference from
      the function omap44xx_prm_late_init() to the function
      .init.text:omap44xx_prm_enable_io_wakeup()
      The function omap44xx_prm_late_init() references
      the function __init omap44xx_prm_enable_io_wakeup().
      This is often because omap44xx_prm_late_init lacks a __init
      annotation or the annotation of omap44xx_prm_enable_io_wakeup is wrong.
      
      Remove the __init annotation from omap44xx_prm_enable_io_wakeup so there
      is no more mismatch.
      Signed-off-by: 's avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: 's avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      e6b4f360
  3. 13 Dec, 2018 1 commit
  4. 08 Dec, 2018 6 commits
  5. 05 Dec, 2018 10 commits
    • Stefan Agner's avatar
      ARM: trusted_foundations: do not use naked function · 1e5b5cb7
      Stefan Agner authored
      (commit 4ea7bdc6b5b33427bbd3f41c333e21c1825462a3 upstream)
      
      As documented in GCC naked functions should only use basic ASM
      syntax. The extended ASM or mixture of basic ASM and "C" code is
      not guaranteed. Currently this works because it was hard coded
      to follow and check GCC behavior for arguments and register
      placement.
      
      Furthermore with clang using parameters in Extended asm in a
      naked function is not supported:
        arch/arm/firmware/trusted_foundations.c:47:10: error: parameter
                references not allowed in naked functions
                      : "r" (type), "r" (arg1), "r" (arg2)
                             ^
      
      Use a regular function to be more portable. This aligns also with
      the other SMC call implementations e.g. in qcom_scm-32.c and
      bcm_kona_smc.c.
      
      Cc: Dmitry Osipenko <digetx@gmail.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Thierry Reding <treding@nvidia.com>
      Signed-off-by: 's avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e5b5cb7
    • Stefan Agner's avatar
      ARM: 8767/1: add support for building ARM kernel with clang · 10479075
      Stefan Agner authored
      (commit c1c386681bd73c4fc28eb5cc91cf8b7be9b409ba upstream)
      
      Use cc-options call for compiler options which are not available
      in clang. With this patch an ARMv7 multi platform kernel can be
      successfully build using clang (tested with version 5.0.1).
      Based-on-patches-by: 's avatarBehan Webster <behanw@converseincode.com>
      Signed-off-by: 's avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: 's avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10479075
    • Stefan Agner's avatar
      ARM: 8766/1: drop no-thumb-interwork in EABI mode · 61cc8587
      Stefan Agner authored
      (commit 22905a24306c8c312c2d66da9f90d09af0414f81 upstream)
      
      According to GCC documentation -m(no-)thumb-interwork is
      meaningless in AAPCS configurations. Also clang does not
      support the flag:
        clang-5.0: error: unknown argument: '-mno-thumb-interwork'
      
      Just drop -mno-thumb-interwork in AEABI configuration.
      Signed-off-by: 's avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: 's avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61cc8587
    • Jiri Olsa's avatar
      perf/x86/intel: Add generic branch tracing check to intel_pmu_has_bts() · 54f73829
      Jiri Olsa authored
      commit 67266c1080ad56c31af72b9c18355fde8ccc124a upstream.
      
      Currently we check the branch tracing only by checking for the
      PERF_COUNT_HW_BRANCH_INSTRUCTIONS event of PERF_TYPE_HARDWARE
      type. But we can define the same event with the PERF_TYPE_RAW
      type.
      
      Changing the intel_pmu_has_bts() code to check on event's final
      hw config value, so both HW types are covered.
      
      Adding unlikely to intel_pmu_has_bts() condition calls, because
      it was used in the original code in intel_bts_constraints.
      Signed-off-by: 's avatarJiri Olsa <jolsa@kernel.org>
      Acked-by: 's avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: <stable@vger.kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/20181121101612.16272-2-jolsa@kernel.orgSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54f73829
    • Jiri Olsa's avatar
      perf/x86/intel: Move branch tracing setup to the Intel-specific source file · 08c133e8
      Jiri Olsa authored
      commit ed6101bbf6266ee83e620b19faa7c6ad56bb41ab upstream.
      
      Moving branch tracing setup to Intel core object into separate
      intel_pmu_bts_config function, because it's Intel specific.
      Suggested-by: 's avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: 's avatarJiri Olsa <jolsa@kernel.org>
      Acked-by: 's avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: <stable@vger.kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/20181121101612.16272-1-jolsa@kernel.orgSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08c133e8
    • Max Filippov's avatar
      xtensa: fix coprocessor context offset definitions · f4038875
      Max Filippov authored
      commit 03bc996af0cc71c7f30c384d8ce7260172423b34 upstream.
      
      Coprocessor context offsets are used by the assembly code that moves
      coprocessor context between the individual fields of the
      thread_info::xtregs_cp structure and coprocessor registers.
      This fixes coprocessor context clobbering on flushing and reloading
      during normal user code execution and user process debugging in the
      presence of more than one coprocessor in the core configuration.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4038875
    • Max Filippov's avatar
      xtensa: enable coprocessors that are being flushed · c26e3c6c
      Max Filippov authored
      commit 2958b66694e018c552be0b60521fec27e8d12988 upstream.
      
      coprocessor_flush_all may be called from a context of a thread that is
      different from the thread being flushed. In that case contents of the
      cpenable special register may not match ti->cpenable of the target
      thread, resulting in unhandled coprocessor exception in the kernel
      context.
      Set cpenable special register to the ti->cpenable of the target register
      for the duration of the flush and restore it afterwards.
      This fixes the following crash caused by coprocessor register inspection
      in native gdb:
      
        (gdb) p/x $w0
        Illegal instruction in kernel: sig: 9 [#1] PREEMPT
        Call Trace:
          ___might_sleep+0x184/0x1a4
          __might_sleep+0x41/0xac
          exit_signals+0x14/0x218
          do_exit+0xc9/0x8b8
          die+0x99/0xa0
          do_illegal_instruction+0x18/0x6c
          common_exception+0x77/0x77
          coprocessor_flush+0x16/0x3c
          arch_ptrace+0x46c/0x674
          sys_ptrace+0x2ce/0x3b4
          system_call+0x54/0x80
          common_exception+0x77/0x77
        note: gdb[100] exited with preempt_count 1
        Killed
      
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c26e3c6c
    • Wanpeng Li's avatar
      KVM: X86: Fix scan ioapic use-before-initialization · 3a468e8e
      Wanpeng Li authored
      commit e97f852fd4561e77721bb9a4e0ea9d98305b1e93 upstream.
      
      Reported by syzkaller:
      
       BUG: unable to handle kernel NULL pointer dereference at 00000000000001c8
       PGD 80000003ec4da067 P4D 80000003ec4da067 PUD 3f7bfa067 PMD 0
       Oops: 0000 [#1] PREEMPT SMP PTI
       CPU: 7 PID: 5059 Comm: debug Tainted: G           OE     4.19.0-rc5 #16
       RIP: 0010:__lock_acquire+0x1a6/0x1990
       Call Trace:
        lock_acquire+0xdb/0x210
        _raw_spin_lock+0x38/0x70
        kvm_ioapic_scan_entry+0x3e/0x110 [kvm]
        vcpu_enter_guest+0x167e/0x1910 [kvm]
        kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
        kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
        do_vfs_ioctl+0xa5/0x690
        ksys_ioctl+0x6d/0x80
        __x64_sys_ioctl+0x1a/0x20
        do_syscall_64+0x83/0x6e0
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The reason is that the testcase writes hyperv synic HV_X64_MSR_SINT6 msr
      and triggers scan ioapic logic to load synic vectors into EOI exit bitmap.
      However, irqchip is not initialized by this simple testcase, ioapic/apic
      objects should not be accessed.
      This can be triggered by the following program:
      
          #define _GNU_SOURCE
      
          #include <endian.h>
          #include <stdint.h>
          #include <stdio.h>
          #include <stdlib.h>
          #include <string.h>
          #include <sys/syscall.h>
          #include <sys/types.h>
          #include <unistd.h>
      
          uint64_t r[3] = {0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff};
      
          int main(void)
          {
          	syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
          	long res = 0;
          	memcpy((void*)0x20000040, "/dev/kvm", 9);
          	res = syscall(__NR_openat, 0xffffffffffffff9c, 0x20000040, 0, 0);
          	if (res != -1)
          		r[0] = res;
          	res = syscall(__NR_ioctl, r[0], 0xae01, 0);
          	if (res != -1)
          		r[1] = res;
          	res = syscall(__NR_ioctl, r[1], 0xae41, 0);
          	if (res != -1)
          		r[2] = res;
          	memcpy(
          			(void*)0x20000080,
          			"\x01\x00\x00\x00\x00\x5b\x61\xbb\x96\x00\x00\x40\x00\x00\x00\x00\x01\x00"
          			"\x08\x00\x00\x00\x00\x00\x0b\x77\xd1\x78\x4d\xd8\x3a\xed\xb1\x5c\x2e\x43"
          			"\xaa\x43\x39\xd6\xff\xf5\xf0\xa8\x98\xf2\x3e\x37\x29\x89\xde\x88\xc6\x33"
          			"\xfc\x2a\xdb\xb7\xe1\x4c\xac\x28\x61\x7b\x9c\xa9\xbc\x0d\xa0\x63\xfe\xfe"
          			"\xe8\x75\xde\xdd\x19\x38\xdc\x34\xf5\xec\x05\xfd\xeb\x5d\xed\x2e\xaf\x22"
          			"\xfa\xab\xb7\xe4\x42\x67\xd0\xaf\x06\x1c\x6a\x35\x67\x10\x55\xcb",
          			106);
          	syscall(__NR_ioctl, r[2], 0x4008ae89, 0x20000080);
          	syscall(__NR_ioctl, r[2], 0xae80, 0);
          	return 0;
          }
      
      This patch fixes it by bailing out scan ioapic if ioapic is not initialized in
      kernel.
      Reported-by: 's avatarWei Wu <ww9210@gmail.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Wei Wu <ww9210@gmail.com>
      Signed-off-by: 's avatarWanpeng Li <wanpengli@tencent.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a468e8e
    • Jim Mattson's avatar
      kvm: svm: Ensure an IBPB on all affected CPUs when freeing a vmcb · 43dd9f48
      Jim Mattson authored
      commit fd65d3142f734bc4376053c8d75670041903134d upstream.
      
      Previously, we only called indirect_branch_prediction_barrier on the
      logical CPU that freed a vmcb. This function should be called on all
      logical CPUs that last loaded the vmcb in question.
      
      Fixes: 15d45071 ("KVM/x86: Add IBPB support")
      Reported-by: 's avatarNeel Natu <neelnatu@google.com>
      Signed-off-by: 's avatarJim Mattson <jmattson@google.com>
      Reviewed-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43dd9f48
    • Junaid Shahid's avatar
      kvm: mmu: Fix race in emulated page table writes · aa716434
      Junaid Shahid authored
      commit 0e0fee5c539b61fdd098332e0e2cc375d9073706 upstream.
      
      When a guest page table is updated via an emulated write,
      kvm_mmu_pte_write() is called to update the shadow PTE using the just
      written guest PTE value. But if two emulated guest PTE writes happened
      concurrently, it is possible that the guest PTE and the shadow PTE end
      up being out of sync. Emulated writes do not mark the shadow page as
      unsync-ed, so this inconsistency will not be resolved even by a guest TLB
      flush (unless the page was marked as unsync-ed at some other point).
      
      This is fixed by re-reading the current value of the guest PTE after the
      MMU lock has been acquired instead of just using the value that was
      written prior to calling kvm_mmu_pte_write().
      Signed-off-by: 's avatarJunaid Shahid <junaids@google.com>
      Reviewed-by: 's avatarWanpeng Li <wanpengli@tencent.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa716434
  6. 01 Dec, 2018 6 commits
    • Janosch Frank's avatar
      s390/mm: Check for valid vma before zapping in gmap_discard · 2188cf06
      Janosch Frank authored
      commit 1843abd03250115af6cec0892683e70cf2297c25 upstream.
      
      Userspace could have munmapped the area before doing unmapping from
      the gmap. This would leave us with a valid vmaddr, but an invalid vma
      from which we would try to zap memory.
      
      Let's check before using the vma.
      
      Fixes: 1e133ab2 ("s390/mm: split arch/s390/mm/pgtable.c")
      Signed-off-by: 's avatarJanosch Frank <frankja@linux.ibm.com>
      Reviewed-by: 's avatarDavid Hildenbrand <david@redhat.com>
      Reported-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Message-Id: <20180816082432.78828-1-frankja@linux.ibm.com>
      Signed-off-by: 's avatarJanosch Frank <frankja@linux.ibm.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      2188cf06
    • Greg Hackmann's avatar
      arm64: remove no-op -p linker flag · 27299117
      Greg Hackmann authored
      (commit 1a381d4a0a9a0f999a13faaba22bf6b3fc80dcb9 upstream)
      
      Linking the ARM64 defconfig kernel with LLVM lld fails with the error:
      
        ld.lld: error: unknown argument: -p
        Makefile:1015: recipe for target 'vmlinux' failed
      
      Without this flag, the ARM64 defconfig kernel successfully links with
      lld and boots on Dragonboard 410c.
      
      After digging through binutils source and changelogs, it turns out that
      -p is only relevant to ancient binutils installations targeting 32-bit
      ARM.  binutils accepts -p for AArch64 too, but it's always been
      undocumented and silently ignored.  A comment in
      ld/emultempl/aarch64elf.em explains that it's "Only here for backwards
      compatibility".
      
      Since this flag is a no-op on ARM64, we can safely drop it.
      Acked-by: 's avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: 's avatarGreg Hackmann <ghackmann@google.com>
      Signed-off-by: 's avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      27299117
    • Satheesh Rajendran's avatar
      powerpc/numa: Suppress "VPHN is not supported" messages · 636374c5
      Satheesh Rajendran authored
      [ Upstream commit 437ccdc8ce629470babdda1a7086e2f477048cbd ]
      
      When VPHN function is not supported and during cpu hotplug event,
      kernel prints message 'VPHN function not supported. Disabling
      polling...'. Currently it prints on every hotplug event, it floods
      dmesg when a KVM guest tries to hotplug huge number of vcpus, let's
      just print once and suppress further kernel prints.
      Signed-off-by: 's avatarSatheesh Rajendran <sathnaga@linux.vnet.ibm.com>
      Signed-off-by: 's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      636374c5
    • Kan Liang's avatar
      perf/x86/intel/uncore: Add more IMC PCI IDs for KabyLake and CoffeeLake CPUs · 19b7cd1b
      Kan Liang authored
      [ Upstream commit c10a8de0d32e95b0b8c7c17b6dc09baea5a5a899 ]
      
      KabyLake and CoffeeLake CPUs have the same client uncore events as SkyLake.
      
      Add the PCI IDs for the KabyLake Y, U, S processor lines and CoffeeLake U,
      H, S processor lines.
      Signed-off-by: 's avatarKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: 's avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/20181019170419.378-1-kan.liang@linux.intel.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      19b7cd1b
    • Michael Ellerman's avatar
      powerpc/io: Fix the IO workarounds code to work with Radix · 99bfbe57
      Michael Ellerman authored
      [ Upstream commit 43c6494fa1499912c8177e71450c0279041152a6 ]
      
      Back in 2006 Ben added some workarounds for a misbehaviour in the
      Spider IO bridge used on early Cell machines, see commit
      014da7ff ("[POWERPC] Cell "Spider" MMIO workarounds"). Later these
      were made to be generic, ie. not tied specifically to Spider.
      
      The code stashes a token in the high bits (59-48) of virtual addresses
      used for IO (eg. returned from ioremap()). This works fine when using
      the Hash MMU, but when we're using the Radix MMU the bits used for the
      token overlap with some of the bits of the virtual address.
      
      This is because the maximum virtual address is larger with Radix, up
      to c00fffffffffffff, and in fact we use that high part of the address
      range for ioremap(), see RADIX_KERN_IO_START.
      
      As it happens the bits that are used overlap with the bits that
      differentiate an IO address vs a linear map address. If the resulting
      address lies outside the linear mapping we will crash (see below), if
      not we just corrupt memory.
      
        virtio-pci 0000:00:00.0: Using 64-bit direct DMA at offset 800000000000000
        Unable to handle kernel paging request for data at address 0xc000000080000014
        ...
        CFAR: c000000000626b98 DAR: c000000080000014 DSISR: 42000000 IRQMASK: 0
        GPR00: c0000000006c54fc c00000003e523378 c0000000016de600 0000000000000000
        GPR04: c00c000080000014 0000000000000007 0fffffff000affff 0000000000000030
               ^^^^
        ...
        NIP [c000000000626c5c] .iowrite8+0xec/0x100
        LR [c0000000006c992c] .vp_reset+0x2c/0x90
        Call Trace:
          .pci_bus_read_config_dword+0xc4/0x120 (unreliable)
          .register_virtio_device+0x13c/0x1c0
          .virtio_pci_probe+0x148/0x1f0
          .local_pci_probe+0x68/0x140
          .pci_device_probe+0x164/0x220
          .really_probe+0x274/0x3b0
          .driver_probe_device+0x80/0x170
          .__driver_attach+0x14c/0x150
          .bus_for_each_dev+0xb8/0x130
          .driver_attach+0x34/0x50
          .bus_add_driver+0x178/0x2f0
          .driver_register+0x90/0x1a0
          .__pci_register_driver+0x6c/0x90
          .virtio_pci_driver_init+0x2c/0x40
          .do_one_initcall+0x64/0x280
          .kernel_init_freeable+0x36c/0x474
          .kernel_init+0x24/0x160
          .ret_from_kernel_thread+0x58/0x7c
      
      This hasn't been a problem because CONFIG_PPC_IO_WORKAROUNDS which
      enables this code is usually not enabled. It is only enabled when it's
      selected by PPC_CELL_NATIVE which is only selected by
      PPC_IBM_CELL_BLADE and that in turn depends on BIG_ENDIAN. So in order
      to hit the bug you need to build a big endian kernel, with IBM Cell
      Blade support enabled, as well as Radix MMU support, and then boot
      that on Power9 using Radix MMU.
      
      Still we can fix the bug, so let's do that. We simply use fewer bits
      for the token, taking the union of the restrictions on the address
      from both Hash and Radix, we end up with 8 bits we can use for the
      token. The only user of the token is iowa_mem_find_bus() which only
      supports 8 token values, so 8 bits is plenty for that.
      
      Fixes: 566ca99a ("powerpc/mm/radix: Add dummy radix_enabled()")
      Signed-off-by: 's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      99bfbe57
    • Scott Wood's avatar
      KVM: PPC: Move and undef TRACE_INCLUDE_PATH/FILE · c57911f0
      Scott Wood authored
      [ Upstream commit 28c5bcf74fa07c25d5bd118d1271920f51ce2a98 ]
      
      TRACE_INCLUDE_PATH and TRACE_INCLUDE_FILE are used by
      <trace/define_trace.h>, so like that #include, they should
      be outside #ifdef protection.
      
      They also need to be #undefed before defining, in case multiple trace
      headers are included by the same C file.  This became the case on
      book3e after commit cf4a6085151a ("powerpc/mm: Add missing tracepoint for
      tlbie"), leading to the following build error:
      
         CC      arch/powerpc/kvm/powerpc.o
      In file included from arch/powerpc/kvm/powerpc.c:51:0:
      arch/powerpc/kvm/trace.h:9:0: error: "TRACE_INCLUDE_PATH" redefined
      [-Werror]
        #define TRACE_INCLUDE_PATH .
        ^
      In file included from arch/powerpc/kvm/../mm/mmu_decl.h:25:0,
                        from arch/powerpc/kvm/powerpc.c:48:
      ./arch/powerpc/include/asm/trace.h:224:0: note: this is the location of
      the previous definition
        #define TRACE_INCLUDE_PATH asm
        ^
      cc1: all warnings being treated as errors
      Reported-by: 's avatarChristian Zigotzky <chzigotzky@xenosoft.de>
      Signed-off-by: 's avatarScott Wood <oss@buserror.net>
      Signed-off-by: 's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      c57911f0
  7. 27 Nov, 2018 4 commits
  8. 23 Nov, 2018 6 commits