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 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.