1. 16 Mar, 2013 1 commit
  2. 15 Jan, 2013 1 commit
    • Alexey Kardashevskiy's avatar
      powerpc: Add DSCR support to ptrace · 1715a826
      Alexey Kardashevskiy authored
      
      
      The DSCR (aka Data Stream Control Register) is supported on some
      server PowerPC chips and allow some control over the prefetch
      of data streams.
      
      The kernel already supports DSCR value per thread but there is also
      a need in a ability to change it from an external process for
      the specific pid.
      
      The patch adds new register index PT_DSCR (index=44) which can be
      set/get by:
        ptrace(PTRACE_POKEUSER, traced_process, PT_DSCR << 3, dscr);
        dscr = ptrace(PTRACE_PEEKUSER, traced_process, PT_DSCR << 3, NULL);
      
      The patch does not increase PT_REGS_COUNT as the pt_regs struct has not
      been changed.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      1715a826
  3. 09 Jan, 2013 1 commit
  4. 14 Nov, 2012 4 commits
  5. 09 Sep, 2012 1 commit
  6. 21 May, 2012 1 commit
  7. 13 May, 2012 1 commit
  8. 29 Apr, 2012 1 commit
  9. 17 Apr, 2012 1 commit
  10. 28 Mar, 2012 1 commit
  11. 17 Jan, 2012 2 commits
    • Eric Paris's avatar
      audit: inline audit_syscall_entry to reduce burden on archs · b05d8447
      Eric Paris authored
      
      
      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: default avatarEric Paris <eparis@redhat.com>
      b05d8447
    • Eric Paris's avatar
      Audit: push audit success and retcode into arch ptrace.h · d7e7528b
      Eric Paris authored
      
      
      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: default avatarEric 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
  12. 31 Oct, 2011 1 commit
  13. 29 Sep, 2011 1 commit
    • Benjamin Herrenschmidt's avatar
      powerpc/ptrace: Fix build with gcc 4.6 · e69b742a
      Benjamin Herrenschmidt authored
      
      
      gcc (rightfully) complains that we are accessing beyond the
      end of the fpr array (we do, to access the fpscr).
      
      The only sane thing to do (whether anything in that code can be
      called remotely sane is debatable) is to special case fpscr and
      handle it as a separate statement.
      
      I initially tried to do it it by making the array access conditional
      to index < PT_FPSCR and using a 3rd else leg but for some reason gcc
      was unable to understand it and still spewed the warning.
      
      So I ended up with something a tad more intricated but it seems to
      build on 32-bit and on 64-bit with and without VSX.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e69b742a
  14. 01 Jul, 2011 2 commits
    • Avi Kivity's avatar
      perf: Add context field to perf_event · 4dc0da86
      Avi Kivity authored
      
      
      The perf_event overflow handler does not receive any caller-derived
      argument, so many callers need to resort to looking up the perf_event
      in their local data structure.  This is ugly and doesn't scale if a
      single callback services many perf_events.
      
      Fix by adding a context parameter to perf_event_create_kernel_counter()
      (and derived hardware breakpoints APIs) and storing it in the perf_event.
      The field can be accessed from the callback as event->overflow_handler_context.
      All callers are updated.
      Signed-off-by: default avatarAvi Kivity <avi@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1309362157-6596-2-git-send-email-avi@redhat.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4dc0da86
    • Peter Zijlstra's avatar
      perf: Remove the nmi parameter from the swevent and overflow interface · a8b0ca17
      Peter Zijlstra authored
      
      
      The nmi parameter indicated if we could do wakeups from the current
      context, if not, we would set some state and self-IPI and let the
      resulting interrupt do the wakeup.
      
      For the various event classes:
      
        - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
          the PMI-tail (ARM etc.)
        - tracepoint: nmi=0; since tracepoint could be from NMI context.
        - software: nmi=[0,1]; some, like the schedule thing cannot
          perform wakeups, and hence need 0.
      
      As one can see, there is very little nmi=1 usage, and the down-side of
      not using it is that on some platforms some software events can have a
      jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).
      
      The up-side however is that we can remove the nmi parameter and save a
      bunch of conditionals in fast paths.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Michael Cree <mcree@orcon.net.nz>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      a8b0ca17
  15. 25 May, 2011 1 commit
    • Ian Munsie's avatar
      powerpc/ftrace: Implement raw syscall tracepoints on PowerPC · 02424d89
      Ian Munsie authored
      
      
      This patch implements the raw syscall tracepoints on PowerPC and exports
      them for ftrace syscalls to use.
      
      To minimise reworking existing code, I slightly re-ordered the thread
      info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
      within the 16 bits of the andi. instruction's UI field. The instructions
      in question are in /arch/powerpc/kernel/entry_{32,64}.S to and the
      _TIF_SYSCALL_T_OR_A with the thread flags to see if system call tracing
      is enabled.
      
      In the case of 64bit PowerPC, arch_syscall_addr and
      arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
      work given the unusual system call table structure and symbol names that
      start with a period.
      Signed-off-by: default avatarIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      02424d89
  16. 06 May, 2011 1 commit
  17. 25 Apr, 2011 1 commit
  18. 31 Mar, 2011 1 commit
  19. 20 Mar, 2011 1 commit
    • Mike Wolf's avatar
      powerpc/ptrace: Remove BUG_ON when full register set not available · a71f5d5d
      Mike Wolf authored
      
      
      In some cases during a threaded core dump not all the threads will have
      a full register set. This happens when the signal causing the core dump
      races with a thread exiting.  The race happens when the exiting thread
      has entered the kernel for the last time before the signal arrives, but
      doesn't get far enough through the exit code to avoid being included
      in the core dump.
      
      So we get a thread included in the core dump which is never going to go
      out to userspace again and only has a partial register set recorded
      
      Normally we would catch each thread as it is about to go into userspace
      and capture the full register set then.
      
      However, this exiting thread is never going to go out to userspace
      again, so we have no way to capture its full register set.  It doesn't
      really matter, though, as this is a thread which is effectively
      already dead.
      
      So instead of hitting a BUG() in this case (a really bad choice of
      action in the first place), we use a poison value for the register
      values.
      
      [BenH]: Some cosmetic/stylistic changes and fix build on ppc32
      Signed-off-by: default avatarMike Wolf <mjw@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a71f5d5d
  20. 08 Dec, 2010 1 commit
  21. 27 Oct, 2010 2 commits
  22. 01 Sep, 2010 1 commit
  23. 22 Jun, 2010 1 commit
    • K.Prasad's avatar
      powerpc, hw_breakpoints: Implement hw_breakpoints for 64-bit server processors · 5aae8a53
      K.Prasad authored
      
      
      Implement perf-events based hw-breakpoint interfaces for PowerPC
      64-bit server (Book III S) processors.  This allows access to a
      given location to be used as an event that can be counted or
      profiled by the perf_events subsystem.
      
      This is done using the DABR (data breakpoint register), which can
      also be used for process debugging via ptrace.  When perf_event
      hw_breakpoint support is configured in, the perf_event subsystem
      manages the DABR and arbitrates access to it, and ptrace then
      creates a perf_event when it is requested to set a data breakpoint.
      
      [Adopted suggestions from Paul Mackerras <paulus@samba.org> to
      - emulate_step() all system-wide breakpoints and single-step only the
        per-task breakpoints
      - perform arch-specific cleanup before unregistration through
        arch_unregister_hw_breakpoint()
      ]
      Signed-off-by: default avatarK.Prasad <prasad@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      5aae8a53
  24. 07 Apr, 2010 1 commit
  25. 08 Mar, 2010 2 commits
  26. 16 Feb, 2010 3 commits
    • Dave Kleikamp's avatar
      powerpc/booke: Add support for advanced debug registers · 3bffb652
      Dave Kleikamp authored
      
      
      powerpc/booke: Add support for advanced debug registers
      
      From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
      
      Based on patches originally written by Torez Smith.
      
      This patch defines context switch and trap related functionality
      for BookE specific Debug Registers. It adds support to ptrace()
      for setting and getting BookE related Debug Registers
      Signed-off-by: default avatarDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Cc: Torez Smith  <lnxtorez@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Gibson <dwg@au1.ibm.com>
      Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: Sergio Durigan Junior <sergiodj@br.ibm.com>
      Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>
      Cc: linuxppc-dev list <Linuxppc-dev@ozlabs.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3bffb652
    • Dave Kleikamp's avatar
      powerpc: Extended ptrace interface · 3162d92d
      Dave Kleikamp authored
      
      
      powerpc: Extended ptrace interface
      
      From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
      
      Based on patches originally written by Torez Smith.
      
      Add a new extended ptrace interface so that user-space has a single
      interface for powerpc, without having to know the specific layout
      of the debug registers.
      
      Implement:
      PPC_PTRACE_GETHWDEBUGINFO
      PPC_PTRACE_SETHWDEBUG
      PPC_PTRACE_DELHWDEBUG
      Signed-off-by: default avatarDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Acked-by: default avatarDavid Gibson <dwg@au1.ibm.com>
      Cc: Torez Smith  <lnxtorez@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
      Cc: Kumar Gala <galak@kernel.crashing.org>
      Cc: Sergio Durigan Junior <sergiodj@br.ibm.com>
      Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>
      Cc: linuxppc-dev list <Linuxppc-dev@ozlabs.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3162d92d
    • Dave Kleikamp's avatar
      powerpc/booke: Introduce new CONFIG options for advanced debug registers · 172ae2e7
      Dave Kleikamp authored
      
      
      powerpc/booke: Introduce new CONFIG options for advanced debug registers
      
      From: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
      
      Introduce new config options to simplify the ifdefs pertaining to the
      advanced debug registers for booke and 40x processors:
      
      CONFIG_PPC_ADV_DEBUG_REGS - boolean: true for dac-based processors
      CONFIG_PPC_ADV_DEBUG_IACS - number of IAC registers
      CONFIG_PPC_ADV_DEBUG_DACS - number of DAC registers
      CONFIG_PPC_ADV_DEBUG_DVCS - number of DVC registers
      CONFIG_PPC_ADV_DEBUG_DAC_RANGE - DAC ranges supported
      
      Beginning conservatively, since I only have the facilities to test 440
      hardware.  I believe all 40x and booke platforms support at least 2 IAC
      and 2 DAC registers.  For 440, 4 IAC and 2 DVC registers are enabled, as
      well as the DAC ranges.
      Signed-off-by: default avatarDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Acked-by: default avatarDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      172ae2e7
  27. 15 Jul, 2009 1 commit
  28. 08 Jun, 2009 1 commit
  29. 29 Jul, 2008 2 commits
  30. 28 Jul, 2008 1 commit