[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c6c385b0-60cf-b0c4-1962-974e783b131a@loongson.cn>
Date: Sun, 14 Dec 2025 20:36:16 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Chenghao Duan <duanchenghao@...inos.cn>, hengqi.chen@...il.com,
chenhuacai@...nel.org
Cc: kernel@...0n.name, zhangtianyang@...ngson.cn, masahiroy@...nel.org,
linux-kernel@...r.kernel.org, loongarch@...ts.linux.dev,
bpf@...r.kernel.org, youling.tang@...ux.dev, jianghaoran@...inos.cn,
vincent.mc.li@...il.com
Subject: Re: [PATCH v2 3/4] LoongArch: BPF: Enhance trampoline support for
kernel and module tracing
On 12/12/25 17:11, Chenghao Duan wrote:
> This patch addresses two main issues in the LoongArch BPF trampoline
> implementation:
>
> 1. BPF-to-BPF call handling:
> - Modify the build_prologue function to ensure that the value of the
> return address register ra is saved to t0 before entering the
> trampoline operation.
> - This ensures that the return address handling logic is accurate and
> error-free when a BPF program calls another BPF program.
>
> 2. Enable Module Function Tracing Support:
> - Remove the previous restrictions that blocked the tracing of kernel
> module functions.
> - Fix the issue that previously caused kernel lockups when attempting
> to trace module functions
>
> 3. Related Function Optimizations:
> - Adjust the jump offset of tail calls to ensure correct instruction
> alignment.
> - Enhance the bpf_arch_text_poke() function to enable accurate location
> of BPF program entry points.
> - Refine the trampoline return logic to ensure that the register data
> is correct when returning to both the traced function and the parent
> function.
>
> Signed-off-by: Chenghao Duan <duanchenghao@...inos.cn>
As described in the commit message, your changes include many kinds
of contents, thanks for the fixes and optimizations.
In order to avoid introducing bugs in the middle, please separate each
logical change into a separate patch, each patch should make an easily
understood change that can be verified by reviewers, each patch should
be justifiable on its own merits.
The current patch #4 can be put after the current patch #2 as a
preparation for the bpf patches.
Furthermore, it would be better to put the related test cases in the
commit message of each patch rather than in the cover letter, so that
it can be verified easily to know what this patch affected and can be
recorded in the git log.
And also please add Fixes tag for each patch if possible.
Thanks,
Tiezhu
Powered by blists - more mailing lists