This series addresses ftrace and kprobes issues observed under heavy
tracing loads.

Tiezhu Yang (4):
  LoongArch: ftrace: Fix stale per-CPU kprobe state after task migration
  LoongArch: kprobes: Use larch_insn_text_copy() to patch instructions
  LoongArch: kprobes: Fix single-stepping instruction slot preparation
  LoongArch: kprobes: Fix handling of fatal unrecoverable recursions

 arch/loongarch/kernel/ftrace_dyn.c | 23 +++++++++++++++++++++++
 arch/loongarch/kernel/kprobes.c    | 19 +++++++++++--------
 2 files changed, 34 insertions(+), 8 deletions(-)

-- 
2.42.0

On 2026/5/12 下午4:20, Tiezhu Yang wrote:
> This series addresses ftrace and kprobes issues observed under heavy
> tracing loads.
> 
> Tiezhu Yang (4):
>    LoongArch: ftrace: Fix stale per-CPU kprobe state after task migration
>    LoongArch: kprobes: Use larch_insn_text_copy() to patch instructions
>    LoongArch: kprobes: Fix single-stepping instruction slot preparation
>    LoongArch: kprobes: Fix handling of fatal unrecoverable recursions

Hi Lisa and Rui,

You are right, please ignore the patch #3.

Hi Huacai,

Please disregard the patch #1 and focus on the patch #2 and #4.

After thinking it through, it is better to avoid calling functions that
might sleep in the probe handler. We have modified the test module with
a proper way, there is no problem thereafter.

The right way is to prevent the problem at the root instead of trying to
fix it after the fact.

Thanks,
Tiezhu

On Fri, May 15, 2026 at 10:52 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> On 2026/5/12 下午4:20, Tiezhu Yang wrote:
> > This series addresses ftrace and kprobes issues observed under heavy
> > tracing loads.
> >
> > Tiezhu Yang (4):
> >    LoongArch: ftrace: Fix stale per-CPU kprobe state after task migration
> >    LoongArch: kprobes: Use larch_insn_text_copy() to patch instructions
> >    LoongArch: kprobes: Fix single-stepping instruction slot preparation
> >    LoongArch: kprobes: Fix handling of fatal unrecoverable recursions
>
> Hi Lisa and Rui,
>
> You are right, please ignore the patch #3.
I think Patch#3 is OK, but you need to remove the introduction about atomicity.

Huacai

>
> Hi Huacai,
>
> Please disregard the patch #1 and focus on the patch #2 and #4.
>
> After thinking it through, it is better to avoid calling functions that
> might sleep in the probe handler. We have modified the test module with
> a proper way, there is no problem thereafter.
>
> The right way is to prevent the problem at the root instead of trying to
> fix it after the fact.
>
> Thanks,
> Tiezhu
>
>

Hi, Tiezhu,

On Fri, May 15, 2026 at 12:29 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> On Fri, May 15, 2026 at 10:52 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> >
> > On 2026/5/12 下午4:20, Tiezhu Yang wrote:
> > > This series addresses ftrace and kprobes issues observed under heavy
> > > tracing loads.
> > >
> > > Tiezhu Yang (4):
> > >    LoongArch: ftrace: Fix stale per-CPU kprobe state after task migration
> > >    LoongArch: kprobes: Use larch_insn_text_copy() to patch instructions
> > >    LoongArch: kprobes: Fix single-stepping instruction slot preparation
> > >    LoongArch: kprobes: Fix handling of fatal unrecoverable recursions
> >
> > Hi Lisa and Rui,
> >
> > You are right, please ignore the patch #3.
> I think Patch#3 is OK, but you need to remove the introduction about atomicity.
Will you resend V2? Or just ignore Patch#3?

Huacai
>
> Huacai
>
> >
> > Hi Huacai,
> >
> > Please disregard the patch #1 and focus on the patch #2 and #4.
> >
> > After thinking it through, it is better to avoid calling functions that
> > might sleep in the probe handler. We have modified the test module with
> > a proper way, there is no problem thereafter.
> >
> > The right way is to prevent the problem at the root instead of trying to
> > fix it after the fact.
> >
> > Thanks,
> > Tiezhu
> >
> >

