From: Ryan Roberts <ryan.roberts@arm.com>
To: Yang Shi <yang@os.amperecomputing.com>,
dev.jain@arm.com, cl@gentwo.org, catalin.marinas@arm.com,
will@kernel.org
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] arm64: mm: make linear mapping permission update more robust for patial range
Date: Tue, 14 Oct 2025 09:05:05 +0100 [thread overview]
Message-ID: <973e36b9-e89a-43b2-bb85-b00343dd4e36@arm.com> (raw)
In-Reply-To: <20251013232803.3065100-2-yang@os.amperecomputing.com>
On 14/10/2025 00:27, Yang Shi wrote:
> The commit fcf8dda8cc48 ("arm64: pageattr: Explicitly bail out when changing
> permissions for vmalloc_huge mappings") made permission update for
> partial range more robust. But the linear mapping permission update
> still assumes update the whole range by iterating from the first page
> all the way to the last page of the area.
>
> Make it more robust by updating the linear mapping permission from the
> page mapped by start address, and update the number of numpages.
>
> Fixes: fcf8dda8cc48 ("arm64: pageattr: Explicitly bail out when changing permissions for vmalloc_huge mappings")
I don't think this is the correct commit. I think this theoretical issue was
present before that. But it is only theoretical AFAIK? In which case, I'd be
inclined to just drop the tag.
Otherwise, LGTM:
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
> ---
> arch/arm64/mm/pageattr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 5135f2d66958..c21a2c319028 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -148,7 +148,6 @@ static int change_memory_common(unsigned long addr, int numpages,
> unsigned long size = PAGE_SIZE * numpages;
> unsigned long end = start + size;
> struct vm_struct *area;
> - int i;
>
> if (!PAGE_ALIGNED(addr)) {
> start &= PAGE_MASK;
> @@ -184,8 +183,9 @@ static int change_memory_common(unsigned long addr, int numpages,
> */
> if (rodata_full && (pgprot_val(set_mask) == PTE_RDONLY ||
> pgprot_val(clear_mask) == PTE_RDONLY)) {
> - for (i = 0; i < area->nr_pages; i++) {
> - __change_memory_common((u64)page_address(area->pages[i]),
> + unsigned long idx = (start - (unsigned long)area->addr) >> PAGE_SHIFT;
> + for (int i = 0; i < numpages; i++) {
> + __change_memory_common((u64)page_address(area->pages[idx++]),
> PAGE_SIZE, set_mask, clear_mask);
> }
> }
next prev parent reply other threads:[~2025-10-14 8:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 23:27 [PATCH 0/2] Two minor fixes for BBML2_NOABORT Yang Shi
2025-10-13 23:27 ` [PATCH 1/2] arm64: mm: make linear mapping permission update more robust for patial range Yang Shi
2025-10-14 8:05 ` Ryan Roberts [this message]
2025-10-14 20:15 ` Yang Shi
2025-10-15 6:46 ` Dev Jain
2025-10-16 18:45 ` Yang Shi
2025-10-16 18:47 ` Dev Jain
2025-10-13 23:27 ` [PATCH 2/2] arm64: mm: relax VM_ALLOW_HUGE_VMAP if BBML2_NOABORT is supported Yang Shi
2025-10-14 8:08 ` Ryan Roberts
2025-10-14 20:23 ` Yang Shi
2025-10-15 6:50 ` Dev Jain
2025-10-16 18:50 ` Yang Shi
2025-10-17 15:50 ` Dev Jain
2025-10-30 13:16 ` Will Deacon
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=973e36b9-e89a-43b2-bb85-b00343dd4e36@arm.com \
--to=ryan.roberts@arm.com \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=dev.jain@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.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