07 Aug, 2010

1 commit

  • …git/tip/linux-2.6-tip

    * 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (162 commits)
    tracing/kprobes: unregister_trace_probe needs to be called under mutex
    perf: expose event__process function
    perf events: Fix mmap offset determination
    perf, powerpc: fsl_emb: Restore setting perf_sample_data.period
    perf, powerpc: Convert the FSL driver to use local64_t
    perf tools: Don't keep unreferenced maps when unmaps are detected
    perf session: Invalidate last_match when removing threads from rb_tree
    perf session: Free the ref_reloc_sym memory at the right place
    x86,mmiotrace: Add support for tracing STOS instruction
    perf, sched migration: Librarize task states and event headers helpers
    perf, sched migration: Librarize the GUI class
    perf, sched migration: Make the GUI class client agnostic
    perf, sched migration: Make it vertically scrollable
    perf, sched migration: Parameterize cpu height and spacing
    perf, sched migration: Fix key bindings
    perf, sched migration: Ignore unhandled task states
    perf, sched migration: Handle ignored migrate out events
    perf: New migration tool overview
    tracing: Drop cpparg() macro
    perf: Use tracepoint_synchronize_unregister() to flush any pending tracepoint call
    ...

    Fix up trivial conflicts in Makefile and drivers/cpufreq/cpufreq.c

    Linus Torvalds
     

25 Jun, 2010

1 commit

  • Freeing a perf event can happen in several ways. A task
    calls perf_event_exit_task() right before exiting. This helper
    will detach all the events from the task context and queue their
    removal through free_event() if they are child tasks. The task
    also loses its context reference there.

    Releasing the breakpoint slot from the constraint table is made
    from free_event() that calls release_bp_slot(). We count the number
    of breakpoints this task is running by looking at the task's
    perf_event_ctxp and iterating through its attached events.
    But at this time, the reference to this context has been cleaned up
    already.

    So looking at the event->ctx instead of task->perf_event_ctxp
    to count the remaining breakpoints should solve the problem.
    At least it would for child breakpoints, but not for parent ones.
    If the parent exits before the child, it will remove all its
    events from the context but free_event() will be called later,
    on fd release time. And checking the number of breakpoints the
    task has attached to its context at this time is unreliable as all
    events have been removed from the context.

    To solve this, we keep track of the list of per task breakpoints.
    On top of it, we maintain our array of numbers of breakpoints used
    by the tasks. We use the context address as a task id.

    So, instead of looking at the number of events attached to a context,
    we walk through our list of per task breakpoints and count the number
    of breakpoints that use the same ctx than the one to be reserved or
    released from the constraint table, and update the count on top of this
    result.

    In the meantime it solves a bad refcounting, it also solves a warning,
    reported by Paul.

    Badness at /home/paulus/kernel/perf/kernel/hw_breakpoint.c:114
    NIP: c0000000000cb470 LR: c0000000000cb46c CTR: c00000000032d9b8
    REGS: c000000118e7b570 TRAP: 0700 Not tainted (2.6.35-rc3-perf-00008-g76b0f13
    )
    MSR: 9000000000029032 CR: 44004424 XER: 000fffff
    TASK = c0000001187dcad0[3143] 'perf' THREAD: c000000118e78000 CPU: 1
    GPR00: c0000000000cb46c c000000118e7b7f0 c0000000009866a0 0000000000000020
    GPR04: 0000000000000000 000000000000001d 0000000000000000 0000000000000001
    GPR08: c0000000009bed68 c00000000086dff8 c000000000a5bf10 0000000000000001
    GPR12: 0000000024004422 c00000000ffff200 0000000000000000 0000000000000000
    GPR16: 0000000000000000 0000000000000000 0000000000000018 00000000101150f4
    GPR20: 0000000010206b40 0000000000000000 0000000000000000 00000000101150f4
    GPR24: c0000001199090c0 0000000000000001 0000000000000000 0000000000000001
    GPR28: 0000000000000000 0000000000000000 c0000000008ec290 0000000000000000
    NIP [c0000000000cb470] .task_bp_pinned+0x5c/0x12c
    LR [c0000000000cb46c] .task_bp_pinned+0x58/0x12c
    Call Trace:
    [c000000118e7b7f0] [c0000000000cb46c] .task_bp_pinned+0x58/0x12c (unreliable)
    [c000000118e7b8a0] [c0000000000cb584] .toggle_bp_task_slot+0x44/0xe4
    [c000000118e7b940] [c0000000000cb6c8] .toggle_bp_slot+0xa4/0x164
    [c000000118e7b9f0] [c0000000000cbafc] .release_bp_slot+0x44/0x6c
    [c000000118e7ba80] [c0000000000c4178] .bp_perf_event_destroy+0x10/0x24
    [c000000118e7bb00] [c0000000000c4aec] .free_event+0x180/0x1bc
    [c000000118e7bbc0] [c0000000000c54c4] .perf_event_release_kernel+0x14c/0x170

    Reported-by: Paul Mackerras
    Signed-off-by: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Prasad
    Cc: Mahesh Salgaonkar
    Cc: Will Deacon
    Cc: Jason Wessel

    Frederic Weisbecker
     

