From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Xueyuan Chen <xueyuan.chen21@gmail.com>,
akpm@linux-foundation.org, ljs@kernel.org, usama.arif@linux.dev,
catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
rppt@kernel.org, ryan.roberts@arm.com, ziy@nvidia.com,
baohua@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Lance Yang <lance.yang@linux.dev>
Subject: Re: [PATCH v6 2/3] arm64/mm: add set_direct_map_ro_noflush()
Date: Tue, 25 Aug 2026 18:46:49 +0200 [thread overview]
Message-ID: <86823e2b-f739-4ebe-b92f-a35b9dcfa0c7@kernel.org> (raw)
In-Reply-To: <ao3GXvT2ltf89_rG@willie-the-truck>
On 8/25/26 18:44, Will Deacon wrote:
> On Tue, Aug 25, 2026 at 05:52:20PM +0200, David Hildenbrand (Arm) wrote:
>> On 7/30/26 11:06, Xueyuan Chen wrote:
>>> Implement set_direct_map_ro_noflush() for arm64 with update_range_prot() on
>>> the linear map, setting PTE_RDONLY and clearing PTE_WRITE. Keep the
>>> existing can_set_direct_map() guard and leave TLB invalidation to the
>>> caller.
>>>
>>> Co-developed-by: Lance Yang <lance.yang@linux.dev>
>>> Signed-off-by: Lance Yang <lance.yang@linux.dev>
>>> Signed-off-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
>>> ---
>>> arch/arm64/include/asm/set_memory.h | 2 ++
>>> arch/arm64/mm/pageattr.c | 10 ++++++++++
>>> 2 files changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/include/asm/set_memory.h b/arch/arm64/include/asm/set_memory.h
>>> index 90f61b17275e..7083260303c3 100644
>>> --- a/arch/arm64/include/asm/set_memory.h
>>> +++ b/arch/arm64/include/asm/set_memory.h
>>> @@ -14,6 +14,8 @@ int set_memory_valid(unsigned long addr, int numpages, int enable);
>>> int set_direct_map_invalid_noflush(struct page *page);
>>> int set_direct_map_default_noflush(struct page *page);
>>> int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid);
>>> +int set_direct_map_ro_noflush(const void *addr, unsigned long nr_pages);
>>> +#define set_direct_map_ro_noflush set_direct_map_ro_noflush
>>> bool kernel_page_present(struct page *page);
>>>
>>> int set_memory_encrypted(unsigned long addr, int numpages);
>>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>>> index ce035e1b4eaf..c51236b61651 100644
>>> --- a/arch/arm64/mm/pageattr.c
>>> +++ b/arch/arm64/mm/pageattr.c
>>> @@ -365,6 +365,16 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
>>> return set_memory_valid(addr, nr, valid);
>>> }
>>>
>>> +int set_direct_map_ro_noflush(const void *addr, unsigned long nr_pages)
>>> +{
>>> + if (!can_set_direct_map())
>>> + return 0;
>>> +
>>> + return update_range_prot((unsigned long)addr, PAGE_SIZE * nr_pages,
>>> + __pgprot(PTE_RDONLY),
>>> + __pgprot(PTE_WRITE));
>>> +}
>>> +
>>> #ifdef CONFIG_DEBUG_PAGEALLOC
>>> /*
>>> * This is - apart from the return value - doing the same
>>
>> We'll need an ACK from arm64 maintaines. To me this looks good.
>
> I generally dislike deferring critical things like TLB invalidation to
> the caller, so it would be good to see an example of a caller that really
> needs that. The caller in patch 1 unconditionally calls
> flush_tlb_kernel_range() immediately after calling
> set_direct_map_ro_noflush().
>
> In fact, that means we have a pointless invalidation if
> !can_set_direct_map(). See exhibit A :)
Ack. I recall that the patch set originally didn't do any flushes, but we really
have to flush even though we are early during boot.
So agreed, the interface should just flush internally.
--
Cheers,
David
next prev parent reply other threads:[~2026-08-25 16:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 9:06 [PATCH v6 0/3] mm: make persistent huge zero folio read-only Xueyuan Chen
2026-07-30 9:06 ` [PATCH v6 1/3] " Xueyuan Chen
2026-08-25 15:51 ` David Hildenbrand (Arm)
2026-08-25 16:29 ` Dave Hansen
2026-07-30 9:06 ` [PATCH v6 2/3] arm64/mm: add set_direct_map_ro_noflush() Xueyuan Chen
2026-08-25 15:52 ` David Hildenbrand (Arm)
2026-08-25 16:44 ` Will Deacon
2026-08-25 16:46 ` David Hildenbrand (Arm) [this message]
2026-08-26 7:53 ` Xueyuan Chen
2026-07-30 9:06 ` [PATCH v6 3/3] x86/mm: " Xueyuan Chen
2026-08-25 15:52 ` David Hildenbrand (Arm)
2026-08-25 16:18 ` Dave Hansen
2026-08-25 16:43 ` David Hildenbrand (Arm)
2026-08-25 16:57 ` Dave Hansen
2026-08-25 17:30 ` David Hildenbrand (Arm)
2026-08-26 12:19 ` Xueyuan Chen
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=86823e2b-f739-4ebe-b92f-a35b9dcfa0c7@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=lance.yang@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mingo@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=tglx@kernel.org \
--cc=usama.arif@linux.dev \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xueyuan.chen21@gmail.com \
--cc=ziy@nvidia.com \
/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