[PATCH 4.4.y] arm: kprobes: Allow to handle reentered kprobe on single-stepping

Shaobo Huang huangshaobo6 at huawei.com
Tue Mar 2 01:24:49 GMT 2021


On March 1, 2021 at 11:30 AM, Greg KH wrote:
> On Mon, Feb 27, 2021 at 05:17:01PM +0800, huangshaobo wrote:
> > From: Masami Hiramatsu <mhiramat at kernel.org>
> > 
> > commit f3fbd7ec62dec1528fb8044034e2885f2b257941 upstream
> > 
> > This is arm port of commit 6a5022a56ac3 ("kprobes/x86: Allow to handle 
> > reentered kprobe on single-stepping")
> > 
> > Since the FIQ handlers can interrupt in the single stepping (or 
> > preparing the single stepping, do_debug etc.), we should consider a 
> > kprobe is hit in the NMI handler. Even in that case, the kprobe is 
> > allowed to be reentered as same as the kprobes hit in kprobe handlers 
> > (KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE).
> > 
> > The real issue will happen when a kprobe hit while another reentered 
> > kprobe is processing (KPROBE_REENTER), because we already consumed a 
> > saved-area for the previous kprobe.
> > 
> > Signed-off-by: Masami Hiramatsu <mhiramat at kernel.org>
> > Signed-off-by: Jon Medhurst <tixy at linaro.org>
> > Fixes: 24ba613c9d6c ("ARM kprobes: core code")
> > Cc: stable at vger.kernel.org #v2.6.25~v4.11
> > Signed-off-by: huangshaobo <huangshaobo6 at huawei.com>
> > ---
> >  arch/arm/probes/kprobes/core.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> 
> What about the 4.9.y tree as well?
> 
> thanks,
> 
> greg k-h

Yes, I tested on the 4.4.y tree. From the code analysis, the same problem
exists in the 2.6.25 to 4.11 trees, and of course the 4.9.y tree is also
included.

thanks,
ShaoBo Huang



More information about the linux-arm-kernel mailing list