1. 07 2月, 2012 1 次提交
    • S
      perf: Fix double start/stop in x86_pmu_start() · f39d47ff
      Stephane Eranian 提交于
      The following patch fixes a bug introduced by the following
      commit:
      
              e050e3f0 ("perf: Fix broken interrupt rate throttling")
      
      The patch caused the following warning to pop up depending on
      the sampling frequency adjustments:
      
        ------------[ cut here ]------------
        WARNING: at arch/x86/kernel/cpu/perf_event.c:995 x86_pmu_start+0x79/0xd4()
      
      It was caused by the following call sequence:
      
      perf_adjust_freq_unthr_context.part() {
           stop()
           if (delta > 0) {
                perf_adjust_period() {
                    if (period > 8*...) {
                        stop()
                        ...
                        start()
                    }
                }
            }
            start()
      }
      
      Which caused a double start and a double stop, thus triggering
      the assert in x86_pmu_start().
      
      The patch fixes the problem by avoiding the double calls. We
      pass a new argument to perf_adjust_period() to indicate whether
      or not the event is already stopped. We can't just remove the
      start/stop from that function because it's called from
      __perf_event_overflow where the event needs to be reloaded via a
      stop/start back-toback call.
      
      The patch reintroduces the assertion in x86_pmu_start() which
      was removed by commit:
      
      	84f2b9b2 ("perf: Remove deprecated WARN_ON_ONCE()")
      
      In this second version, we've added calls to disable/enable PMU
      during unthrottling or frequency adjustment based on bug report
      of spurious NMI interrupts from Eric Dumazet.
      Reported-and-tested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: markus@trippelsdorf.de
      Cc: paulus@samba.org
      Link: http://lkml.kernel.org/r/20120207133956.GA4932@quad
      [ Minor edits to the changelog and to the code ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f39d47ff
  2. 03 2月, 2012 1 次提交
    • S
      perf: Remove deprecated WARN_ON_ONCE() · 84f2b9b2
      Stephane Eranian 提交于
      With the new throttling/unthrottling code introduced with
      commit:
      
        e050e3f0 ("perf: Fix broken interrupt rate throttling")
      
      we occasionally hit two WARN_ON_ONCE() checks in:
      
        - intel_pmu_pebs_enable()
        - intel_pmu_lbr_enable()
        - x86_pmu_start()
      
      The assertions are no longer problematic. There is a valid
      path where they can trigger but it is harmless.
      
      The assertion can be triggered with:
      
        $ perf record -e instructions:pp ....
      
      Leading to paths:
      
        intel_pmu_pebs_enable
        intel_pmu_enable_event
        x86_perf_event_set_period
        x86_pmu_start
        perf_adjust_freq_unthr_context
        perf_event_task_tick
        scheduler_tick
      
      And:
      
        intel_pmu_lbr_enable
        intel_pmu_enable_event
        x86_perf_event_set_period
        x86_pmu_start
        perf_adjust_freq_unthr_context.
        perf_event_task_tick
        scheduler_tick
      
      cpuc->enabled is always on because when we get to
      perf_adjust_freq_unthr_context() the PMU is not totally
      disabled. Furthermore when we need to adjust a period,
      we only stop the event we need to change and not the
      entire PMU. Thus, when we re-enable, cpuc->enabled is
      already set. Note that when we stop the event, both
      pebs and lbr are stopped if necessary (and possible).
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: peterz@infradead.org
      Link: http://lkml.kernel.org/r/20120202110401.GA30911@quadSigned-off-by: NIngo Molnar <mingo@elte.hu>
      84f2b9b2
  3. 01 2月, 2012 3 次提交
  4. 30 1月, 2012 2 次提交
    • M
      x86/reboot: Remove VersaLogic Menlow reboot quirk · e6d36a65
      Michael D Labriola 提交于
      This commit removes the reboot quirk originally added by commit
      e19e074b ("x86: Fix reboot problem on VersaLogic Menlow boards").
      
      Testing with a VersaLogic Ocelot (VL-EPMs-21a rev 1.00 w/ BIOS
      6.5.102) revealed the following regarding the reboot hang
      problem:
      
      - v2.6.37 reboot=bios was needed.
      
      - v2.6.38-rc1: behavior changed, reboot=acpi is needed,
        reboot=kbd and reboot=bios results in system hang.
      
      - v2.6.38: VersaLogic patch (e19e074b "x86: Fix reboot problem on
        VersaLogic Menlow boards") was applied prior to v2.6.38-rc7.  This
        patch sets a quirk for VersaLogic Menlow boards that forces the use
        of reboot=bios, which doesn't work anymore.
      
      - v3.2: It seems that commit 660e34ce ("x86: Reorder reboot method
        preferences") changed the default reboot method to acpi prior to
        v3.0-rc1, which means the default behavior is appropriate for the
        Ocelot.  No VersaLogic quirk is required.
      
      The Ocelot board used for testing can successfully reboot w/out
      having to pass any reboot= arguments for all 3 current versions
      of the BIOS.
      Signed-off-by: NMichael D Labriola <michael.d.labriola@gmail.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Michael D Labriola <mlabriol@gdeb.com>
      Cc: Kushal Koolwal <kushalkoolwal@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/87vcnub9hu.fsf@gmail.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      e6d36a65
    • M
      x86/reboot: Skip DMI checks if reboot set by user · 5955633e
      Michael D Labriola 提交于
      Skip DMI checks for vendor specific reboot quirks if the user
      passed in a reboot= arg on the command line - we should never
      override user choices.
      Signed-off-by: NMichael D Labriola <michael.d.labriola@gmail.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Michael D Labriola <mlabriol@gdeb.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/87wr8ab9od.fsf@gmail.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      5955633e
  5. 28 1月, 2012 1 次提交
  6. 27 1月, 2012 2 次提交
    • P
      bugs, x86: Fix printk levels for panic, softlockups and stack dumps · b0f4c4b3
      Prarit Bhargava 提交于
      rsyslog will display KERN_EMERG messages on a connected
      terminal.  However, these messages are useless/undecipherable
      for a general user.
      
      For example, after a softlockup we get:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Stack:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Call Trace:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
       kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89
       d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <e8> ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89
      
      This happens because the printk levels for these messages are
      incorrect. Only an informational message should be displayed on
      a terminal.
      
      I modified the printk levels for various messages in the kernel
      and tested the output by using the drivers/misc/lkdtm.c kernel
      modules (ie, softlockups, panics, hard lockups, etc.) and
      confirmed that the console output was still the same and that
      the output to the terminals was correct.
      
      For example, in the case of a softlockup we now see the much
      more informative:
      
       Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ...
       BUG: soft lockup - CPU4 stuck for 60s!
      
      instead of the above confusing messages.
      
      AFAICT, the messages no longer have to be KERN_EMERG.  In the
      most important case of a panic we set console_verbose().  As for
      the other less severe cases the correct data is output to the
      console and /var/log/messages.
      
      Successfully tested by me using the drivers/misc/lkdtm.c module.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: dzickus@redhat.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1327586134-11926-1-git-send-email-prarit@redhat.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      b0f4c4b3
    • J
      x86: Properly parenthesize cmpxchg() macro arguments · fc395b92
      Jan Beulich 提交于
      Quite oddly, all of the arguments passed through from the top
      level macros to the second level which didn't need parentheses
      had them, while the only expression (involving a parameter)
      needing them didn't.
      
      Very recently I got bitten by the lack thereof when using
      something like "array + index" for the first operand, with
      "array" being an array more narrow than int.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/4F2183A9020000780006F3E6@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      fc395b92
  7. 26 1月, 2012 6 次提交
  8. 25 1月, 2012 1 次提交
    • D
      x86: xen: size struct xen_spinlock to always fit in arch_spinlock_t · 7a7546b3
      David Vrabel 提交于
      If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
      xen_spinlock is 32 bits.  When a spin lock is contended and
      xl->spinners is modified the two bytes immediately after the spin lock
      would be corrupted.
      
      This is a regression caused by 84eb950d
      (x86, ticketlock: Clean up types and accessors) which reduced the size
      of arch_spinlock_t.
      
      Fix this by making xl->spinners a u8 if NR_CPUS < 256.  A
      BUILD_BUG_ON() is also added to check the sizes of the two structures
      are compatible.
      
      In many cases this was not noticable as there would often be padding
      bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
      CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
      
      The bnx2 driver is affected. In struct bnx2, phy_lock and
      indirect_lock may have no padding after them.  Contention on phy_lock
      would corrupt indirect_lock making it appear locked and the driver
      would deadlock.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Acked-by: NIan Campbell <ian.campbell@citrix.com>
      CC: stable@kernel.org #only 3.2
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      7a7546b3
  9. 20 1月, 2012 1 次提交
  10. 19 1月, 2012 2 次提交
  11. 18 1月, 2012 6 次提交
    • A
      x86-32: Fix build failure with AUDIT=y, AUDITSYSCALL=n · 6015ff10
      Al Viro 提交于
      JONGMAN HEO reports:
      
        With current linus git (commit a25a2b84), I got following build error,
      
        arch/x86/kernel/vm86_32.c: In function 'do_sys_vm86':
        arch/x86/kernel/vm86_32.c:340: error: implicit declaration of function '__audit_syscall_exit'
        make[3]: *** [arch/x86/kernel/vm86_32.o] Error 1
      
      OK, I can reproduce it (32bit allmodconfig with AUDIT=y, AUDITSYSCALL=n)
      
      It's due to commit d7e7528b: "Audit: push audit success and retcode
      into arch ptrace.h".
      Reported-by: NJONGMAN HEO <jongman.heo@samsung.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6015ff10
    • L
      x86, tsc: Fix SMI induced variation in quick_pit_calibrate() · 68f30fbe
      Linus Torvalds 提交于
      pit_expect_msb() returns success wrongly in the below SMI scenario:
      
      a. pit_verify_msb() has not yet seen the MSB transition.
      
      b. we are close to the MSB transition though and got a SMI immediately after
         returning from pit_verify_msb() which didn't see the MSB transition. PIT MSB
         transition has happened somewhere during SMI execution.
      
      c. returned from SMI and we noted down the 'tsc', saw the pit MSB change now and
         exited the loop to calculate 'deltatsc'. Instead of noting the TSC at the MSB
         transition, we are way off because of the SMI.  And as the SMI happened
         between the pit_verify_msb() and before the 'tsc' is recorded in the
         for loop, 'delattsc' (d1/d2 in quick_pit_calibrate()) will be small and
         quick_pit_calibrate() will not notice this error.
      
      Depending on whether SMI disturbance happens while computing d1 or d2, we will
      see the TSC calibrated value smaller or bigger than the expected value. As a
      result, in a cluster we were seeing a variation of approximately +/- 20MHz in
      the calibrated values, resulting in NTP failures.
      
        [ As far as the SMI source is concerned, this is a periodic SMI that gets
          disabled after ACPI is enabled by the OS. But the TSC calibration happens
          before the ACPI is enabled. ]
      
      To address this, change pit_expect_msb() so that
      
       - the 'tsc' is the TSC in between the two reads that read the MSB
      change from the PIT (same as before)
      
       - the 'delta' is the difference in TSC from *before* the MSB changed
      to *after* the MSB changed.
      
      Now the delta is twice as big as before (it covers four PIT accesses,
      roughly 4us) and quick_pit_calibrate() will loop a bit longer to get
      the calibrated value with in the 500ppm precision. As the delta (d1/d2)
      covers four PIT accesses, actual calibrated result might be closer to
      250ppm precision.
      
      As the loop now takes longer to stabilize, double MAX_QUICK_PIT_MS to 50.
      
      SMI disturbance will showup as much larger delta's and the loop will take
      longer than usual for the result to be with in the accepted precision. Or will
      fallback to slow PIT calibration if it takes more than 50msec.
      
      Also while we are at this, remove the calibration correction that aims to
      get the result to the middle of the error bars. We really don't know which
      direction to correct into, so remove it.
      Reported-and-tested-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1326843337.5291.4.camel@sbsiddha-mobl2Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      68f30fbe
    • E
      audit: inline audit_syscall_entry to reduce burden on archs · b05d8447
      Eric Paris 提交于
      Every arch calls:
      
      if (unlikely(current->audit_context))
      	audit_syscall_entry()
      
      which requires knowledge about audit (the existance of audit_context) in
      the arch code.  Just do it all in static inline in audit.h so that arch's
      can remain blissfully ignorant.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      b05d8447
    • E
      audit: ia32entry.S sign extend error codes when calling 64 bit code · f031cd25
      Eric Paris 提交于
      In the ia32entry syscall exit audit fastpath we have assembly code which calls
      __audit_syscall_exit directly.  This code was, however, zeroes the upper 32
      bits of the return code.  It then proceeded to call code which expects longs
      to be 64bits long.  In order to handle code which expects longs to be 64bit we
      sign extend the return code if that code is an error.  Thus the
      __audit_syscall_exit function can correctly handle using the values in
      snprintf("%ld").  This fixes the regression introduced in 5cbf1565.
      
      Old record:
      type=SYSCALL msg=audit(1306197182.256:281): arch=40000003 syscall=192 success=no exit=4294967283
      New record:
      type=SYSCALL msg=audit(1306197182.256:281): arch=40000003 syscall=192 success=no exit=-13
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      f031cd25
    • E
      Audit: push audit success and retcode into arch ptrace.h · d7e7528b
      Eric Paris 提交于
      The audit system previously expected arches calling to audit_syscall_exit to
      supply as arguments if the syscall was a success and what the return code was.
      Audit also provides a helper AUDITSC_RESULT which was supposed to simplify things
      by converting from negative retcodes to an audit internal magic value stating
      success or failure.  This helper was wrong and could indicate that a valid
      pointer returned to userspace was a failed syscall.  The fix is to fix the
      layering foolishness.  We now pass audit_syscall_exit a struct pt_reg and it
      in turns calls back into arch code to collect the return value and to
      determine if the syscall was a success or failure.  We also define a generic
      is_syscall_success() macro which determines success/failure based on if the
      value is < -MAX_ERRNO.  This works for arches like x86 which do not use a
      separate mechanism to indicate syscall failure.
      
      We make both the is_syscall_success() and regs_return_value() static inlines
      instead of macros.  The reason is because the audit function must take a void*
      for the regs.  (uml calls theirs struct uml_pt_regs instead of just struct
      pt_regs so audit_syscall_exit can't take a struct pt_regs).  Since the audit
      function takes a void* we need to use static inlines to cast it back to the
      arch correct structure to dereference it.
      
      The other major change is that on some arches, like ia64, MIPS and ppc, we
      change regs_return_value() to give us the negative value on syscall failure.
      THE only other user of this macro, kretprobe_example.c, won't notice and it
      makes the value signed consistently for the audit functions across all archs.
      
      In arch/sh/kernel/ptrace_64.c I see that we were using regs[9] in the old
      audit code as the return value.  But the ptrace_64.h code defined the macro
      regs_return_value() as regs[3].  I have no idea which one is correct, but this
      patch now uses the regs_return_value() function, so it now uses regs[3].
      
      For powerpc we previously used regs->result but now use the
      regs_return_value() function which uses regs->gprs[3].  regs->gprs[3] is
      always positive so the regs_return_value(), much like ia64 makes it negative
      before calling the audit code when appropriate.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: H. Peter Anvin <hpa@zytor.com> [for x86 portion]
      Acked-by: Tony Luck <tony.luck@intel.com> [for ia64]
      Acked-by: Richard Weinberger <richard@nod.at> [for uml]
      Acked-by: David S. Miller <davem@davemloft.net> [for sparc]
      Acked-by: Ralf Baechle <ralf@linux-mips.org> [for mips]
      Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [for ppc]
      d7e7528b
    • U
      x86, opcode: ANDN and Group 17 in x86-opcode-map.txt · ce79dac8
      Ulrich Drepper 提交于
      The Intel documentation at
      
      http://software.intel.com/file/36945
      
      shows the ANDN opcode and Group 17 with encoding f2 and f3 encoding
      respectively.  The current version of x86-opcode-map.txt shows them
      with f3 and f4.  Unless someone can point to documentation which shows
      the currently used encoding the following patch be applied.
      Signed-off-by: NUlrich Drepper <drepper@gmail.com>
      Link: http://lkml.kernel.org/r/CAOPLpQdq5SuVo9=023CYhbFLAX9rONyjmYq7jJkqc5xwctW5eA@mail.gmail.comSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
      ce79dac8
  12. 17 1月, 2012 10 次提交
  13. 16 1月, 2012 3 次提交
  14. 14 1月, 2012 1 次提交