22 Jun, 2010

1 commit


04 May, 2010

1 commit

  • Fix this build error:

    kernel/hw_breakpoint.c:58:1: error: pasting "__pcpu_scope_" and "*" does not give a valid preprocessing token

    It happens if CONFIG_DEBUG_FORCE_WEAK_PER_CPU, because we concatenate
    someting with the name and we have the "*" in the name.

    Cc: Frederic Weisbecker
    Cc: Will Deacon
    Cc: Paul Mundt
    Cc: Mahesh Salgaonkar
    Cc: K. Prasad
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Jason Wessel
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

01 May, 2010

5 commits

  • The breakpoint generic layer assumes that archs always know in advance
    the static number of address registers available to host breakpoints
    through the HBP_NUM macro.

    However this is not true for every archs. For example Arm needs to get
    this information dynamically to handle the compatiblity between
    different versions.

    To solve this, this patch proposes to drop the static HBP_NUM macro
    and let the arch provide the number of available slots through a
    new hw_breakpoint_slots() function. For archs that have
    CONFIG_HAVE_MIXED_BREAKPOINTS_REGS selected, it will be called once
    as the number of registers fits for instruction and data breakpoints
    together.
    For the others it will be called first to get the number of
    instruction breakpoint registers and another time to get the
    data breakpoint registers, the targeted type is given as a
    parameter of hw_breakpoint_slots().

    Reported-by: Will Deacon
    Signed-off-by: Frederic Weisbecker
    Acked-by: Paul Mundt
    Cc: Mahesh Salgaonkar
    Cc: K. Prasad
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Jason Wessel
    Cc: Ingo Molnar

    Frederic Weisbecker
     
  • Depending on their nature and on what an arch supports, breakpoints
    may consume more than one address register. For example a simple
    absolute address match usually only requires one address register.
    But an address range match may consume two registers.

    Currently our slot allocation constraints, that tend to reflect the
    limited arch's resources, always consider that a breakpoint consumes
    one slot.

    Then provide a way for archs to tell us the weight of a breakpoint
    through a new hw_breakpoint_weight() helper. This weight will be
    computed against the generic allocation constraints instead of
    a constant value.

    Signed-off-by: Frederic Weisbecker
    Acked-by: Paul Mundt
    Cc: Will Deacon
    Cc: Mahesh Salgaonkar
    Cc: K. Prasad
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Ingo Molnar

    Frederic Weisbecker
     
  • There are two outstanding fashions for archs to implement hardware
    breakpoints.

    The first is to separate breakpoint address pattern definition
    space between data and instruction breakpoints. We then have
    typically distinct instruction address breakpoint registers
    and data address breakpoint registers, delivered with
    separate control registers for data and instruction breakpoints
    as well. This is the case of PowerPc and ARM for example.

    The second consists in having merged breakpoint address space
    definition between data and instruction breakpoint. Address
    registers can host either instruction or data address and
    the access mode for the breakpoint is defined in a control
    register. This is the case of x86 and Super H.

    This patch adds a new CONFIG_HAVE_MIXED_BREAKPOINTS_REGS config
    that archs can select if they belong to the second case. Those
    will have their slot allocation merged for instructions and
    data breakpoints.

    The others will have a separate slot tracking between data and
    instruction breakpoints.

    Signed-off-by: Frederic Weisbecker
    Acked-by: Paul Mundt
    Cc: Will Deacon
    Cc: Mahesh Salgaonkar
    Cc: K. Prasad
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Ingo Molnar

    Frederic Weisbecker
     
  • The current policies of breakpoints in x86 and SH are the following:

    - task bound breakpoints can only break on userspace addresses
    - cpu wide breakpoints can only break on kernel addresses

    The former rule prevents ptrace breakpoints to be set to trigger on
    kernel addresses, which is good. But as a side effect, we can't
    breakpoint on kernel addresses for task bound breakpoints.

    The latter rule simply makes no sense, there is no reason why we
    can't set breakpoints on userspace while performing cpu bound
    profiles.

    We want the following new policies:

    - task bound breakpoint can set userspace address breakpoints, with
    no particular privilege required.
    - task bound breakpoints can set kernelspace address breakpoints but
    must be privileged to do that.
    - cpu bound breakpoints can do what they want as they are privileged
    already.

    To implement these new policies, this patch checks if we are dealing
    with a kernel address breakpoint, if so and if the exclude_kernel
    parameter is set, we tell the user that the breakpoint is invalid,
    which makes a good generic ptrace protection.
    If we don't have exclude_kernel, ensure the user has the right
    privileges as kernel breakpoints are quite sensitive (risk of
    trap recursion attacks and global performance impacts).

    [ Paul Mundt: keep addr space check for sh signal delivery and fix
    double function declaration]

    Signed-off-by: Frederic Weisbecker
    Cc: Will Deacon
    Cc: Mahesh Salgaonkar
    Cc: K. Prasad
    Cc: Paul Mundt
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Jason Wessel
    Cc: Ingo Molnar
    Signed-off-by: Paul Mundt

    Frederic Weisbecker
     
  • We stopped checking disabled breakpoints because we weren't
    allowing breakpoints on NULL addresses. And gdb tends to set
    NULL addresses on inactive breakpoints.

    But refusing NULL addresses was actually a regression that has
    been fixed now. There is no reason anymore to not validate
    inactive breakpoint settings.

    Signed-off-by: Frederic Weisbecker
    Acked-by: Paul Mundt
    Cc: Will Deacon
    Cc: Mahesh Salgaonkar
    Cc: K. Prasad
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Jason Wessel
    Cc: Ingo Molnar

    Frederic Weisbecker
     

