Sorry for paste the wrong link, it's this one instead: Link: https://lore.kernel.org/bpf/20230513001757.75ae0d1b@xxxxxxxxxxxxxxxxxxxx/ It's the original discussions of this problem. Regards, Ze On Tue, May 16, 2023 at 5:47 PM Ze Gao <zegao2021@xxxxxxxxx> wrote: > > Precisely, these that are called within kprobe_busy_{begin, end}, > which the previous patch does not resolve. > I will refine the commit message to make it clear. > > FYI, details can checked out here: > Link: https://lore.kernel.org/linux-trace-kernel/20230516132516.c902edcf21028874a74fb868@xxxxxxxxxx/ > > Regards, > Ze > > On Tue, May 16, 2023 at 5:18 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > On Tue, May 16, 2023 at 03:18:28PM +0800, Ze Gao wrote: > > > Current implementation calls kprobe related functions before doing > > > ftrace recursion check in fprobe_kprobe_handler, which opens door > > > to kernel crash due to stack recursion if preempt_count_{add, sub} > > > is traceable. > > > > Which preempt_count*() are you referring to? The ones you just made > > _notrace in the previous patch?