1. 09 1月, 2011 1 次提交
    • C
      perf, x86: P4 PMU - Fix unflagged overflows handling · 047a3772
      Cyrill Gorcunov 提交于
      Don found that P4 PMU reads CCCR register instead of counter
      itself (in attempt to catch unflagged event) this makes P4
      NMI handler to consume all NMIs it observes. So the other
      NMI users such as kgdb simply have no chance to get NMI
      on their hands.
      
      Side note: at moment there is no way to run nmi-watchdog
      together with perf tool. This is because both 'perf top' and
      nmi-watchdog use same event. So while nmi-watchdog reserves
      one event/counter for own needs there is no room for perf tool
      left (there is a way to disable nmi-watchdog on boot of course).
      
      Ming has tested this patch with the following results
      
       | 1. watchdog disabled
       |
       | kgdb tests on boot OK
       | perf works OK
       |
       | 2. watchdog enabled, without patch perf-x86-p4-nmi-4
       |
       | kgdb tests on boot hang
       |
       | 3. watchdog enabled, without patch perf-x86-p4-nmi-4 and do not run kgdb
       | tests on boot
       |
       | "perf top" partialy works
       |   cpu-cycles            no
       |   instructions          yes
       |   cache-references      no
       |   cache-misses          no
       |   branch-instructions   no
       |   branch-misses         yes
       |   bus-cycles            no
       |
       | 4. watchdog enabled, with patch perf-x86-p4-nmi-4 applied
       |
       | kgdb tests on boot OK
       | perf does not work, NMI "Dazed and confused" messages show up
       |
      
      Which means we still have problems with p4 box due to 'unknown'
      nmi happens but at least it should fix kgdb test cases.
      Reported-by: NJason Wessel <jason.wessel@windriver.com>
      Reported-by: NDon Zickus <dzickus@redhat.com>
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Acked-by: NDon Zickus <dzickus@redhat.com>
      Acked-by: NLin Ming <ming.m.lin@intel.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <4D275E7E.3040903@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      047a3772
  2. 08 1月, 2011 1 次提交
    • F
      x86: Save rbp in pt_regs on irq entry · 625dbc3b
      Frederic Weisbecker 提交于
      From the x86_64 low level interrupt handlers, the frame pointer is
      saved right after the partial pt_regs frame.
      
      rbp is not supposed to be part of the irq partial saved registers,
      but it only requires to extend the pt_regs frame by 8 bytes to
      do so, plus a tiny stack offset fixup on irq exit.
      
      This changes a bit the semantics or get_irq_entry() that is supposed
      to provide only the value of caller saved registers and the cpu
      saved frame. However it's a win for unwinders that can walk through
      stack frames on top of get_irq_regs() snapshots.
      
      A noticeable impact is that it makes perf events cpu-clock and
      task-clock events based callchains working on x86_64.
      
      Let's then save rbp into the irq pt_regs.
      
      As a result with:
      
      	perf record -e cpu-clock perf bench sched messaging
      	perf report --stdio
      
      Before:
          20.94%             perf  [kernel.kallsyms]        [k] lock_acquire
                             |
                             --- lock_acquire
                                |
                                |--44.01%-- __write_nocancel
                                |
                                |--43.18%-- __read
                                |
                                |--6.08%-- fork
                                |          create_worker
                                |
                                |--0.88%-- _dl_fixup
                                |
                                |--0.65%-- do_lookup_x
                                |
                                |--0.53%-- __GI___libc_read
                                 --4.67%-- [...]
      
      After:
          19.23%         perf  [kernel.kallsyms]    [k] __lock_acquire
                         |
                         --- __lock_acquire
                            |
                            |--97.74%-- lock_acquire
                            |          |
                            |          |--21.82%-- _raw_spin_lock
                            |          |          |
                            |          |          |--37.26%-- unix_stream_recvmsg
                            |          |          |          sock_aio_read
                            |          |          |          do_sync_read
                            |          |          |          vfs_read
                            |          |          |          sys_read
                            |          |          |          system_call
                            |          |          |          __read
                            |          |          |
                            |          |          |--24.09%-- unix_stream_sendmsg
                            |          |          |          sock_aio_write
                            |          |          |          do_sync_write
                            |          |          |          vfs_write
                            |          |          |          sys_write
                            |          |          |          system_call
                            |          |          |          __write_nocancel
      
      v2: Fix cfi annotations.
      Reported-by: NSoeren Sandmann Pedersen <sandmann@redhat.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: H. Peter Anvin <hpa@zytor.com
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Jan Beulich <JBeulich@novell.com>
      625dbc3b
  3. 07 1月, 2011 7 次提交
  4. 05 1月, 2011 3 次提交
  5. 04 1月, 2011 2 次提交
  6. 03 1月, 2011 5 次提交
    • A
      ARM: pxa: fix page table corruption on resume · 24c78557
      Aric D. Blumer 提交于
      Before this patch, the following error would sometimes occur after a
      resume on pxa3xx:
      
          /path/to/mm/memory.c:144: bad pmd 8040542e.
      
      The problem was that a temporary page table mapping was being improperly
      restored.
      
      The PXA3xx resume code creates a temporary mapping of resume_turn_on_mmu
      to avoid a prefetch abort.  The pxa3xx_resume_after_mmu code requires
      that the r1 register holding the address of this mapping not be
      modified, however, resume_turn_on_mmu does modify it. It is mostly
      correct in that r1 receives the base table address, but it may also
      get other bits in 13:0.  This results in pxa3xx_resume_after_mmu
      restoring the original mapping to the wrong place, corrupting memory
      and leaving the temporary mapping in place.
      Signed-off-by: NMatt Reimer <mreimer@sdgsystems.com>
      Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
      24c78557
    • M
      ARM: it8152: add IT8152_LAST_IRQ definition to fix build error · 823a2df2
      Mike Rapoport 提交于
      The commit 6ac6b817 (ARM: pxa: encode
      IRQ number into .nr_irqs) removed definition of ITE_LAST_IRQ which
      caused the following build error:
      
      CC      arch/arm/common/it8152.o
      arch/arm/common/it8152.c: In function 'it8152_init_irq':
      arch/arm/common/it8152.c:86: error: 'IT8152_LAST_IRQ' undeclared (first use in this function)
      arch/arm/common/it8152.c:86: error: (Each undeclared identifier is reported only once
      arch/arm/common/it8152.c:86: error: for each function it appears in.)
      make[2]: *** [arch/arm/common/it8152.o] Error 1
      
      Defining the IT8152_LAST_IRQ in the arch/arm/include/hardware/it8152.c
      fixes the build.
      Signed-off-by: NMike Rapoport <mike@compulab.co.il>
      Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
      823a2df2
    • L
      ARM: pxa: PXA_ESERIES depends on FB_W100. · 82427de2
      Lennert Buytenhek 提交于
      As arch/arm/mach-pxa/eseries.c references w100fb_gpio_{read,write}()
      directly.
      Signed-off-by: NLennert Buytenhek <buytenh@secretlab.ca>
      Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
      82427de2
    • R
      arch/x86/oprofile/op_model_amd.c: Perform initialisation on a single CPU · c7c25802
      Robert Richter 提交于
      Disable preemption in init_ibs(). The function only checks the
      ibs capabilities and sets up pci devices (if necessary). It runs
      only on one cpu but operates with the local APIC and some MSRs,
      thus it is better to disable preemption.
      
      [    7.034377] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/483
      [    7.034385] caller is setup_APIC_eilvt+0x155/0x180
      [    7.034389] Pid: 483, comm: modprobe Not tainted 2.6.37-rc1-20101110+ #1
      [    7.034392] Call Trace:
      [    7.034400]  [<ffffffff812a2b72>] debug_smp_processor_id+0xd2/0xf0
      [    7.034404]  [<ffffffff8101e985>] setup_APIC_eilvt+0x155/0x180
      [ ... ]
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22812
      
      Reported-by: <atswartz@gmail.com>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      Cc: oprofile-list@lists.sourceforge.net <oprofile-list@lists.sourceforge.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Dan Carpenter <error27@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: <stable@kernel.org>         [2.6.37.x]
      LKML-Reference: <20110103111514.GM4739@erda.amd.com>
      [ small cleanups ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c7c25802
    • A
      ARM: 6605/1: Add missing include "asm/memory.h" · 7c0ab43e
      Axel Lin 提交于
      This patch fixes below build error by adding the missing asm/memory.h,
      which is needed for arch_is_coherent().
      
      $ make pxa3xx_defconfig; make
        CC      init/do_mounts_rd.o
      In file included from include/linux/list_bl.h:5,
                       from include/linux/rculist_bl.h:7,
                       from include/linux/dcache.h:7,
                       from include/linux/fs.h:381,
                       from init/do_mounts_rd.c:3:
      include/linux/bit_spinlock.h: In function 'bit_spin_unlock':
      include/linux/bit_spinlock.h:61: error: implicit declaration of function 'arch_is_coherent'
      make[1]: *** [init/do_mounts_rd.o] Error 1
      make: *** [init] Error 2
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Acked-by: NPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7c0ab43e
  7. 02 1月, 2011 1 次提交
  8. 29 12月, 2010 2 次提交
  9. 27 12月, 2010 1 次提交
    • J
      x86/microcode: Fix double vfree() and remove redundant pointer checks before vfree() · 5cdd2de0
      Jesper Juhl 提交于
      In arch/x86/kernel/microcode_intel.c::generic_load_microcode()
      we have  this:
      
      	while (leftover) {
      		...
      		if (get_ucode_data(mc, ucode_ptr, mc_size) ||
      		    microcode_sanity_check(mc) < 0) {
      			vfree(mc);
      			break;
      		}
      		...
      	}
      
      	if (mc)
      		vfree(mc);
      
      This will cause a double free of 'mc'. This patch fixes that by
      just  removing the vfree() call in the loop since 'mc' will be
      freed nicely just  after we break out of the loop.
      
      There's also a second change in the patch. I noticed a lot of
      checks for  pointers being NULL before passing them to vfree().
      That's completely  redundant since vfree() deals gracefully with
      being passed a NULL pointer.  Removing the redundant checks
      yields a nice size decrease for the object  file.
      
      Size before the patch:
         text    data     bss     dec     hex filename
         4578     240    1032    5850    16da arch/x86/kernel/microcode_intel.o
      Size after the patch:
         text    data     bss     dec     hex filename
         4489     240     984    5713    1651 arch/x86/kernel/microcode_intel.o
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Acked-by: NTigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Shaohua Li <shaohua.li@intel.com>
      LKML-Reference: <alpine.LNX.2.00.1012251946100.10759@swampdragon.chaosbits.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5cdd2de0
  10. 24 12月, 2010 6 次提交
  11. 23 12月, 2010 1 次提交
    • D
      x86, nmi_watchdog: Remove ARCH_HAS_NMI_WATCHDOG and rely on CONFIG_HARDLOCKUP_DETECTOR · 4a7863cc
      Don Zickus 提交于
      The x86 arch has shifted its use of the nmi_watchdog from a
      local implementation to the global one provide by
      kernel/watchdog.c.  This shift has caused a whole bunch of
      compile problems under different config options.  I attempt to
      simplify things with the patch below.
      
      In order to simplify things, I had to come to terms with the
      meaning of two terms ARCH_HAS_NMI_WATCHDOG and
      CONFIG_HARDLOCKUP_DETECTOR.  Basically they mean the same thing,
      the former on a local level and the latter on a global level.
      
      With the old x86 nmi watchdog gone, there is no need to rely on
      defining the ARCH_HAS_NMI_WATCHDOG variable because it doesn't
      make sense any more.  x86 will now use the global
      implementation.
      
      The changes below do a few things.  First it changes the few
      places that relied on ARCH_HAS_NMI_WATCHDOG to use
      CONFIG_X86_LOCAL_APIC (the former was an alias for the latter
      anyway, so nothing unusual here).  Those pieces of code were
      relying more on local apic functionality the nmi watchdog
      functionality, so the change should make sense.
      
      Second, I removed the x86 implementation of
      touch_nmi_watchdog().  It isn't need now, instead x86 will rely
      on kernel/watchdog.c's implementation.
      
      Third, I removed the #define ARCH_HAS_NMI_WATCHDOG itself from
      x86.  And tweaked the include/linux/nmi.h file to tell users to
      look for an externally defined touch_nmi_watchdog in the case of
      ARCH_HAS_NMI_WATCHDOG _or_ CONFIG_HARDLOCKUP_DETECTOR. This
      changes removes some of the ugliness in that file.
      
      Finally, I added a Kconfig dependency for
      CONFIG_HARDLOCKUP_DETECTOR that said you can't have
      ARCH_HAS_NMI_WATCHDOG _and_ CONFIG_HARDLOCKUP_DETECTOR.  You can
      only have one nmi_watchdog.
      
      Tested with
      ARCH=i386: allnoconfig, defconfig, allyesconfig, (various broken
      configs) ARCH=x86_64: allnoconfig, defconfig, allyesconfig,
      (various broken configs)
      
      Hopefully, after this patch I won't get any more compile broken
      emails. :-)
      
      v3:
        changed a couple of 'linux/nmi.h' -> 'asm/nmi.h' to pick-up correct function
        prototypes when CONFIG_HARDLOCKUP_DETECTOR is not set.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: fweisbec@gmail.com
      LKML-Reference: <1293044403-14117-1-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4a7863cc
  12. 22 12月, 2010 1 次提交
  13. 21 12月, 2010 1 次提交
  14. 20 12月, 2010 3 次提交
    • N
      ARM: fix cache-feroceon-l2 after stack based kmap_atomic() · 6d3e6d36
      Nicolas Pitre 提交于
      Since commit 3e4d3af5 "mm: stack based kmap_atomic()", it is actively
      wrong to rely on fixed kmap type indices (namely KM_L2_CACHE) as
      kmap_atomic() totally ignores them and a concurrent instance of it may
      happily reuse any slot for any purpose.  Because kmap_atomic() is now
      able to deal with reentrancy, we can get rid of the ad hoc mapping here.
      
      While the code is made much simpler, there is a needless cache flush
      introduced by the usage of __kunmap_atomic().  It is not clear if the
      performance difference to remove that is worth the cost in code
      maintenance (I don't think there are that many highmem users on that
      platform anyway) but that should be reconsidered when/if someone cares
      enough to do some measurements.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      6d3e6d36
    • N
      ARM: fix cache-xsc3l2 after stack based kmap_atomic() · 25cbe454
      Nicolas Pitre 提交于
      Since commit 3e4d3af5 "mm: stack based kmap_atomic()", it is actively
      wrong to rely on fixed kmap type indices (namely KM_L2_CACHE) as
      kmap_atomic() totally ignores them and a concurrent instance of it may
      happily reuse any slot for any purpose.  Because kmap_atomic() is now
      able to deal with reentrancy, we can get rid of the ad hoc mapping here,
      and we even don't have to disable IRQs anymore (highmem case).
      
      While the code is made much simpler, there is a needless cache flush
      introduced by the usage of __kunmap_atomic().  It is not clear if the
      performance difference to remove that is worth the cost in code
      maintenance (I don't think there are that many highmem users on that
      platform if at all anyway).
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      25cbe454
    • N
      ARM: get rid of kmap_high_l1_vipt() · 39af22a7
      Nicolas Pitre 提交于
      Since commit 3e4d3af5 "mm: stack based kmap_atomic()", it is no longer
      necessary to carry an ad hoc version of kmap_atomic() added in commit
      7e5a69e8 "ARM: 6007/1: fix highmem with VIPT cache and DMA" to cope
      with reentrancy.
      
      In fact, it is now actively wrong to rely on fixed kmap type indices
      (namely KM_L1_CACHE) as kmap_atomic() totally ignores them now and a
      concurrent instance of it may reuse any slot for any purpose.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      39af22a7
  15. 19 12月, 2010 2 次提交
  16. 18 12月, 2010 3 次提交
    • R
      ARM: smp: avoid incrementing mm_users on CPU startup · 1ae1b5f0
      Russell King 提交于
      We should not be incrementing mm_users when we startup a secondary
      CPU - doing so results in mm_users incrementing by one each time we
      hotplug a CPU, which will eventually wrap, and will cause problems.
      
      Other architectures such as x86 do not increment mm_users, but only
      mm_count, so we follow that pattern.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1ae1b5f0
    • H
      x86, kexec: Limit the crashkernel address appropriately · 7f8595bf
      H. Peter Anvin 提交于
      Keep the crash kernel address below 512 MiB for 32 bits and 896 MiB
      for 64 bits.  For 32 bits, this retains compatibility with earlier
      kernel releases, and makes it work even if the vmalloc= setting is
      adjusted.
      
      For 64 bits, we should be able to increase this substantially once a
      hard-coded limit in kexec-tools is fixed.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Stanislaw Gruszka <sgruszka@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      LKML-Reference: <20101217195035.GE14502@redhat.com>
      7f8595bf
    • C
      arch/tile: handle rt_sigreturn() more cleanly · 81711cee
      Chris Metcalf 提交于
      The current tile rt_sigreturn() syscall pattern uses the common idiom
      of loading up pt_regs with all the saved registers from the time of
      the signal, then anticipating the fact that we will clobber the ABI
      "return value" register (r0) as we return from the syscall by setting
      the rt_sigreturn return value to whatever random value was in the pt_regs
      for r0.
      
      However, this breaks in our 64-bit kernel when running "compat" tasks,
      since we always sign-extend the "return value" register to properly
      handle returned pointers that are in the upper 2GB of the 32-bit compat
      address space.  Doing this to the sigreturn path then causes occasional
      random corruption of the 64-bit r0 register.
      
      Instead, we stop doing the crazy "load the return-value register"
      hack in sigreturn.  We already have some sigreturn-specific assembly
      code that we use to pass the pt_regs pointer to C code.  We extend that
      code to also set the link register to point to a spot a few instructions
      after the usual syscall return address so we don't clobber the saved r0.
      Now it no longer matters what the rt_sigreturn syscall returns, and the
      pt_regs structure can be cleanly and completely reloaded.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      81711cee