04 Mar, 2010

1 commit


01 Mar, 2010

1 commit

  • We support event unthrottling in breakpoint events. It means
    that if we have more than sysctl_perf_event_sample_rate/HZ,
    perf will throttle, ignoring subsequent events until the next
    tick.

    So if ptrace exceeds this max rate, it will omit events, which
    breaks the ptrace determinism that is supposed to report every
    triggered breakpoints. This is likely to happen if we set
    sysctl_perf_event_sample_rate to 1.

    This patch removes support for unthrottling in breakpoint
    events to break throttling and restore ptrace determinism.

    Signed-off-by: Frederic Weisbecker
    Cc: 2.6.33.x
    Cc: Peter Zijlstra
    Cc: K.Prasad
    Cc: Paul Mackerras

    Frederic Weisbecker
     

27 Feb, 2010

1 commit

  • Add __percpu sparse annotations to hw_breakpoint.

    These annotations are to make sparse consider percpu variables to be
    in a different address space and warn if accessed without going
    through percpu accessors. This patch doesn't affect normal builds.

    In kernel/hw_breakpoint.c, per_cpu(nr_task_bp_pinned, cpu)'s will
    trigger spurious noderef related warnings from sparse. Changing it to
    &per_cpu(nr_task_bp_pinned[0], cpu) will work around the problem but
    deemed to ugly by the maintainer. Leave it alone until better
    solution can be found.

    Signed-off-by: Tejun Heo
    Cc: Stephen Rothwell
    Cc: K.Prasad
    LKML-Reference:
    Signed-off-by: Frederic Weisbecker

    Tejun Heo
     

04 Feb, 2010

