All of lore.kernel.org
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: chenhuacai@kernel.org,chenhuacai@loongson.cn,duanchenghao@kylinos.cn,gregkh@linuxfoundation.org,kernel@xen0n.name,loongarch@lists.linux.dev,sashal@kernel.org
Cc: <stable-commits@vger.kernel.org>
Subject: Patch "LoongArch: Refactor register restoration in ftrace_common_return" has been added to the 6.6-stable tree
Date: Thu, 08 Jan 2026 11:40:50 +0100	[thread overview]
Message-ID: <2026010850-backroom-faceless-cb27@gregkh> (raw)
In-Reply-To: <20260106031300.961198-1-chenhuacai@loongson.cn>


This is a note to let you know that I've just added the patch titled

    LoongArch: Refactor register restoration in ftrace_common_return

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     loongarch-refactor-register-restoration-in-ftrace_common_return.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


From stable+bounces-205031-greg=kroah.com@vger.kernel.org Tue Jan  6 04:16:59 2026
From: Huacai Chen <chenhuacai@loongson.cn>
Date: Tue,  6 Jan 2026 11:13:00 +0800
Subject: LoongArch: Refactor register restoration in ftrace_common_return
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Sasha Levin <sashal@kernel.org>, Huacai Chen <chenhuacai@kernel.org>
Cc: Xuerui Wang <kernel@xen0n.name>, stable@vger.kernel.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, Chenghao Duan <duanchenghao@kylinos.cn>, Huacai Chen <chenhuacai@loongson.cn>
Message-ID: <20260106031300.961198-1-chenhuacai@loongson.cn>

From: Chenghao Duan <duanchenghao@kylinos.cn>

commit 45cb47c628dfbd1994c619f3eac271a780602826 upstream.

Refactor the register restoration sequence in the ftrace_common_return
function to clearly distinguish between the logic of normal returns and
direct call returns in function tracing scenarios. The logic is as
follows:

1. In the case of a normal return, the execution flow returns to the
traced function, and ftrace must ensure that the register data is
consistent with the state when the function was entered.

ra = parent return address; t0 = traced function return address.

2. In the case of a direct call return, the execution flow jumps to the
custom trampoline function, and ftrace must ensure that the register
data is consistent with the state when ftrace was entered.

ra = traced function return address; t0 = parent return address.

Cc: stable@vger.kernel.org
Fixes: 9cdc3b6a299c ("LoongArch: ftrace: Add direct call support")
Signed-off-by: Chenghao Duan <duanchenghao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/loongarch/kernel/mcount_dyn.S |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

--- a/arch/loongarch/kernel/mcount_dyn.S
+++ b/arch/loongarch/kernel/mcount_dyn.S
@@ -93,7 +93,6 @@ SYM_INNER_LABEL(ftrace_graph_call, SYM_L
  * at the callsite, so there is no need to restore the T series regs.
  */
 ftrace_common_return:
-	PTR_L		ra, sp, PT_R1
 	PTR_L		a0, sp, PT_R4
 	PTR_L		a1, sp, PT_R5
 	PTR_L		a2, sp, PT_R6
@@ -103,12 +102,17 @@ ftrace_common_return:
 	PTR_L		a6, sp, PT_R10
 	PTR_L		a7, sp, PT_R11
 	PTR_L		fp, sp, PT_R22
-	PTR_L		t0, sp, PT_ERA
 	PTR_L		t1, sp, PT_R13
-	PTR_ADDI	sp, sp, PT_SIZE
 	bnez		t1, .Ldirect
+
+	PTR_L		ra, sp, PT_R1
+	PTR_L		t0, sp, PT_ERA
+	PTR_ADDI	sp, sp, PT_SIZE
 	jr		t0
 .Ldirect:
+	PTR_L		t0, sp, PT_R1
+	PTR_L		ra, sp, PT_ERA
+	PTR_ADDI	sp, sp, PT_SIZE
 	jr		t1
 SYM_CODE_END(ftrace_common)
 
@@ -155,6 +159,8 @@ SYM_CODE_END(return_to_handler)
 
 #ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
 SYM_CODE_START(ftrace_stub_direct_tramp)
-	jr		t0
+	move		t1, ra
+	move		ra, t0
+	jr		t1
 SYM_CODE_END(ftrace_stub_direct_tramp)
 #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */


Patches currently in stable-queue which might be from chenhuacai@loongson.cn are

queue-6.6/loongarch-use-__pmd-__pte-for-swap-entry-conversions.patch
queue-6.6/loongarch-refactor-register-restoration-in-ftrace_common_return.patch
queue-6.6/loongarch-correct-the-calculation-logic-of-thread_count.patch
queue-6.6/loongarch-add-new-pci-id-for-pci_fixup_vgadev.patch
queue-6.6/loongarch-bpf-zero-extend-bpf_tail_call-index.patch
queue-6.6/loongarch-mask-all-interrupts-during-kexec-kdump.patch
queue-6.6/loongarch-fix-build-errors-for-config_randstruct.patch
queue-6.6/samples-ftrace-adjust-loongarch-register-restore-order-in-direct-calls.patch
queue-6.6/loongarch-bpf-sign-extend-kfunc-call-arguments.patch
queue-6.6/loongarch-use-unsigned-long-for-_end-and-_text.patch
queue-6.6/loongarch-add-machine_kexec_mask_interrupts-implementation.patch

      reply	other threads:[~2026-01-08 10:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-06  3:13 [PATCH 6.6] LoongArch: Refactor register restoration in ftrace_common_return Huacai Chen
2026-01-08 10:40 ` gregkh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026010850-backroom-faceless-cb27@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=chenhuacai@kernel.org \
    --cc=chenhuacai@loongson.cn \
    --cc=duanchenghao@kylinos.cn \
    --cc=kernel@xen0n.name \
    --cc=loongarch@lists.linux.dev \
    --cc=sashal@kernel.org \
    --cc=stable-commits@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.