1. 15 Jun, 2011 5 commits
    • Robert Richter's avatar
      Merge branch 'oprofile/urgent' into HEAD · a406ab6d
      Robert Richter authored
      a406ab6d
    • Daniel Kalmar's avatar
      MIPS: oprofile: Add callgraph support · 5f307491
      Daniel Kalmar authored
      Stack unwinding is done by code examination. For kernelspace, the
      already existing unwind function is utilized that uses kallsyms to
      quickly find the beginning of functions. For userspace a new function
      was added that examines code at and before the pc.
      Signed-off-by: default avatarDaniel Kalmar <kalmard@homejinni.com>
      Signed-off-by: default avatarGergely Kis <gergely@homejinni.com>
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      5f307491
    • Daniel Kalmar's avatar
      MIPS: Add new unwind_stack variant · 94ea09c6
      Daniel Kalmar authored
      The unwind_stack_by_address variant supports unwinding based
      on any kernel code address.
      This symbol is also exported so it can be called from modules.
      Signed-off-by: default avatarDaniel Kalmar <kalmard@homejinni.com>
      Signed-off-by: default avatarGergely Kis <gergely@homejinni.com>
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      94ea09c6
    • Robert Richter's avatar
      oprofile, x86: Fix nmi-unsafe callgraph support · a0e3e702
      Robert Richter authored
      Current oprofile's x86 callgraph support may trigger page faults
      throwing the BUG_ON(in_nmi()) message below. This patch fixes this by
      using the same nmi-safe copy-from-user code as in perf.
      
      ------------[ cut here ]------------
      kernel BUG at .../arch/x86/kernel/traps.c:436!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/devices/pci0000:00/0000:00:0a.0/0000:07:00.0/0000:08:04.0/net/eth0/broadcast
      CPU 5
      Modules linked in:
      
      Pid: 8611, comm: opcontrol Not tainted 2.6.39-00007-gfe47ae7f #1 Advanced Micro Device Anaheim/Anaheim
      RIP: 0010:[<ffffffff813e8e35>]  [<ffffffff813e8e35>] do_nmi+0x22/0x1ee
      RSP: 0000:ffff88042fd47f28  EFLAGS: 00010002
      RAX: ffff88042c0a7fd8 RBX: 0000000000000001 RCX: 00000000c0000101
      RDX: 00000000ffff8804 RSI: ffffffffffffffff RDI: ffff88042fd47f58
      RBP: ffff88042fd47f48 R08: 0000000000000004 R09: 0000000000001484
      R10: 0000000000000001 R11: 0000000000000000 R12: ffff88042fd47f58
      R13: 0000000000000000 R14: ffff88042fd47d98 R15: 0000000000000020
      FS:  00007fca25e56700(0000) GS:ffff88042fd40000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000074 CR3: 000000042d28b000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process opcontrol (pid: 8611, threadinfo ffff88042c0a6000, task ffff88042c532310)
      Stack:
       0000000000000000 0000000000000001 ffff88042c0a7fd8 0000000000000000
       ffff88042fd47de8 ffffffff813e897a 0000000000000020 ffff88042fd47d98
       0000000000000000 ffff88042c0a7fd8 ffff88042fd47de8 0000000000000074
      Call Trace:
       <NMI>
       [<ffffffff813e897a>] nmi+0x1a/0x20
       [<ffffffff813f08ab>] ? bad_to_user+0x25/0x771
       <<EOE>>
      Code: ff 59 5b 41 5c 41 5d c9 c3 55 65 48 8b 04 25 88 b5 00 00 48 89 e5 41 55 41 54 49 89 fc 53 48 83 ec 08 f6 80 47 e0 ff ff 04 74 04 <0f> 0b eb fe 81 80 44 e0 ff ff 00 00 01 04 65 ff 04 25 c4 0f 01
      RIP  [<ffffffff813e8e35>] do_nmi+0x22/0x1ee
       RSP <ffff88042fd47f28>
      ---[ end trace ed6752185092104b ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      Pid: 8611, comm: opcontrol Tainted: G      D     2.6.39-00007-gfe47ae7f #1
      Call Trace:
       <NMI>  [<ffffffff813e5e0a>] panic+0x8c/0x188
       [<ffffffff813e915c>] oops_end+0x81/0x8e
       [<ffffffff8100403d>] die+0x55/0x5e
       [<ffffffff813e8c45>] do_trap+0x11c/0x12b
       [<ffffffff810023c8>] do_invalid_op+0x91/0x9a
       [<ffffffff813e8e35>] ? do_nmi+0x22/0x1ee
       [<ffffffff8131e6fa>] ? oprofile_add_sample+0x83/0x95
       [<ffffffff81321670>] ? op_amd_check_ctrs+0x4f/0x2cf
       [<ffffffff813ee4d5>] invalid_op+0x15/0x20
       [<ffffffff813e8e35>] ? do_nmi+0x22/0x1ee
       [<ffffffff813e8e7a>] ? do_nmi+0x67/0x1ee
       [<ffffffff813e897a>] nmi+0x1a/0x20
       [<ffffffff813f08ab>] ? bad_to_user+0x25/0x771
       <<EOE>>
      
      Cc: John Lumby <johnlumby@hotmail.com>
      Cc: Maynard Johnson <maynardj@us.ibm.com>
      Cc: <stable@kernel.org> # .37+
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      a0e3e702
    • Robert Richter's avatar
      oprofile, x86: Fix race in nmi handler while starting counters · 8fe7e94e
      Robert Richter authored
      In some rare cases, nmis are generated immediately after the nmi
      handler of the cpu was started. This causes the counter not to be
      enabled. Before enabling the nmi handlers we need to set variable
      ctr_running first and make sure its value is written to memory.
      
      Also, the patch makes all existing barriers a memory barrier instead
      of a compiler barrier only.
      Reported-by: default avatarSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Cc: <stable@kernel.org> # .35+
      Signed-off-by: default avatarRobert Richter <robert.richter@amd.com>
      8fe7e94e
  2. 13 Jun, 2011 10 commits
  3. 12 Jun, 2011 8 commits
  4. 11 Jun, 2011 16 commits
  5. 10 Jun, 2011 1 commit