1 commit

  • Change 'bp_len' type to __u64 to make it work across archs as
    the s390 architecture watch point length can be upto 2^64.

    reference:
    http://lkml.org/lkml/2010/1/25/212

    This is an ABI change that is not backward compatible with
    the previous hardware breakpoint info layout integrated in this
    development cycle, a rebuilt of perf tools is necessary for
    versions based on 2.6.33-rc1 - 2.6.33-rc6 to work with a
    kernel based on this patch.

    Signed-off-by: Mahesh Salgaonkar
    Acked-by: Peter Zijlstra
    Cc: Ananth N Mavinakayanahalli
    Cc: "K. Prasad"
    Cc: Maneesh Soni
    Cc: Heiko Carstens
    Cc: Martin
    LKML-Reference:
    Signed-off-by: Frederic Weisbecker

    Mahesh Salgaonkar
     

30 Jan, 2010

1 commit

  • This patch fixes the regression in functionality where the
    kernel debugger and the perf API do not nicely share hw
    breakpoint reservations.

    The kernel debugger cannot use any mutex_lock() calls because it
    can start the kernel running from an invalid context.

    A mutex free version of the reservation API needed to get
    created for the kernel debugger to safely update hw breakpoint
    reservations.

    The possibility for a breakpoint reservation to be concurrently
    processed at the time that kgdb interrupts the system is
    improbable. Should this corner case occur the end user is
    warned, and the kernel debugger will prohibit updating the
    hardware breakpoint reservations.

    Any time the kernel debugger reserves a hardware breakpoint it
    will be a system wide reservation.

    Signed-off-by: Jason Wessel
    Acked-by: Frederic Weisbecker
    Cc: kgdb-bugreport@lists.sourceforge.net
    Cc: K.Prasad
    Cc: Peter Zijlstra
    Cc: Alan Stern
    Cc: torvalds@linux-foundation.org
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Jason Wessel
     

28 Jan, 2010

1 commit

  • On a given architecture, when hardware breakpoint registration fails
    due to un-supported access type (read/write/execute), we lose the bp
    slot since register_perf_hw_breakpoint() does not release the bp slot
    on failure.
    Hence, any subsequent hardware breakpoint registration starts failing
    with 'no space left on device' error.

    This patch introduces error handling in register_perf_hw_breakpoint()
    function and releases bp slot on error.

    Signed-off-by: Mahesh Salgaonkar
    Cc: Ananth N Mavinakayanahalli
    Cc: K. Prasad
    Cc: Maneesh Soni
    LKML-Reference:
    Signed-off-by: Frederic Weisbecker

    Mahesh Salgaonkar
     

01 Jan, 2010

1 commit

  • …nel/git/tip/linux-2.6-tip

    * 'tracing-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    tracing: Fix sign fields in ftrace_define_fields_##call()
    tracing/syscalls: Fix typo in SYSCALL_DEFINE0
    tracing/kprobe: Show sign of fields in trace_kprobe format files
    ksym_tracer: Remove trace_stat
    ksym_tracer: Fix race when incrementing count
    ksym_tracer: Fix to allow writing newline to ksym_trace_filter
    ksym_tracer: Fix to make the tracer work
    tracing: Kconfig spelling fixes and cleanups
    tracing: Fix setting tracer specific options
    Documentation: Update ftrace-design.txt
    Documentation: Update tracepoint-analysis.txt
    Documentation: Update mmiotrace.txt

    Linus Torvalds
     

30 Dec, 2009

1 commit

  • ksym tracer doesn't work:

    # echo tasklist_lock:rw- > ksym_trace_filter
    -bash: echo: write error: No such device

    It's because we pass to perf_event_create_kernel_counter()
    a cpu number which is not present.

    Signed-off-by: Li Zefan
    Cc: Steven Rostedt
    Cc: K.Prasad
    Cc: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Li Zefan
     

15 Dec, 2009

1 commit


09 Dec, 2009

1 commit

  • Currently, when ptrace needs to modify a breakpoint, like disabling
    it, changing its address, type or len, it calls
    modify_user_hw_breakpoint(). This latter will perform the heavy and
    racy task of unregistering the old breakpoint and registering a new
    one.

    This is racy as someone else might steal the reserved breakpoint
    slot under us, which is undesired as the breakpoint is only
    supposed to be modified, sometimes in the middle of a debugging
    workflow. We don't want our slot to be stolen in the middle.

    So instead of unregistering/registering the breakpoint, just
    disable it while we modify its breakpoint fields and re-enable it
    after if necessary.

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Prasad
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

