30 Dec, 2010

1 commit

  • Go through x86 code and replace __get_cpu_var and get_cpu_var
    instances that refer to a scalar and are not used for address
    determinations.

    Cc: Yinghai Lu
    Cc: Ingo Molnar
    Acked-by: Tejun Heo
    Acked-by: "H. Peter Anvin"
    Signed-off-by: Christoph Lameter
    Signed-off-by: Tejun Heo

    Tejun Heo
     

12 Nov, 2010

1 commit

  • When a single step exception fires, the trap bits, used to
    signal hardware breakpoints, are in a random state.

    These trap bits might be set if another exception will follow,
    like a breakpoint in the next instruction, or a watchpoint in the
    previous one. Or there can be any junk there.

    So if we handle these trap bits during the single step exception,
    we are going to handle an exception twice, or we are going to
    handle junk.

    Just ignore them in this case.

    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=21332

    Reported-by: Michael Stefaniuc
    Signed-off-by: Frederic Weisbecker
    Cc: Rafael J. Wysocki
    Cc: Maciej Rutecki
    Cc: Alexandre Julliard
    Cc: Jason Wessel
    Cc: All since 2.6.33.x

    Frederic Weisbecker
     

17 Sep, 2010

1 commit

  • Lengths and types of breakpoints are encoded in a half byte
    into CPU registers. However when we extract these values
    and store them, we add a high half byte part to them: 0x40 to the
    length and 0x80 to the type.
    When that gets reloaded to the CPU registers, the high part
    is masked.

    While making the instruction breakpoints available for perf,
    I zapped that high part on instruction breakpoint encoding
    and that broke the arch -> generic translation used by ptrace
    instruction breakpoints. Writing dr7 to set an inst breakpoint
    was then failing.

    There is no apparent reason for these high parts so we could get
    rid of them altogether. That's an invasive change though so let's
    do that later and for now fix the problem by restoring that inst
    breakpoint high part encoding in this sole patch.

    Reported-by: Kelvie Wong
    Signed-off-by: Frederic Weisbecker
    Cc: Prasad
    Cc: Mahesh Salgaonkar
    Cc: Will Deacon

    Frederic Weisbecker
     

25 Jun, 2010

2 commits

  • Instruction breakpoints need to have a specific length of 0 to
    be working. Bring this support but also take care the user is not
    trying to set an unsupported length, like a range breakpoint for
    example.

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

    Frederic Weisbecker
     
  • Instruction breakpoints trigger before the instruction executes,
    and returning back from the breakpoint handler brings us again
    to the instruction that breakpointed. This naturally bring to
    a breakpoint recursion.

    To solve this, x86 has the Resume Bit trick. When the cpu flags
    have the RF flag set, the next instruction won't trigger any
    instruction breakpoint, and once this instruction is executed,
    RF is cleared back.

    This let's us jump back to the instruction that triggered the
    breakpoint without recursion.

    Use this when an instruction breakpoint triggers.

    Signed-off-by: Frederic Weisbecker
    Cc: Will Deacon
    Cc: Prasad
    Cc: Mahesh Salgaonkar
    Cc: Paul Mackerras
    Cc: Ingo Molnar
    Cc: Jason Wessel

    Frederic Weisbecker
     

01 May, 2010

1 commit

  • 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
     

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
     

28 Feb, 2010

1 commit

  • Remove the name field from the arch_hw_breakpoint. We never deal
    with target symbols in the arch level, neither do we need to ever
    store it. It's a legacy for the previous version of the x86
    breakpoint backend.

    Let's remove it.

    Signed-off-by: Frederic Weisbecker
    Cc: K.Prasad
    Cc: Linus Torvalds

    Frederic Weisbecker
     

27 Feb, 2010

1 commit


20 Feb, 2010

1 commit

  • Before we had a generic breakpoint API, ptrace was accepting
    breakpoints on NULL address in x86. The new API refuse them,
    without given strong reasons. We need to follow the previous
    behaviour as some userspace apps like Wine need such NULL
    breakpoints to ensure old emulated software protections
    are still working.

    This fixes a 2.6.32 - 2.6.33-x ptrace regression.

    Reported-and-tested-by: Michael Stefaniuc
    Signed-off-by: Frederic Weisbecker
    Acked-by: K.Prasad
    Acked-by: Roland McGrath
    Cc: Alan Stern
    Cc: Maneesh Soni
    Cc: Alexandre Julliard
    Cc: Rafael J. Wysocki
    Cc: Maciej Rutecki

    Frederic Weisbecker
     

29 Jan, 2010

1 commit

  • Processing of debug exceptions in do_debug() can stop if it
    originated from a hw-breakpoint exception by returning NOTIFY_STOP
    in most cases.

    But for certain cases such as:

    a) user-space breakpoints with pending SIGTRAP signal delivery (as
    in the case of ptrace induced breakpoints).

    b) exceptions due to other causes than breakpoints

    We will continue to process the exception by returning NOTIFY_DONE.

    Signed-off-by: K.Prasad
    Cc: Ingo Molnar
    Cc: Roland McGrath
    Cc: Alan Stern
    Cc: Jan Kiszka
    LKML-Reference:
    Signed-off-by: Frederic Weisbecker

    K.Prasad
     

06 Dec, 2009

1 commit

  • struct perf_event::event callback was called when a breakpoint
    triggers. But this is a rather opaque callback, pretty
    tied-only to the breakpoint API and not really integrated into perf
    as it triggers even when we don't overflow.

    We prefer to use overflow_handler() as it fits into the perf events
    rules, being called only when we overflow.

    Reported-by: Peter Zijlstra
    Signed-off-by: Frederic Weisbecker
    Cc: Paul Mackerras
    Cc: Arnaldo Carvalho de Melo
    Cc: "K. Prasad"

    Frederic Weisbecker
     

26 Nov, 2009

1 commit

  • When we schedule out a breakpoint from the cpu, we also
    incidentally remove the "Global exact breakpoint" flag from the
    breakpoint control register. It makes us losing the fine grained
    precision about the origin of the instructions that may trigger
    breakpoint exceptions for the other breakpoints running in this
    cpu.

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

    Frederic Weisbecker
     

25 Nov, 2009

1 commit

  • Percpu symbols now occupy the same namespace as other global
    symbols and as such short global symbols without subsystem
    prefix tend to collide with local variables. dr7 percpu
    variable used by x86 was hit by this. Rename it to cpu_dr7.

    The rename also makes it more consistent with its fellow
    cpu_debugreg percpu variable.

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

    Tejun Heo
     

24 Nov, 2009

1 commit


14 Nov, 2009

1 commit

  • This build error:

    arch/x86/kvm/x86.c:3655: error: implicit declaration of function 'hw_breakpoint_restore'

    Happens because in the CONFIG_KVM=m case there's no 'CONFIG_KVM' define
    in the kernel - it's CONFIG_KVM_MODULE in that case.

    Make the prototype available unconditionally.

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

    Ingo Molnar
     

10 Nov, 2009

1 commit


08 Nov, 2009

1 commit

  • 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
     

18 Jun, 2009

1 commit

  • arch_check_va_in_kernelspace() and hw_breakpoint_handler() is used only by same file so it should be static.

    Also fixed non-ANSI function declaration of function 'arch_uninstall_thread_hw_breakpoint'

    Fixed following sparse warnings :
    arch/x86/kernel/hw_breakpoint.c:124:42: warning: non-ANSI function declaration of function 'arch_uninstall_thread_hw_breakpoint'
    arch/x86/kernel/hw_breakpoint.c:169:5: warning: symbol 'arch_check_va_in_kernelspace' was not declared. Should it be static?
    arch/x86/kernel/hw_breakpoint.c:313:15: warning: symbol 'hw_breakpoint_handler' was not declared. Should it be static?

    Signed-off-by: Jaswinder Singh Rajput
    Cc: Alan Stern
    Cc: "K.Prasad"
    Cc: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Jaswinder Singh Rajput
     

17 Jun, 2009

1 commit

  • Conflicts:
    arch/x86/Kconfig
    arch/x86/kernel/traps.c
    arch/x86/power/cpu.c
    arch/x86/power/cpu_32.c
    kernel/Makefile

    Semantic conflict:
    arch/x86/kernel/hw_breakpoint.c

    Merge reason: Resolve the conflicts, move from put_cpu_no_sched() to
    put_cpu() in arch/x86/kernel/hw_breakpoint.c.

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

03 Jun, 2009

2 commits