On 2026/5/20 下午3:58, Huacai Chen wrote:
> Hi, Tiezhu,
> 
> On Fri, May 15, 2026 at 12:29 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>
>> On Fri, May 15, 2026 at 10:52 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>>>
>>> On 2026/5/12 下午4:20, Tiezhu Yang wrote:
>>>> This series addresses ftrace and kprobes issues observed under heavy
>>>> tracing loads.
>>>>
>>>> Tiezhu Yang (4):
>>>>     LoongArch: ftrace: Fix stale per-CPU kprobe state after task migration
>>>>     LoongArch: kprobes: Use larch_insn_text_copy() to patch instructions
>>>>     LoongArch: kprobes: Fix single-stepping instruction slot preparation
>>>>     LoongArch: kprobes: Fix handling of fatal unrecoverable recursions
>>>
>>> Hi Lisa and Rui,
>>>
>>> You are right, please ignore the patch #3.
>> I think Patch#3 is OK, but you need to remove the introduction about atomicity.
> Will you resend V2? Or just ignore Patch#3?

I think no need to send v2.

Please disregard patch #1 and #3,
I will tell you more info in the inner meeting.

Please only consider patch #2 and #4.

Thanks,
Tiezhu

On Thu, May 21, 2026 at 10:37 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> On 2026/5/20 下午3:58, Huacai Chen wrote:
> > Hi, Tiezhu,
> >
> > On Fri, May 15, 2026 at 12:29 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> >>
> >> On Fri, May 15, 2026 at 10:52 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
> >>>
> >>> On 2026/5/12 下午4:20, Tiezhu Yang wrote:
> >>>> This series addresses ftrace and kprobes issues observed under heavy
> >>>> tracing loads.
> >>>>
> >>>> Tiezhu Yang (4):
> >>>>     LoongArch: ftrace: Fix stale per-CPU kprobe state after task migration
> >>>>     LoongArch: kprobes: Use larch_insn_text_copy() to patch instructions
> >>>>     LoongArch: kprobes: Fix single-stepping instruction slot preparation
> >>>>     LoongArch: kprobes: Fix handling of fatal unrecoverable recursions
> >>>
> >>> Hi Lisa and Rui,
> >>>
> >>> You are right, please ignore the patch #3.
> >> I think Patch#3 is OK, but you need to remove the introduction about atomicity.
> > Will you resend V2? Or just ignore Patch#3?
>
> I think no need to send v2.
>
> Please disregard patch #1 and #3,
> I will tell you more info in the inner meeting.
>
> Please only consider patch #2 and #4.
OK, but I want to remove preempt_enable_no_resched() in Patch#4
because all other architectures have no.

Huacai

>
> Thanks,
> Tiezhu
>
>

On 2026/5/21 下午8:52, Huacai Chen wrote:
> On Thu, May 21, 2026 at 10:37 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:

...

> OK, but I want to remove preempt_enable_no_resched() in Patch#4
> because all other architectures have no.

As the commit message said, this is to balance the preemption count.

We don't want to be preempted for the entire duration of kprobe
processing, preempt_disable() is called at the start of
kprobe_breakpoint_handler(), so preempt_enable_no_resched()
should also be called at each exit path.

So, it should keep the code as is.

Thanks,
Tiezhu

On Fri, May 22, 2026 at 10:17 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> On 2026/5/21 下午8:52, Huacai Chen wrote:
> > On Thu, May 21, 2026 at 10:37 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> ...
>
> > OK, but I want to remove preempt_enable_no_resched() in Patch#4
> > because all other architectures have no.
>
> As the commit message said, this is to balance the preemption count.
>
> We don't want to be preempted for the entire duration of kprobe
> processing, preempt_disable() is called at the start of
> kprobe_breakpoint_handler(), so preempt_enable_no_resched()
> should also be called at each exit path.
You are entering the panic path, who cares about preemption at this
point? On the other hand, keeping preemption disabled is better,
because nobody wants the "last state" to be corrupted by preemption.


Huacai

>
> So, it should keep the code as is.
>
> Thanks,
> Tiezhu
>

On 2026/5/22 上午10:40, Huacai Chen wrote:
> On Fri, May 22, 2026 at 10:17 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>>
>> On 2026/5/21 下午8:52, Huacai Chen wrote:
>>> On Thu, May 21, 2026 at 10:37 AM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>>
>> ...
>>
>>> OK, but I want to remove preempt_enable_no_resched() in Patch#4
>>> because all other architectures have no.
>>
>> As the commit message said, this is to balance the preemption count.
>>
>> We don't want to be preempted for the entire duration of kprobe
>> processing, preempt_disable() is called at the start of
>> kprobe_breakpoint_handler(), so preempt_enable_no_resched()
>> should also be called at each exit path.
> You are entering the panic path, who cares about preemption at this
> point? On the other hand, keeping preemption disabled is better,
> because nobody wants the "last state" to be corrupted by preemption.

If you look at it from this angle, no objection from me.

If there are no objections from the other people, you can
remove the code and the description in the commit message.

"2. Balancing the preemption count with preempt_enable_no_resched() to
    maintain preemption balance before the system halts."

Thanks,
Tiezhu