From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Steven Price <steven.price@arm.com>,
Yang Shi <yang@os.amperecomputing.com>,
David Hildenbrand <david@kernel.org>,
Fuad Tabba <tabba@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] KVM: arm64: Clear the whole hugetlb folio when sanitising MTE tags
Date: Tue, 20 Oct 2026 12:52:54 +0100 [thread overview]
Message-ID: <atdUzfOA1Obd7Mir@gremlin> (raw)
In-Reply-To: <20261019132103.3836646-2-fuad.tabba@linux.dev>
hugetlb strikes again... :) the mm part of me apologises ;)
On Mon, Oct 19, 2026 at 02:21:01PM +0100, Fuad Tabba wrote:
> sanitise_mte_tags() clears the tags of the pages about to be mapped at
> stage-2 before marking them tagged. For a hugetlb folio the flag covers
> every page in the folio, but the loop only covers the mapping being
> installed. Stage-2 maps a folio in pieces for the contiguous hugetlb
> sizes, and for any size under dirty logging. The first fault then marks
> the whole folio after clearing only its own piece, and the rest keeps
> its previous owner's tags for the guest to read.
I'm guessing the folio size is always >= size here?
>
> Clear the whole folio, as mte_sync_tags() does.
>
> Fixes: 25c17c4b55def ("hugetlb: arm64: add mte support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
Some nits below but generally looks sensible to me so:
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> arch/arm64/kvm/mmu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 9ba86450fe4af..48a08b608ea72 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1514,7 +1514,8 @@ static void sanitise_mte_tags(struct kvm *kvm, kvm_pfn_t pfn,
> if (folio_test_hugetlb(folio)) {
> /* Hugetlb has MTE flags set on head page only */
Is this comment redundant now?
> if (folio_try_hugetlb_mte_tagging(folio)) {
> - for (i = 0; i < nr_pages; i++, page++)
> + page = folio_page(folio, 0);
> + for (i = 0; i < folio_nr_pages(folio); i++, page++)
I know it's a stable fix, but the fact that this pattern exists in multiple
places really argues for a mte_clear_folio_tags(), which would make this
trivially:
mte_clear_folio_tags(folio);
And avoid the re-use of page etc.
It's not a huge change and makes the next patch in the series simpler too so
arguably could be part of the series?
> mte_clear_page_tags(page_address(page));
> folio_set_hugetlb_mte_tagged(folio);
> }
> --
> 2.47.3
>
>
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-10-20 11:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 13:21 [PATCH 0/3] KVM: arm64: Fix stale MTE tags reaching a guest Fuad Tabba
2026-10-19 13:21 ` [PATCH 1/3] KVM: arm64: Clear the whole hugetlb folio when sanitising MTE tags Fuad Tabba
2026-10-20 11:52 ` Lorenzo Stoakes (ARM) [this message]
2026-10-20 13:09 ` Fuad Tabba
2026-10-20 13:16 ` Lorenzo Stoakes (ARM)
2026-10-20 13:22 ` Fuad Tabba
2026-10-19 13:21 ` [PATCH 2/3] KVM: arm64: Clear the whole hugetlb folio when storing " Fuad Tabba
2026-10-20 11:58 ` Lorenzo Stoakes (ARM)
2026-10-20 13:11 ` Fuad Tabba
2026-10-20 13:17 ` Lorenzo Stoakes (ARM)
2026-10-19 13:21 ` [PATCH 3/3] KVM: arm64: Sanitise MTE tags when a permission fault installs a mapping Fuad Tabba
2026-10-20 12:14 ` Lorenzo Stoakes (ARM)
2026-10-20 13:17 ` Fuad Tabba
2026-10-20 13:20 ` Lorenzo Stoakes (ARM)
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=atdUzfOA1Obd7Mir@gremlin \
--to=ljs@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.com \
--cc=yuzenghui@huawei.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 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.