From: haoran.jiang@linux.dev
To: "Huacai Chen" <chenhuacai@kernel.org>
Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
kernel@xen0n.name, yangtiezhu@loongson.cn,
"Haoran Jiang" <jianghaoran@kylinos.cn>
Subject: Re: [PATCH 0/2] Add support to dump the kernel page tables
Date: Wed, 22 Jul 2026 02:54:10 +0000 [thread overview]
Message-ID: <83b544072099ee1b03359d1a4c1c2af89f8fde65@linux.dev> (raw)
In-Reply-To: <CAAhV-H7GwHp1q-c5igf82h5gk1G5uDx+-gcrtqZsYHn_vbnR1g@mail.gmail.com>
2026年7月10日 20:52, "Huacai Chen" <chenhuacai@kernel.org mailto:chenhuacai@kernel.org?to=%22Huacai%20Chen%22%20%3Cchenhuacai%40kernel.org%3E > 写到:
>
> Hi, Haoran,
>
> On Tue, Jul 7, 2026 at 2:47 PM <haoran.jiang@linux.dev> wrote:
>
> >
> > From: Haoran Jiang <jianghaoran@kylinos.cn>
> >
> > Enforce the W^X principle on page tables,
> > and also support the kernel page dump feature.
> >
> > The following tests were performed:
> >
> > kdb:
> > echo kgdbts=V1 > /sys/module/kgdbts/parameters/kgdbts
> >
> > ebpf:
> > ./test_progs -t struct_ops -d struct_ops_multi_pages
> > ./test_progs -t fexit_stress
> > ./test_progs -t module_fentry_shadow
> > ./test_progs -t fentry_test/fentry
> > ./test_progs -t fexit_test/fexit
> > ./test_progs -t modify_return
> > ./test_progs -t fexit_sleep
> > ./test_progs -t test_overhead
> > ./test_progs -t trampoline_count
> > ./test_progs -t kprobe
> > ./test_progs -t uprobe
> >
> > livepatch:
> > insmod samples/livepatch/livepatch_sample.ko
> >
> > kprobe:
> > insmod samples/kprobes/kprobe_example.ko
> > insmod samples/kprobes/kretprobe_example.ko
> >
> > unxibench:
> > before this patch:
> > running 1 parallel copy of tests: 1492
> > running 128 parallel copies of tests: 8765
> >
> > after this patch:
> > running 1 parallel copy of tests: 1440
> > running 128 parallel copies of tests: 8749
> >
> I hope you have verified ftrace, kprobes, jump label, kgdb, etc. on
> modules, not only on the kernel itself. Otherwise the tests are not
> enough.
>
jump label:
Tested with the kernel test module at `/lib/test_static_keys.c`. The `static_branch_likely()` and `static_branch_unlikely()` functions
were exercised in module context, and all test cases passed successfully.
cd lib
insmod test_static_key_base.ko
insmod test_static_keys.ko
kprobe:
With ftrace disabled, used the kprobe sample module from `samples/kprobe/` in the kernel source to trace functions in a custom module.
The tracing of functions within the module worked as expected.
cd sample/kprobe
insmod kprobe_example.ko symbol="test_print"
insmod kretprobe_example.ko func="test_print"
[ 798.077262] handler_pre: <test_print> p->addr = 0x000000007e1cc0d2, era = 0xffff800003474000, estat = 0xc0000
[ 798.087827] handler_post: <test_print> p->addr = 0x000000007e1cc0d2, estat = 0xc0000
[ 798.116541] test_print returned 39 and took 39280450 ns to execute
ftrace:
With ftrace and fprobe enabled, the following eBPF program was used to trace functions such as `bpf_testmod_fentry_test1()`
in the `bpf_testmod.c` module. The underlying mechanism leverages ftrace capabilities, and all tests passed successfully.
cd tools/testing/selftests/bpf
./test_progs -t kprobe_multi_testmod_test
#172/1 kprobe_multi_testmod_test/testmod_attach_api_syms:OK
#172/2 kprobe_multi_testmod_test/testmod_attach_api_addrs:OK
#172 kprobe_multi_testmod_test:OK
Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED
kdb:
With KDB enabled, I installed breakpoints on functions in the module and performed single-step execution tests via KDB.
The tests passed successfully. During the testing, we observed that single-step debugging triggered an Oops error,
but this issue is unrelated to the two patches mentioned above.
[112]kdb> ss
Entering kdb (current=0x900020009f520000, pid 10661) on processor 112 Oops: (null)
due to oops @ 0x90000000005b57a4
I have submitted a fix patch for this issue.
https://lore.kernel.org/loongarch/20260722024409.158142-1-haoran.jiang@linux.dev/T/#u
> @Tiezhu, you are familiar with all the above mechanisms, so please
> help to review, and double check whether uprobes need to be modified.
>
> Huacai
>
> >
> > Haoran Jiang (2):
> > LoongArch: Enforce W^X for page-mapped virtual memory region
> > LoongArch: Add support to dump the kernel page tables
> >
> > arch/loongarch/Kconfig | 2 +
> > arch/loongarch/include/asm/pgtable-bits.h | 12 +-
> > arch/loongarch/kernel/ftrace_dyn.c | 16 +
> > arch/loongarch/kernel/inst.c | 25 +-
> > arch/loongarch/kernel/jump_label.c | 3 +
> > arch/loongarch/kernel/kgdb.c | 50 +++
> > arch/loongarch/kernel/kprobes.c | 4 +-
> > arch/loongarch/mm/Makefile | 1 +
> > arch/loongarch/mm/ptdump.c | 474 ++++++++++++++++++++++
> > 9 files changed, 575 insertions(+), 12 deletions(-)
> > create mode 100644 arch/loongarch/mm/ptdump.c
> >
> > --
> > 2.43.0
> >
>
prev parent reply other threads:[~2026-07-22 2:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 6:45 [PATCH 0/2] Add support to dump the kernel page tables haoran.jiang
2026-07-07 6:45 ` [PATCH 1/2] LoongArch: Enforce W^X for page-mapped virtual memory region haoran.jiang
2026-07-10 13:03 ` Huacai Chen
2026-07-07 6:45 ` [PATCH 2/2] LoongArch: Add support to dump the kernel page tables haoran.jiang
2026-07-10 14:08 ` Huacai Chen
2026-07-10 12:52 ` [PATCH 0/2] " Huacai Chen
2026-07-22 2:54 ` haoran.jiang [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=83b544072099ee1b03359d1a4c1c2af89f8fde65@linux.dev \
--to=haoran.jiang@linux.dev \
--cc=chenhuacai@kernel.org \
--cc=jianghaoran@kylinos.cn \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=yangtiezhu@loongson.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox