From: Kevin Brodsky <kevin.brodsky@arm.com>
To: Ryan Roberts <ryan.roberts@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
"David Hildenbrand (Arm)" <david@kernel.org>,
Dev Jain <dev.jain@arm.com>,
Yang Shi <yang@os.amperecomputing.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Jinjiang Tu <tujinjiang@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v1 2/3] arm64: mm: Handle invalid large leaf mappings correctly
Date: Mon, 23 Mar 2026 17:52:53 +0100 [thread overview]
Message-ID: <588b2b4f-9cf6-43e5-b0e5-55820c74cbbb@arm.com> (raw)
In-Reply-To: <20260323130317.1737522-3-ryan.roberts@arm.com>
On 23/03/2026 14:03, Ryan Roberts wrote:
> [...]
>
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 358d1dc9a576f..87dfe4c82fa92 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -25,6 +25,11 @@ static ptdesc_t set_pageattr_masks(ptdesc_t val, struct mm_walk *walk)
> {
> struct page_change_data *masks = walk->private;
>
> + /*
> + * Some users clear and set bits which alias eachother (e.g. PTE_NG and
Nit: "each other"
> + * PTE_PRESENT_INVALID). It is therefore important that we always clear
> + * first then set.
> + */
> val &= ~(pgprot_val(masks->clear_mask));
> val |= (pgprot_val(masks->set_mask));
>
> @@ -36,7 +41,7 @@ static int pageattr_pud_entry(pud_t *pud, unsigned long addr,
> {
> pud_t val = pudp_get(pud);
>
> - if (pud_sect(val)) {
> + if (pud_leaf(val)) {
> if (WARN_ON_ONCE((next - addr) != PUD_SIZE))
> return -EINVAL;
> val = __pud(set_pageattr_masks(pud_val(val), walk));
> @@ -52,7 +57,7 @@ static int pageattr_pmd_entry(pmd_t *pmd, unsigned long addr,
> {
> pmd_t val = pmdp_get(pmd);
>
> - if (pmd_sect(val)) {
> + if (pmd_leaf(val)) {
> if (WARN_ON_ONCE((next - addr) != PMD_SIZE))
> return -EINVAL;
> val = __pmd(set_pageattr_masks(pmd_val(val), walk));
> @@ -132,11 +137,12 @@ static int __change_memory_common(unsigned long start, unsigned long size,
> ret = update_range_prot(start, size, set_mask, clear_mask);
>
> /*
> - * If the memory is being made valid without changing any other bits
> - * then a TLBI isn't required as a non-valid entry cannot be cached in
> - * the TLB.
> + * If the memory is being switched from present-invalid to valid without
> + * changing any other bits then a TLBI isn't required as a non-valid
> + * entry cannot be cached in the TLB.
> */
> - if (pgprot_val(set_mask) != PTE_VALID || pgprot_val(clear_mask))
> + if (pgprot_val(set_mask) != (PTE_MAYBE_NG | PTE_VALID) ||
It isn't obvious to understand where all those PTE_MAYBE_NG come from if
one hasn't realised that PTE_PRESENT_INVALID overlays PTE_NG.
Since for this purpose we always set/clear both PTE_VALID and
PTE_MAYBE_NG, maybe we could define some macro as PTE_VALID |
PTE_MAYBE_NG, as a counterpart to PTE_PRESENT_INVALID?
- Kevin
> [...]
next prev parent reply other threads:[~2026-03-23 16:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 13:03 [PATCH v1 0/3] Fix bugs for realm guest plus BBML2_NOABORT Ryan Roberts
2026-03-23 13:03 ` [PATCH v1 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests Ryan Roberts
2026-03-23 16:52 ` Kevin Brodsky
2026-03-23 17:20 ` Ryan Roberts
2026-03-23 21:34 ` Yang Shi
2026-03-25 17:29 ` Ryan Roberts
2026-03-27 20:49 ` Yang Shi
2026-03-23 13:03 ` [PATCH v1 2/3] arm64: mm: Handle invalid large leaf mappings correctly Ryan Roberts
2026-03-23 16:52 ` Kevin Brodsky [this message]
2026-03-23 17:25 ` Ryan Roberts
2026-03-23 19:56 ` Kevin Brodsky
2026-03-24 2:30 ` Jinjiang Tu
2026-03-25 17:31 ` Ryan Roberts
2026-03-26 1:54 ` Jinjiang Tu
2026-03-24 18:20 ` Yang Shi
2026-03-25 17:37 ` Ryan Roberts
2026-03-27 20:46 ` Yang Shi
2026-03-23 13:03 ` [PATCH v1 3/3] arm64: mm: Remove pmd_sect() and pud_sect() 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=588b2b4f-9cf6-43e5-b0e5-55820c74cbbb@arm.com \
--to=kevin.brodsky@arm.com \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ryan.roberts@arm.com \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tujinjiang@huawei.com \
--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
all inboxes | Powered by JetHome®