From: Yang Shi <yang@os.amperecomputing.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: will@kernel.org, ryan.roberts@arm.com, akpm@linux-foundation.org,
david@redhat.com, lorenzo.stoakes@oracle.com, ardb@kernel.org,
dev.jain@arm.com, scott@os.amperecomputing.com, cl@gentwo.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v8 5/5] arm64: kprobes: call set_memory_rox() for kprobe page
Date: Thu, 18 Sep 2025 08:05:55 -0700 [thread overview]
Message-ID: <22732cbe-20f8-4d1e-b086-e34d0f9bbb35@os.amperecomputing.com> (raw)
In-Reply-To: <aMv_nhEuCSHKp5J6@arm.com>
On 9/18/25 5:48 AM, Catalin Marinas wrote:
> On Wed, Sep 17, 2025 at 12:02:11PM -0700, Yang Shi wrote:
>> The kprobe page is allocated by execmem allocator with ROX permission.
>> It needs to call set_memory_rox() to set proper permission for the
>> direct map too. It was missed.
>>
>> And the set_memory_rox() guarantees the direct map will be split if it
>> needs so that set_direct_map calls in vfree() won't fail.
>>
>> Fixes: 10d5e97c1bf8 ("arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page")
>> Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
>> ---
>> arch/arm64/kernel/probes/kprobes.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
>> index 0c5d408afd95..c4f8c4750f1e 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -10,6 +10,7 @@
>>
>> #define pr_fmt(fmt) "kprobes: " fmt
>>
>> +#include <linux/execmem.h>
>> #include <linux/extable.h>
>> #include <linux/kasan.h>
>> #include <linux/kernel.h>
>> @@ -41,6 +42,17 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>> static void __kprobes
>> post_kprobe_handler(struct kprobe *, struct kprobe_ctlblk *, struct pt_regs *);
>>
>> +void *alloc_insn_page(void)
>> +{
>> + void *page;
> Nit: I'd call this 'addr'. 'page' makes me think of a struct page.
Sure.
>
>> +
>> + page = execmem_alloc(EXECMEM_KPROBES, PAGE_SIZE);
>> + if (!page)
>> + return NULL;
>> + set_memory_rox((unsigned long)page, 1);
> It's unfortunate that we change the attributes of the ROX vmap first to
> RO, then to back to ROX so that we get the linear map changed. Maybe
> factor out some of the code in change_memory_common() to only change the
> linear map.
I want to make sure I understand you correctly, you meant
set_memory_rox() should do:
change linear map to RO (call a new helper, for example,
set_direct_map_ro())
change vmap to ROX (call change_memory_common())
Is it correct?
If so set_memory_ro() should do the similar thing.
And I think we should have the cleanup patch separate from this bug fix
patch because the bug fix patch should be applied to -stable release
too. Keeping it simpler makes the backport easier.
Shall I squash the cleanup patch into patch #1?
Thanks,
Yang
>
> Otherwise it looks fine.
>
next prev parent reply other threads:[~2025-09-18 15:06 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 19:02 [PATCH v8 0/5] arm64: support FEAT_BBM level 2 and large block mapping when rodata=full Yang Shi
2025-09-17 19:02 ` [PATCH v8 1/5] arm64: Enable permission change on arm64 kernel block mappings Yang Shi
2025-09-17 19:02 ` [PATCH v8 2/5] arm64: cpufeature: add AmpereOne to BBML2 allow list Yang Shi
2025-09-17 19:02 ` [PATCH v8 3/5] arm64: mm: support large block mapping when rodata=full Yang Shi
2025-11-01 16:14 ` Guenter Roeck
2025-11-02 10:31 ` Ryan Roberts
2025-11-02 12:11 ` Ryan Roberts
2025-11-02 15:13 ` Guenter Roeck
2025-11-02 17:46 ` Guenter Roeck
2025-11-02 17:49 ` Guenter Roeck
2025-11-02 17:52 ` Guenter Roeck
2025-11-03 0:47 ` Yang Shi
2025-11-03 10:07 ` Ryan Roberts
2025-11-03 16:21 ` Yang Shi
2025-11-03 5:53 ` Dev Jain
2025-09-17 19:02 ` [PATCH v8 4/5] arm64: mm: split linear mapping if BBML2 unsupported on secondary CPUs Yang Shi
2026-02-02 7:18 ` Arnd Bergmann
2026-02-02 7:43 ` Ard Biesheuvel
2026-02-02 8:11 ` Arnd Bergmann
2025-09-17 19:02 ` [PATCH v8 5/5] arm64: kprobes: call set_memory_rox() for kprobe page Yang Shi
2025-09-18 12:48 ` Catalin Marinas
2025-09-18 15:05 ` Yang Shi [this message]
2025-09-18 15:30 ` Ryan Roberts
2025-09-18 15:50 ` Yang Shi
2025-09-18 15:32 ` Catalin Marinas
2025-09-18 15:48 ` Yang Shi
2025-09-18 21:10 ` [PATCH v8 0/5] arm64: support FEAT_BBM level 2 and large block mapping when rodata=full Will Deacon
2025-09-19 10:08 ` Ryan Roberts
2025-09-19 11:27 ` Will Deacon
2025-09-19 11:49 ` Ryan Roberts
2025-09-19 11:56 ` Will Deacon
2025-09-19 12:00 ` Ryan Roberts
2025-09-19 18:44 ` Will Deacon
2025-09-23 7:15 ` Ryan Roberts
2025-09-19 14:55 ` Yang Shi
2026-03-16 7:35 ` Jinjiang Tu
2026-03-16 15:47 ` Ryan Roberts
2026-03-17 0:15 ` Yang Shi
2026-03-17 2:06 ` Jinjiang Tu
2026-03-17 9:07 ` Ryan Roberts
2026-03-17 17:03 ` Yang Shi
2026-03-18 8:29 ` Jinjiang Tu
2026-03-18 9:17 ` Ryan Roberts
2026-03-19 1:22 ` Jinjiang Tu
2026-03-17 17:12 ` Yang Shi
2026-03-17 8:47 ` Kevin Brodsky
2026-03-17 9:13 ` Ryan Roberts
2026-03-17 9:29 ` Kevin Brodsky
2026-03-17 11:45 ` Ryan Roberts
2026-03-17 12:43 ` Kevin Brodsky
2026-03-17 15:05 ` Ryan Roberts
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=22732cbe-20f8-4d1e-b086-e34d0f9bbb35@os.amperecomputing.com \
--to=yang@os.amperecomputing.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=ryan.roberts@arm.com \
--cc=scott@os.amperecomputing.com \
--cc=will@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.