1. 22 10月, 2018 3 次提交
    • V
      s390/kasan: support preemptible kernel build · cf3dbe5d
      Vasily Gorbik 提交于
      When the kernel is built with:
      CONFIG_PREEMPT=y
      CONFIG_PREEMPT_COUNT=y
      "stfle" function used by kasan initialization code makes additional
      call to preempt_count_add/preempt_count_sub. To avoid removing kasan
      instrumentation from sched code where those functions leave split stfle
      function and provide __stfle variant without preemption handling to be
      used by Kasan.
      Reported-by: NBenjamin Block <bblock@linux.ibm.com>
      Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      cf3dbe5d
    • C
      x86/stackprotector: Remove the call to boot_init_stack_canary() from cpu_startup_entry() · 977e4be5
      Christophe Leroy 提交于
      The following commit:
      
        d7880812 ("idle: Add the stack canary init to cpu_startup_entry()")
      
      ... added an x86 specific boot_init_stack_canary() call to the generic
      cpu_startup_entry() as a temporary hack, with the intention to remove
      the #ifdef CONFIG_X86 later.
      
      More than 5 years later let's finally realize that plan! :-)
      
      While implementing stack protector support for PowerPC, we found
      that calling boot_init_stack_canary() is also needed for PowerPC
      which uses per task (TLS) stack canary like the X86.
      
      However, calling boot_init_stack_canary() would break architectures
      using a global stack canary (ARM, SH, MIPS and XTENSA).
      
      Instead of modifying the #ifdef CONFIG_X86 to an even messier:
      
         #if defined(CONFIG_X86) || defined(CONFIG_PPC)
      
      PowerPC implemented the call to boot_init_stack_canary() in the function
      calling cpu_startup_entry().
      
      Let's try the same cleanup on the x86 side as well.
      
      On x86 we have two functions calling cpu_startup_entry():
      
       - start_secondary()
       - cpu_bringup_and_idle()
      
      start_secondary() already calls boot_init_stack_canary(), so
      it's good, and this patch adds the call to boot_init_stack_canary()
      in cpu_bringup_and_idle().
      
      I.e. now x86 catches up to the rest of the world and the ugly init
      sequence in init/main.c can be removed from cpu_startup_entry().
      
      As a final benefit we can also remove the <linux/stackprotector.h>
      dependency from <linux/sched.h>.
      
      [ mingo: Improved the changelog a bit, added language explaining x86 borkage and sched.h change. ]
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Reviewed-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/20181020072649.5B59310483E@pc16082vm.idsi0.si.c-s.frSigned-off-by: NIngo Molnar <mingo@kernel.org>
      977e4be5
    • M
      kprobes/x86: Use preempt_enable() in optimized_callback() · 2e62024c
      Masami Hiramatsu 提交于
      The following commit:
      
        a19b2e3d ("kprobes/x86: Remove IRQ disabling from ftrace-based/optimized kprobes”)
      
      removed local_irq_save/restore() from optimized_callback(), the handler
      might be interrupted by the rescheduling interrupt and might be
      rescheduled - so we must not use the preempt_enable_no_resched() macro.
      
      Use preempt_enable() instead, to not lose preemption events.
      
      [ mingo: Improved the changelog. ]
      Reported-by: NNadav Amit <namit@vmware.com>
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: <stable@vger.kernel.org>
      Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: dwmw@amazon.co.uk
      Fixes: a19b2e3d ("kprobes/x86: Remove IRQ disabling from ftrace-based/optimized kprobes”)
      Link: http://lkml.kernel.org/r/154002887331.7627.10194920925792947001.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2e62024c
  2. 21 10月, 2018 1 次提交
  3. 19 10月, 2018 5 次提交
  4. 18 10月, 2018 4 次提交
  5. 17 10月, 2018 5 次提交
  6. 16 10月, 2018 9 次提交
    • O
      ataflop: fold headers into C file · 3e6b8c3c
      Omar Sandoval 提交于
      atafd.h and atafdreg.h are only used from ataflop.c, so merge them in
      there.
      Signed-off-by: NOmar Sandoval <osandov@fb.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      3e6b8c3c
    • P
      locking/qspinlock, x86: Provide liveness guarantee · 7aa54be2
      Peter Zijlstra 提交于
      On x86 we cannot do fetch_or() with a single instruction and thus end up
      using a cmpxchg loop, this reduces determinism. Replace the fetch_or()
      with a composite operation: tas-pending + load.
      
      Using two instructions of course opens a window we previously did not
      have. Consider the scenario:
      
      	CPU0		CPU1		CPU2
      
       1)	lock
      	  trylock -> (0,0,1)
      
       2)			lock
      			  trylock /* fail */
      
       3)	unlock -> (0,0,0)
      
       4)					lock
      					  trylock -> (0,0,1)
      
       5)			  tas-pending -> (0,1,1)
      			  load-val <- (0,1,0) from 3
      
       6)			  clear-pending-set-locked -> (0,0,1)
      
      			  FAIL: _2_ owners
      
      where 5) is our new composite operation. When we consider each part of
      the qspinlock state as a separate variable (as we can when
      _Q_PENDING_BITS == 8) then the above is entirely possible, because
      tas-pending will only RmW the pending byte, so the later load is able
      to observe prior tail and lock state (but not earlier than its own
      trylock, which operates on the whole word, due to coherence).
      
      To avoid this we need 2 things:
      
       - the load must come after the tas-pending (obviously, otherwise it
         can trivially observe prior state).
      
       - the tas-pending must be a full word RmW instruction, it cannot be an XCHGB for
         example, such that we cannot observe other state prior to setting
         pending.
      
      On x86 we can realize this by using "LOCK BTS m32, r32" for
      tas-pending followed by a regular load.
      
      Note that observing later state is not a problem:
      
       - if we fail to observe a later unlock, we'll simply spin-wait for
         that store to become visible.
      
       - if we observe a later xchg_tail(), there is no difference from that
         xchg_tail() having taken place before the tas-pending.
      Suggested-by: NWill Deacon <will.deacon@arm.com>
      Reported-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: andrea.parri@amarulasolutions.com
      Cc: longman@redhat.com
      Fixes: 59fb586b ("locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath")
      Link: https://lkml.kernel.org/r/20181003130957.183726335@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      7aa54be2
    • P
      x86/asm: 'Simplify' GEN_*_RMWcc() macros · 288e4521
      Peter Zijlstra 提交于
      Currently the GEN_*_RMWcc() macros include a return statement, which
      pretty much mandates we directly wrap them in a (inline) function.
      
      Macros with return statements are tricky and, as per the above, limit
      use, so remove the return statement and make them
      statement-expressions. This allows them to be used more widely.
      
      Also, shuffle the arguments a bit. Place the @cc argument as 3rd, this
      makes it consistent between UNARY and BINARY, but more importantly, it
      makes the @arg0 argument last.
      
      Since the @arg0 argument is now last, we can do CPP trickery and make
      it an optional argument, simplifying the users; 17 out of 18
      occurences do not need this argument.
      
      Finally, change to asm symbolic names, instead of the numeric ordering
      of operands, which allows us to get rid of __BINARY_RMWcc_ARG and get
      cleaner code overall.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: JBeulich@suse.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: bp@alien8.de
      Cc: hpa@linux.intel.com
      Link: https://lkml.kernel.org/r/20181003130957.108960094@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      288e4521
    • J
      perf/x86/intel: Export mem events only if there's PEBS support · d4ae5529
      Jiri Olsa 提交于
      Memory events depends on PEBS support and access to LDLAT MSR, but we
      display them in /sys/devices/cpu/events even if the CPU does not
      provide those, like for KVM guests.
      
      That brings the false assumption that those events should be
      available, while they fail event to open.
      
      Separating the mem-* events attributes and merging them with
      cpu_events only if there's PEBS support detected.
      
      We could also check if LDLAT MSR is available, but the PEBS check
      seems to cover the need now.
      Suggested-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.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: Michael Petlan <mpetlan@redhat.com>
      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/20180906135748.GC9577@kravaSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d4ae5529
    • S
      arm64: cpufeature: Trap CTR_EL0 access only where it is necessary · 4afe8e79
      Suzuki K Poulose 提交于
      When there is a mismatch in the CTR_EL0 field, we trap
      access to CTR from EL0 on all CPUs to expose the safe
      value. However, we could skip trapping on a CPU which
      matches the safe value.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      4afe8e79
    • S
      arm64: cpufeature: Fix handling of CTR_EL0.IDC field · 1602df02
      Suzuki K Poulose 提交于
      CTR_EL0.IDC reports the data cache clean requirements for instruction
      to data coherence. However, if the field is 0, we need to check the
      CLIDR_EL1 fields to detect the status of the feature. Currently we
      don't do this and generate a warning with tainting the kernel, when
      there is a mismatch in the field among the CPUs. Also the userspace
      doesn't have a reliable way to check the CLIDR_EL1 register to check
      the status.
      
      This patch fixes the problem by checking the CLIDR_EL1 fields, when
      (CTR_EL0.IDC == 0) and updates the kernel's copy of the CTR_EL0 for
      the CPU with the actual status of the feature. This would allow the
      sanity check infrastructure to do the proper checking of the fields
      and also allow the CTR_EL0 emulation code to supply the real status
      of the feature.
      
      Now, if a CPU has raw CTR_EL0.IDC == 0 and effective IDC == 1 (with
      overall system wide IDC == 1), we need to expose the real value to
      the user. So, we trap CTR_EL0 access on the CPU which reports incorrect
      CTR_EL0.IDC.
      
      Fixes: commit 6ae4b6e0 ("arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC")
      Cc: Shanker Donthineni <shankerd@codeaurora.org>
      Cc: Philip Elcan <pelcan@codeaurora.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      1602df02
    • S
      arm64: cpufeature: ctr: Fix cpu capability check for late CPUs · 8ab66cbe
      Suzuki K Poulose 提交于
      The matches() routine for a capability must honor the "scope"
      passed to it and return the proper results.
      i.e, when passed with SCOPE_LOCAL_CPU, it should check the
      status of the capability on the current CPU. This is used by
      verify_local_cpu_capabilities() on a late secondary CPU to make
      sure that it's compliant with the established system features.
      However, ARM64_HAS_CACHE_{IDC/DIC} always checks the system wide
      registers and this could mean that a late secondary CPU could return
      "true" (since the CPU hasn't updated the system wide registers yet)
      and thus lead the system in an inconsistent state, where
      the system assumes it has IDC/DIC feature, while the new CPU
      doesn't.
      
      Fixes: commit 6ae4b6e0 ("arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC")
      Cc: Philip Elcan <pelcan@codeaurora.org>
      Cc: Shanker Donthineni <shankerd@codeaurora.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      8ab66cbe
    • H
      parisc: Fix uninitialized variable usage in unwind.c · cf8afe5c
      Helge Deller 提交于
      As noticed by Dave Anglin, the last commit introduced a small bug where
      the potentially uninitialized r struct is used instead of the regs
      pointer as input for unwind_frame_init(). Fix it.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Reported-by: NJohn David Anglin <dave.anglin@bell.net>
      cf8afe5c
    • D
      Revert "sparc: Convert to using %pOFn instead of device_node.name" · a06ecbfe
      David S. Miller 提交于
      This reverts commit 0b9871a3.
      
      Causes crashes with qemu, interacts badly with commit commit
      6d0a70a2 ("vsprintf: print OF node name using full_name")
      etc.
      Reported-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a06ecbfe
  7. 15 10月, 2018 4 次提交
  8. 14 10月, 2018 5 次提交
    • N
      x86/boot: Add -Wno-pointer-sign to KBUILD_CFLAGS · dca5203e
      Nathan Chancellor 提交于
      When compiling the kernel with Clang, this warning appears even though
      it is disabled for the whole kernel because this folder has its own set
      of KBUILD_CFLAGS. It was disabled before the beginning of git history.
      
      In file included from arch/x86/boot/compressed/kaslr.c:29:
      In file included from arch/x86/boot/compressed/misc.h:21:
      In file included from ./include/linux/elf.h:5:
      In file included from ./arch/x86/include/asm/elf.h:77:
      In file included from ./arch/x86/include/asm/vdso.h:11:
      In file included from ./include/linux/mm_types.h:9:
      In file included from ./include/linux/spinlock.h:88:
      In file included from ./arch/x86/include/asm/spinlock.h:43:
      In file included from ./arch/x86/include/asm/qrwlock.h:6:
      ./include/asm-generic/qrwlock.h:101:53: warning: passing 'u32 *' (aka
      'unsigned int *') to parameter of type 'int *' converts between pointers
      to integer types with different sign [-Wpointer-sign]
              if (likely(atomic_try_cmpxchg_acquire(&lock->cnts, &cnts, _QW_LOCKED)))
                                                                 ^~~~~
      ./include/linux/compiler.h:76:40: note: expanded from macro 'likely'
      # define likely(x)      __builtin_expect(!!(x), 1)
                                                  ^
      ./include/asm-generic/atomic-instrumented.h:69:66: note: passing
      argument to parameter 'old' here
      static __always_inline bool atomic_try_cmpxchg(atomic_t *v, int *old, int new)
                                                                       ^
      Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Link: https://lkml.kernel.org/r/20181013010713.6999-1-natechancellor@gmail.com
      dca5203e
    • N
      x86/time: Correct the attribute on jiffies' definition · 53c13ba8
      Nathan Chancellor 提交于
      Clang warns that the declaration of jiffies in include/linux/jiffies.h
      doesn't match the definition in arch/x86/time/kernel.c:
      
      arch/x86/kernel/time.c:29:42: warning: section does not match previous declaration [-Wsection]
      __visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES;
                                               ^
      ./include/linux/cache.h:49:4: note: expanded from macro '__cacheline_aligned'
                       __section__(".data..cacheline_aligned")))
                       ^
      ./include/linux/jiffies.h:81:31: note: previous attribute is here
      extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies;
                                    ^
      ./arch/x86/include/asm/cache.h:20:2: note: expanded from macro '__cacheline_aligned_in_smp'
              __page_aligned_data
              ^
      ./include/linux/linkage.h:39:29: note: expanded from macro '__page_aligned_data'
      #define __page_aligned_data     __section(.data..page_aligned) __aligned(PAGE_SIZE)
                                      ^
      ./include/linux/compiler_attributes.h:233:56: note: expanded from macro '__section'
      #define __section(S)                    __attribute__((__section__(#S)))
                                                             ^
      1 warning generated.
      
      The declaration was changed in commit 7c30f352 ("jiffies.h: declare
      jiffies and jiffies_64 with ____cacheline_aligned_in_smp") but wasn't
      updated here. Make them match so Clang no longer warns.
      
      Fixes: 7c30f352 ("jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp")
      Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181013005311.28617-1-natechancellor@gmail.com
      53c13ba8
    • D
      x86/entry: Add some paranoid entry/exit CR3 handling comments · 16561f27
      Dave Hansen 提交于
      Andi Kleen was just asking me about the NMI CR3 handling and why
      we restore it unconditionally.  I was *sure* we had documented it
      well.  We did not.
      
      Add some documentation.  We have common entry code where the CR3
      value is stashed, but three places in two big code paths where we
      restore it.  I put bulk of the comments in this common path and
      then refer to it from the other spots.
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: luto@kernel.org
      Cc: bp@alien8.de
      Cc: "H. Peter Anvin" <hpa@zytor.come
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Link: https://lkml.kernel.org/r/20181012232118.3EAAE77B@viggo.jf.intel.com
      16561f27
    • P
      x86/percpu: Fix this_cpu_read() · b59167ac
      Peter Zijlstra 提交于
      Eric reported that a sequence count loop using this_cpu_read() got
      optimized out. This is wrong, this_cpu_read() must imply READ_ONCE()
      because the interface is IRQ-safe, therefore an interrupt can have
      changed the per-cpu value.
      
      Fixes: 7c3576d2 ("[PATCH] i386: Convert PDA into the percpu section")
      Reported-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Cc: hpa@zytor.com
      Cc: eric.dumazet@gmail.com
      Cc: bp@alien8.de
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181011104019.748208519@infradead.org
      b59167ac
    • P
      x86/tsc: Force inlining of cyc2ns bits · 4907c68a
      Peter Zijlstra 提交于
      Looking at the asm for native_sched_clock() I noticed we don't inline
      enough. Mostly caused by sharing code with cyc2ns_read_begin(), which
      we didn't used to do. So mark all that __force_inline to make it DTRT.
      
      Fixes: 59eaef78 ("x86/tsc: Remodel cyc2ns to use seqcount_latch()")
      Reported-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: hpa@zytor.com
      Cc: eric.dumazet@gmail.com
      Cc: bp@alien8.de
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20181011104019.695196158@infradead.org
      4907c68a
  9. 13 10月, 2018 3 次提交
    • V
      KVM: vmx: hyper-v: don't pass EPT configuration info to vmx_hv_remote_flush_tlb() · 5f8bb004
      Vitaly Kuznetsov 提交于
      I'm observing random crashes in multi-vCPU L2 guests running on KVM on
      Hyper-V. I bisected the issue to the commit 877ad952 ("KVM: vmx: Add
      tlb_remote_flush callback support"). Hyper-V TLFS states:
      
      "AddressSpace specifies an address space ID (an EPT PML4 table pointer)"
      
      So apparently, Hyper-V doesn't expect us to pass naked EPTP, only PML4
      pointer should be used. Strip off EPT configuration information before
      calling into vmx_hv_remote_flush_tlb().
      
      Fixes: 877ad952 ("KVM: vmx: Add tlb_remote_flush callback support")
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5f8bb004
    • D
      sparc: Throttle perf events properly. · 455adb31
      David S. Miller 提交于
      Like x86 and arm, call perf_sample_event_took() in perf event
      NMI interrupt handler.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      455adb31
    • D
      sparc: Fix single-pcr perf event counter management. · cfdc3170
      David S. Miller 提交于
      It is important to clear the hw->state value for non-stopped events
      when they are added into the PMU.  Otherwise when the event is
      scheduled out, we won't read the counter because HES_UPTODATE is still
      set.  This breaks 'perf stat' and similar use cases, causing all the
      events to show zero.
      
      This worked for multi-pcr because we make explicit sparc_pmu_start()
      calls in calculate_multiple_pcrs().  calculate_single_pcr() doesn't do
      this because the idea there is to accumulate all of the counter
      settings into the single pcr value.  So we have to add explicit
      hw->state handling there.
      
      Like x86, we use the PERF_HES_ARCH bit to track truly stopped events
      so that we don't accidently start them on a reload.
      
      Related to all of this, sparc_pmu_start() is missing a userpage update
      so add it.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cfdc3170
  10. 12 10月, 2018 1 次提交