Oops, I misunderstood your comments before.

Yes, it's not necessary to do this reordering as regards to kprobe.

Thanks for your review.

I'll rebase onto the latest tree and send v3 ASAP.

Regards,
Ze

On Wed, May 17, 2023 at 12:03 AM Masami Hiramatsu [off-list ref] wrote:

On Tue, 16 May 2023 17:47:52 +0800
Ze Gao [off-list ref] wrote:

quoted

Precisely, these that are called within kprobe_busy_{begin, end},
which the previous patch does not resolve.

Note that kprobe_busy_{begin,end} don't need to use notrace version
because kprobe itself prohibits probing on preempt_count_{add,sub}.

Thank you,

quoted

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@kernel.org/ (local)

Regards,
Ze

On Tue, May 16, 2023 at 5:18 PM Peter Zijlstra [off-list ref] wrote:

quoted

On Tue, May 16, 2023 at 03:18:28PM +0800, Ze Gao wrote:

quoted

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?

--
Masami Hiramatsu (Google) [off-list ref]