Re: [RFC/RFT 2/2] RISC-V: kprobes/kretprobe support

[Guo Ren <guoren@kernel.org>]

Hi Patrick,

I'm the author of csky's kprobe & uprobe, please ref to kprobe [1], uprobe [2]

1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/csky?h=v5.8-rc1&id=33e53ae1ce413a081254e686d9b27cc1b3585e2f
2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/csky?h=v5.8-rc1&id=8f6bb793b2be82f1f73bfb416486f156f70b4314

May I continue your patches to finish the work? I'll keep the primary
author's name of you with the patches which you've done.

Most of the instructions' emulation codes will be deprecated, but the
rest is ok. Maybe you should finish executing out of the slot first
and then implement pc-related instructions' emulation.

On Fri, Jun 12, 2020 at 1:58 PM David Abdurachmanov
<david.abdurachmanov@gmail.com> wrote:
>
> On Tue, Mar 31, 2020 at 5:45 AM Zong Li <zong.li@sifive.com> wrote:
> >
> > On Thu, Dec 19, 2019 at 5:28 PM Zong Li <zong.li@sifive.com> wrote:
> > >
> > > On Wed, Dec 18, 2019 at 9:10 PM Patrick Stählin <me@packi.ch> wrote:
> > > >
> > > > Hi all
> > > >
> > > > On 18.12.19 10:14, Zong Li wrote:
> > > > > On Wed, Dec 18, 2019 at 5:09 PM Zong Li <zong.li@sifive.com> wrote:
> > > > >>
> > > > >> From: mhiramat@kernel.org (Masami Hiramatsu)
> > > > >>
> > > > >> On Wed, 14 Nov 2018 21:52:57 +0100
> > > > >> Patrick Staehlin <me@packi.ch> wrote:
> > > > >>
> > > > >>> Yeah, I think it's simpler.
> > > > >>>
> > > > >>> And I found that the kprobe_breakpoint_handler() was called without
> > > > >>> checking !user_mode(regs). In that case, you should add the check in
> > > > >>> front of kprobe_breakpoint_handler() call.
> > > > >>>
> > > > >>> Thank you,
> > > > >>
> > > > >> Hi all,
> > > > >>
> > > > >> Is there any update? I was wondering if this patch are keep going? If
> > > > >> not, I think I could pick it up to go head
> > > >
> > > > I am still working on it, albeit slowly, holiday season coming up here
> > > > in Switzerland may accelerate that a bit. All the feedback I got from
> > > > Masami has been implemented.
> > >
> > > As Masami's suggestion, I don't see stop_machine in your implementation [1],
> > > are there some concerns to use it on SMP?
> >
> > Hi all,
> > I introduced the patching code framework. Maybe it is helpful for
> > self-modify code here. (Please see:
> > https://lkml.org/lkml/2020/3/9/679)
> > This patch series is reviewing, maybe we could apply the
> > implementation after it was merged.
> >
> >
> > >
> > > > Additionally I added instruction simulation for everything except memory
> > > > accesses. I am currently working on getting compressed instructions
> > > > decoded properly into regular instructions but that is very tedious work.
> > > > I guess I am two or three full days of work away from getting a RFC/RFT
> > > > v2 series ready I guess that will happen in early January.
> > >
> > > Thanks for the efforts.
> > >
> > > >
> > > > What I currently have is at [1], that is mostly untested as of now
> > > > (beware I will rebase/squash that branch regularly). What I could use
> > > > help with in the future (as in for v2), is somebody testing it on real
> > > > hardware, as I've never gotten any testing feedback on my original
> > > > patch-series (that would not have worked properly because of the lacking
> > > > cache-flush).
> > >
> > > I give some quick tests by using kprobe sanity test and simple LKM on
> > > Hifive Unleashed board,
> > > it seems to work normally. I could help to test your next version patch as well.
>
> Hi Patrick,
>
> I have noticed that "riscv: introduce interfaces to patch kernel code"
> (mentioned by Zong above) has been merged in 5.7 kernel.
>
> I was wondering if you plan to submit a new revision of the patchset?
>
> Thanks,
> david
>
> > >
> > > >
> > > > [1] https://github.com/packi/linux/tree/kprobes-riscv
> > > >
> > > > Patrick
> >
>

-- 
Best Regards
 Guo Ren

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