lkml.org 
[lkml]   [2015]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 8/8] ARM64: Add uprobe support
    On 01/04, Pratyush Anand wrote:
    >
    > On Friday 02 January 2015 10:53 PM, Oleg Nesterov wrote:
    >> But the main question is: why do we need add/find_ss_context ?? Please
    >> explain.
    >>
    >
    > See arch/arm64/kernel/debug-monitors.c: call_step_hook
    >
    > Unlike breakpoint exception, there is no ESR info check for step
    > exception. So, it is the responsibility of step handler
    > (uprobe_single_step_handler) to make sure that exception was generated
    > for it.

    Yes, yes, this is clear. My point was, we can (I think) rely on
    uprobe_post_sstep_notifier() which checks ->active_uprobe != NULL.

    And I guess you understood what I meant, but since I wasn't clear let
    me repeat to ensure we really understand each other.

    Can't

    uprobe_single_step_handler(regs, esr)
    {
    if (user_mode(regs) && uprobe_post_sstep_notifier(regs))
    return HANDLED;
    return ERROR;
    }

    work without this step_ctx logic?

    If everything is correct, the probed task can execute a single (xol) insn
    in user-mode before the trap. If ->active_uprobe is set we know that we
    expect the ss trap in user-mode, and nothing else except this xol insn can
    generate it?

    Perhaps arm64 needs additional checks, I dunno... If you think that the
    ->active_uprobe check is not enough you can probably also verify that
    "utask->state = UTASK_SSTEP" and/or "regs->pc - 4 == utask->xol_vaddr",
    but so far it seems to me that these additional checks can only make sense
    under WARN_ON().

    Oleg.



    \
     
     \ /
      Last update: 2015-01-04 20:01    [W:2.286 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site