On Thu, 1 Apr 2021 16:49:47 +0800 "liaochang (A)" <liaocha...@huawei.com> wrote:
> Hi Jisheng, Hi, > > 在 2021/3/31 22:22, Jisheng Zhang 写道: > > On Tue, 30 Mar 2021 18:33:16 +0900 > > Masami Hiramatsu <mhira...@kernel.org> wrote: > > > >> Hi Jisheng, > > > > Hi Masami, > > > >> > >> On Tue, 30 Mar 2021 02:16:24 +0800 > >> Jisheng Zhang <jszha...@mail.ustc.edu.cn> wrote: > >> > >>> From: Jisheng Zhang <jszh...@kernel.org> > >>> > >>> Current riscv's kprobe handlers are run with both preemption and > >>> interrupt enabled, this violates kprobe requirements. Fix this issue > >>> by keeping interrupts disabled for BREAKPOINT exception. > >> > >> Not only while the breakpoint exception but also until the end of > >> the single step (maybe you are using __BUG_INSN_32 ??) need to be > >> disable interrupts. Can this do that? > >> > > > > interrupt is disabled during "single step" by kprobes_save_local_irqflag() > > and kprobes_restore_local_irqflag(). The code flow looks like: > > > > do_trap_break() // for bp > > kprobe_breakpoint_handler() > > setup_singlestep() > > kprobes_restore_local_irqflag() > > > > do_trap_break() // for ss > > kprobe_single_step_handler() > > kprobes_restore_local_irqflag() > > Recently, kernel hit BUG_ON() on QEMU after I install a probe at "sys_read" > via kprobe, TIPS: Each line should not exceed 80 chars > accoriding to my debugging and analysis it looks like caused by the "irq > disable" operation for single-stepping. > > I present a detailed description about this problem in the mail with title > "[PATCH] riscv/kprobe: fix kernel panic when invoking sys_read traced by > kprobe". > Looking forward to some feedback,Thanks. > I will comment that patch. thanks