08 Dec, 2009

1 commit

  • Today's linux-next build failed with:

    kernel/hw_breakpoint.c:86: error: 'task_bp_pinned' redeclared as different kind of symbol
    ...

    Caused by commit dd17c8f72993f9461e9c19250e3f155d6d99df22 ("percpu:
    remove per_cpu__ prefix") from the percpu tree interacting with
    commit 56053170ea2a2c0dc17420e9b94aa3ca51d80408 ("hw-breakpoints:
    Fix task-bound breakpoint slot allocation") from the tip tree.

    Signed-off-by: Stephen Rothwell
    Acked-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Tejun Heo
    Cc: Rusty Russell
    Cc: Christoph Lameter
    Cc: Andrew Morton
    Cc: Linus Torvalds
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Stephen Rothwell
     

07 Dec, 2009

1 commit

  • Whatever the context nature of a breakpoint, we always perform the
    following constraint checks before allocating it a slot:

    - Check the number of pinned breakpoint bound the concerned cpus
    - Check the max number of task-bound breakpoints that are belonging
    to a task.
    - Add both and see if we have a reamining slot for the new breakpoint

    This is the right thing to do when we are about to register a cpu-only
    bound breakpoint. But not if we are dealing with a task bound
    breakpoint. What we want in this case is:

    - Check the number of pinned breakpoint bound the concerned cpus
    - Check the number of breakpoints that already belong to the task
    in which the breakpoint to register is bound to.
    - Add both

    This fixes a regression that makes the "firefox -g" command fail to
    register breakpoints once we deal with a secondary thread.

    Reported-by: Walt
    Signed-off-by: Frederic Weisbecker
    Cc: Prasad

    Frederic Weisbecker
     

06 Dec, 2009

2 commits


27 Nov, 2009

2 commits

  • Kernel breakpoints are created using functions in which we pass
    breakpoint parameters as individual variables: address, length
    and type.

    Although it fits well for x86, this just does not scale across
    architectures that may support this api later as these may have
    more or different needs. Pass in a perf_event_attr structure
    instead because it is meant to evolve as much as possible into
    a generic hardware breakpoint parameter structure.

    Reported-by: K.Prasad
    Signed-off-by: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     
  • In-kernel user breakpoints are created using functions in which
    we pass breakpoint parameters as individual variables: address,
    length and type.

    Although it fits well for x86, this just does not scale across
    archictectures that may support this api later as these may have
    more or different needs. Pass in a perf_event_attr structure
    instead because it is meant to evolve as much as possible into
    a generic hardware breakpoint parameter structure.

    Reported-by: K.Prasad
    Signed-off-by: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

26 Nov, 2009

2 commits

  • If the new percpu tree is combined with the perf events tree
    the following new warning triggers:

    kernel/hw_breakpoint.c: In function 'toggle_bp_task_slot':
    kernel/hw_breakpoint.c:151: warning: 'task_bp_pinned' is used uninitialized in this function

    Because it's not valid anymore to define a local variable
    and a percpu variable (even if it's file scope local) with
    the same name.

    Rename the local variable to resolve this.

    Signed-off-by: Andrew Morton
    Cc: Frederic Weisbecker
    Cc: K.Prasad
    Cc: Tejun Heo
    Cc: Linus Torvalds
    LKML-Reference:
    [ v2: added changelog ]
    Signed-off-by: Ingo Molnar

    Andrew Morton
     
  • This simplifies the error handling when we create a breakpoint.
    We don't need to check the NULL return value corner case anymore
    since we have improved perf_event_create_kernel_counter() to
    always return an error code in the failure case.

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Paul Mackerras
    Cc: Steven Rostedt
    Cc: Prasad
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

24 Nov, 2009

2 commits

  • Perf tools create perf events as disabled in the beginning.
    Breakpoints are then considered like ptrace temporary
    breakpoints, only meant to reserve a breakpoint slot until we
    get all the necessary informations from the user.

    In this case, we don't check the address that is breakpointed as
    it is NULL in the ptrace case.

    But perf tools don't have the same purpose, events are created
    disabled to wait for all events to be created before enabling
    all of them. We want to check the breakpoint parameters in this
    case.

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Paul Mackerras
    Cc: Prasad
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     
  • Attribute authorship to developers of hw-breakpoint related
    files.

    Signed-off-by: K.Prasad
    Cc: Alan Stern
    Cc: Frederic Weisbecker
    LKML-Reference:
    [ v2: moved it to latest -tip ]
    Signed-off-by: Ingo Molnar

    K.Prasad
     

22 Nov, 2009

1 commit


10 Nov, 2009

1 commit


08 Nov, 2009

2 commits

  • Allow or refuse to build a counter using the breakpoints pmu following
    given constraints.

    We keep track of the pmu users by using three per cpu variables:

    - nr_cpu_bp_pinned stores the number of pinned cpu breakpoints counters
    in the given cpu

    - nr_bp_flexible stores the number of non-pinned breakpoints counters
    in the given cpu.

    - task_bp_pinned stores the number of pinned task breakpoints in a cpu

    The latter is not a simple counter but gathers the number of tasks that
    have n pinned breakpoints.
    Considering HBP_NUM the number of available breakpoint address
    registers:
    task_bp_pinned[0] is the number of tasks having 1 breakpoint
    task_bp_pinned[1] is the number of tasks having 2 breakpoints
    [...]
    task_bp_pinned[HBP_NUM - 1] is the number of tasks having the
    maximum number of registers (HBP_NUM).

    When a breakpoint counter is created and wants an access to the pmu,
    we evaluate the following constraints:

    == Non-pinned counter ==

    - If attached to a single cpu, check:

    (per_cpu(nr_bp_flexible, cpu) || (per_cpu(nr_cpu_bp_pinned, cpu)
    + max(per_cpu(task_bp_pinned, cpu)))) < HBP_NUM

    -> If there are already non-pinned counters in this cpu, it
    means there is already a free slot for them.
    Otherwise, we check that the maximum number of per task
    breakpoints (for this cpu) plus the number of per cpu
    breakpoint (for this cpu) doesn't cover every registers.

    - If attached to every cpus, check:

    (per_cpu(nr_bp_flexible, *) || (max(per_cpu(nr_cpu_bp_pinned, *))
    + max(per_cpu(task_bp_pinned, *)))) < HBP_NUM

    -> This is roughly the same, except we check the number of per
    cpu bp for every cpu and we keep the max one. Same for the
    per tasks breakpoints.

    == Pinned counter ==

    - If attached to a single cpu, check:

    ((per_cpu(nr_bp_flexible, cpu) > 1)
    + per_cpu(nr_cpu_bp_pinned, cpu)
    + max(per_cpu(task_bp_pinned, cpu))) < HBP_NUM

    -> Same checks as before. But now the nr_bp_flexible, if any,
    must keep one register at least (or flexible breakpoints will
    never be be fed).

    - If attached to every cpus, check:

    ((per_cpu(nr_bp_flexible, *) > 1)
    + max(per_cpu(nr_cpu_bp_pinned, *))
    + max(per_cpu(task_bp_pinned, *))) < HBP_NUM

    Changes in v2:

    - Counter -> event rename

    Changes in v5:

    - Fix unreleased non-pinned task-bound-only counters. We only released
    it in the first cpu. (Thanks to Paul Mackerras for reporting that)

    Changes in v6:

    - Currently, events scheduling are done in this order: cpu context
    pinned + cpu context non-pinned + task context pinned + task context
    non-pinned events. Then our current constraints are right theoretically
    but not in practice, because non-pinned counters may be scheduled
    before we can apply every possible pinned counters. So consider
    non-pinned counters as pinned for now.

    Signed-off-by: Frederic Weisbecker
    Cc: Prasad
    Cc: Alan Stern
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Steven Rostedt
    Cc: Ingo Molnar
    Cc: Jan Kiszka
    Cc: Jiri Slaby
    Cc: Li Zefan
    Cc: Avi Kivity
    Cc: Paul Mackerras
    Cc: Mike Galbraith
    Cc: Masami Hiramatsu
    Cc: Paul Mundt

    Frederic Weisbecker
     
  • This patch rebase the implementation of the breakpoints API on top of
    perf events instances.

    Each breakpoints are now perf events that handle the
    register scheduling, thread/cpu attachment, etc..

    The new layering is now made as follows:

    ptrace kgdb ftrace perf syscall
    \ | / /
    \ | / /
    /
    Core breakpoint API /
    /
    | /
    | /

    Breakpoints perf events

    |
    |

    Breakpoints PMU ---- Debug Register constraints handling
    (Part of core breakpoint API)
    |
    |

    Hardware debug registers

    Reasons of this rewrite:

    - Use the centralized/optimized pmu registers scheduling,
    implying an easier arch integration
    - More powerful register handling: perf attributes (pinned/flexible
    events, exclusive/non-exclusive, tunable period, etc...)

    Impact:

    - New perf ABI: the hardware breakpoints counters
    - Ptrace breakpoints setting remains tricky and still needs some per
    thread breakpoints references.

    Todo (in the order):

    - Support breakpoints perf counter events for perf tools (ie: implement
    perf_bpcounter_event())
    - Support from perf tools

    Changes in v2:

    - Follow the perf "event " rename
    - The ptrace regression have been fixed (ptrace breakpoint perf events
    weren't released when a task ended)
    - Drop the struct hw_breakpoint and store generic fields in
    perf_event_attr.
    - Separate core and arch specific headers, drop
    asm-generic/hw_breakpoint.h and create linux/hw_breakpoint.h
    - Use new generic len/type for breakpoint
    - Handle off case: when breakpoints api is not supported by an arch

    Changes in v3:

    - Fix broken CONFIG_KVM, we need to propagate the breakpoint api
    changes to kvm when we exit the guest and restore the bp registers
    to the host.

    Changes in v4:

    - Drop the hw_breakpoint_restore() stub as it is only used by KVM
    - EXPORT_SYMBOL_GPL hw_breakpoint_restore() as KVM can be built as a
    module
    - Restore the breakpoints unconditionally on kvm guest exit:
    TIF_DEBUG_THREAD doesn't anymore cover every cases of running
    breakpoints and vcpu->arch.switch_db_regs might not always be
    set when the guest used debug registers.
    (Waiting for a reliable optimization)

    Changes in v5:

    - Split-up the asm-generic/hw-breakpoint.h moving to
    linux/hw_breakpoint.h into a separate patch
    - Optimize the breakpoints restoring while switching from kvm guest
    to host. We only want to restore the state if we have active
    breakpoints to the host, otherwise we don't care about messed-up
    address registers.
    - Add asm/hw_breakpoint.h to Kbuild
    - Fix bad breakpoint type in trace_selftest.c

    Changes in v6:

    - Fix wrong header inclusion in trace.h (triggered a build
    error with CONFIG_FTRACE_SELFTEST

    Signed-off-by: Frederic Weisbecker
    Cc: Prasad
    Cc: Alan Stern
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Steven Rostedt
    Cc: Ingo Molnar
    Cc: Jan Kiszka
    Cc: Jiri Slaby
    Cc: Li Zefan
    Cc: Avi Kivity
    Cc: Paul Mackerras
    Cc: Mike Galbraith
    Cc: Masami Hiramatsu
    Cc: Paul Mundt

    Frederic Weisbecker
     

03 Jun, 2009

1 commit

  • This patch introduces the generic Hardware Breakpoint interfaces for both user
    and kernel space requests.
    This core Api handles the hardware breakpoints through new helpers. It
    handles the user-space breakpoints and kernel breakpoints in front of
    arch implementation.

    One can choose kernel wide breakpoints using the following helpers
    and passing them a generic struct hw_breakpoint:

    - register_kernel_hw_breakpoint()
    - unregister_kernel_hw_breakpoint()
    - modify_kernel_hw_breakpoint()

    On the other side, you can choose per task breakpoints.

    - register_user_hw_breakpoint()
    - unregister_user_hw_breakpoint()
    - modify_user_hw_breakpoint()

    [ fweisbec@gmail.com: fix conflict against perfcounter ]

    Original-patch-by: Alan Stern
    Signed-off-by: K.Prasad
    Reviewed-by: Alan Stern
    Signed-off-by: Frederic Weisbecker

    K.Prasad