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 Monday 05 January 2015 12:10 AM, Oleg Nesterov wrote:
> 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?
>

Yes,yes, no need of 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?

Yes, I do see any value addition in saving xol_vaddr in ss_ctx->match_addr.

>
> 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().

Yes.

~Pratyush


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