Re: [PATCH v3 0/7] riscv: Add k/uprobe supported

[Guo Ren <guoren@kernel.org>]

On Tue, Jul 14, 2020 at 7:23 PM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> Hi Guo,
>
> On Mon, 13 Jul 2020 23:39:15 +0000
> guoren@kernel.org wrote:
>
> > From: Guo Ren <guoren@linux.alibaba.com>
> >
> > The patchset includes kprobe/uprobe support and some related fixups.
> > Patrick provides HAVE_REGS_AND_STACK_ACCESS_API support and some
> > kprobe's code. The framework of k/uprobe is from csky but also refers
> > to other arches'. kprobes on ftrace is also supported in the patchset.
> >
> > There is no single step exception in riscv ISA, only single-step
> > facility for jtag. See riscv-Privileged spec:
> >
> > Interrupt Exception Code-Description
> > 1 0 Reserved
> > 1 1 Supervisor software interrupt
> > 1 2–4 Reserved
> > 1 5 Supervisor timer interrupt
> > 1 6–8 Reserved
> > 1 9 Supervisor external interrupt
> > 1 10–15 Reserved
> > 1 ≥16 Available for platform use
> > 0 0 Instruction address misaligned
> > 0 1 Instruction access fault
> > 0 2 Illegal instruction
> > 0 3 Breakpoint
> > 0 4 Load address misaligned
> > 0 5 Load access fault
> > 0 6 Store/AMO address misaligned
> > 0 7 Store/AMO access fault
> > 0 8 Environment call from U-mode
> > 0 9 Environment call from S-mode
> > 0 10–11 Reserved
> > 0 12 Instruction page fault
> > 0 13 Load page fault
> > 0 14 Reserved
> > 0 15 Store/AMO page fault
> > 0 16–23 Reserved
> > 0 24–31 Available for custom use
> > 0 32–47 Reserved
> > 0 48–63 Available for custom use
> > 0 ≥64 Reserved
> >
> > No single step!
> >
> > Other arches use hardware single-step exception for k/uprobe,  eg:
> >  - powerpc: regs->msr |= MSR_SINGLESTEP
> >  - arm/arm64: PSTATE.D for enabling software step exceptions
> >  - s390: Set PER control regs, turns on single step for the given address
> >  - x86: regs->flags |= X86_EFLAGS_TF
> >  - csky: of course use hw single step :)
> >
> > All the above arches use a hardware single-step exception
> > mechanism to execute the instruction that was replaced with a probe
> > breakpoint. So utilize ebreak to simulate.
> >
> > Some pc related instructions couldn't be executed out of line and some
> > system/fence instructions couldn't be a trace site at all. So we give
> > out a reject list and simulate list in decode-insn.c.
> >
> > You could use uprobe to test simulate code like this:
> >
> >  echo 'p:enter_current_state_one /hello:0x6e4 a0=%a0 a1=%a1' >> /sys/kernel/debug/tracing/uprobe_events
> >  echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
> >  /hello
> >  ^C
> >  cat /sys/kernel/debug/tracing/trace
> >  tracer: nop
> >
> >  entries-in-buffer/entries-written: 1/1   #P:1
> >
> >                               _-----=> irqs-off
> >                              / _----=> need-resched
> >                             | / _---=> hardirq/softirq
> >                             || / _--=> preempt-depth
> >                             ||| /     delay
> >            TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> >               | |       |   ||||       |         |
> >           hello-94    [000] d...    55.404242: enter_current_state_one: (0x106e4) a0=0x1 a1=0x3fffa8ada8
> >
> > Be care /hello:0x6e4 is the file offset in elf and it relate to 0x106e4
> > in memory and hello is your target elf program.
> >
> > Try kprobe like this:
> >
> >  echo 'p:myprobe _do_fork dfd=%a0 filename=%a1 flags=%a2 mode=+4($stack)' > /sys/kernel/debug/tracing/kprobe_events
> >  echo 'r:myretprobe _do_fork $retval' >> /sys/kernel/debug/tracing/kprobe_event
> >
> >  echo 1 >/sys/kernel/debug/tracing/events/kprobes/enable
> >  cat /sys/kernel/debug/tracing/trace
> >  tracer: nop
> >
> >  entries-in-buffer/entries-written: 2/2   #P:1
> >
> >                               _-----=> irqs-off
> >                              / _----=> need-resched
> >                             | / _---=> hardirq/softirq
> >                             || / _--=> preempt-depth
> >                             ||| /     delay
> >            TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> >               | |       |   ||||       |         |
> >              sh-92    [000] .n..   131.804230: myprobe: (_do_fork+0x0/0x2e6) dfd=0xffffffe03929fdf8 filename=0x0 flags=0x101000 mode=0x1200000ffffffe0
> >              sh-92    [000] d...   131.806607: myretprobe: (__do_sys_clone+0x70/0x82 <- _do_fork) arg1=0x5f
> >  cat /sys/kernel/debug/tracing/trace
>
> Thank you for your great work!
>
> BTW, could you also run the ftracetest and boot-time smoke test on it?
> You can find it under tools/testing/selftests/ftrace, and
> CONFIG_KPROBES_SANITY_TEST.
> It will ensure that your patch is correctly ported.

CONFIG_KPROBES_SANITY_TEST passed:
[    0.078274] NET: Registered protocol family 16
[    0.162015] Kprobe smoke test: started
[    0.456900] Kprobe smoke test: passed successfully

The tools/testing/selftests/ftrace cover a lot of stuff not only
kprobe, and I'll try them later to fixup in another patchset.
-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv