From: Catalin Marinas <catalin.marinas@arm.com>
To: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
Suzuki K Poulose <Suzuki.Poulose@arm.com>,
Steven Price <steven.price@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Joey Gouly <joey.gouly@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v2 2/7] KVM: arm64: MTE: Update code comments
Date: Fri, 10 Jan 2025 13:11:10 +0000 [thread overview]
Message-ID: <Z4Ecbi9QUScEstCQ@arm.com> (raw)
In-Reply-To: <20250110110023.2963795-3-aneesh.kumar@kernel.org>
On Fri, Jan 10, 2025 at 04:30:18PM +0530, Aneesh Kumar K.V (Arm) wrote:
> commit d77e59a8fccd ("arm64: mte: Lock a page for MTE tag
> initialisation") updated the locking such the kernel now allows
> VM_SHARED mapping with MTE. Update the code comment to reflect this.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/arm64/kvm/mmu.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index c9d46ad57e52..eb8220a409e1 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1391,11 +1391,11 @@ static int get_vma_page_shift(struct vm_area_struct *vma, unsigned long hva)
> * able to see the page's tags and therefore they must be initialised first. If
> * PG_mte_tagged is set, tags have already been initialised.
> *
> - * The race in the test/set of the PG_mte_tagged flag is handled by:
> - * - preventing VM_SHARED mappings in a memslot with MTE preventing two VMs
> - * racing to santise the same page
> - * - mmap_lock protects between a VM faulting a page in and the VMM performing
> - * an mprotect() to add VM_MTE
> + * The race in the test/set of the PG_mte_tagged flag is handled by using
> + * PG_mte_lock and PG_mte_tagged together. if PG_mte_lock is found unset, we can
> + * go ahead and clear the page tags. if PG_mte_lock is found set, then the page
> + * tags are already cleared or there is a parallel tag clearing is going on. We
^^^^^^^^
remove this (or the other 'is')
> + * wait for the parallel tag clear to finish by waiting on PG_mte_tagged bit.
> */
I don't think we need to describe the behaviour of set_page_mte_tagged()
and try_page_mte_tagging() in here. How the locking works for tagged
pages was hidden in those functions with their own documentation. I
would just remove this whole paragraph here, just leave the first one
stating that the tags must be initialised if not already done so.
--
Catalin
next prev parent reply other threads:[~2025-01-10 13:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-10 11:00 [PATCH v2 0/7] Add support for NoTagAccess memory attribute Aneesh Kumar K.V (Arm)
2025-01-10 11:00 ` [PATCH v2 1/7] arm64: Update the values to binary from hex Aneesh Kumar K.V (Arm)
2025-01-10 13:11 ` Catalin Marinas
2025-01-10 11:00 ` [PATCH v2 2/7] KVM: arm64: MTE: Update code comments Aneesh Kumar K.V (Arm)
2025-01-10 13:11 ` Catalin Marinas [this message]
2025-01-10 11:00 ` [PATCH v2 3/7] arm64: cpufeature: add Allocation Tag Access Permission (MTE_PERM) feature Aneesh Kumar K.V (Arm)
2025-01-10 13:15 ` Catalin Marinas
2025-01-10 11:00 ` [PATCH v2 4/7] KVM: arm64: MTE: Add KVM_CAP_ARM_MTE_PERM Aneesh Kumar K.V (Arm)
2025-01-10 11:00 ` [PATCH v2 5/7] KVM: arm64: MTE: Use stage-2 NoTagAccess memory attribute if supported Aneesh Kumar K.V (Arm)
2025-01-10 18:20 ` Catalin Marinas
2025-01-11 13:19 ` Aneesh Kumar K.V
2025-01-13 19:09 ` Catalin Marinas
2025-01-13 20:47 ` Peter Collingbourne
2025-01-14 9:55 ` Suzuki K Poulose
2025-01-15 13:15 ` Catalin Marinas
2025-01-28 10:31 ` Aneesh Kumar K.V
2025-01-29 14:38 ` Catalin Marinas
2025-01-10 11:00 ` [PATCH v2 6/7] KVM: arm64: MTE: Nested guest support Aneesh Kumar K.V (Arm)
2025-01-10 11:00 ` [PATCH v2 7/7] KVM: arm64: Split some of the kvm_pgtable_prot bits into separate defines Aneesh Kumar K.V (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=Z4Ecbi9QUScEstCQ@arm.com \
--to=catalin.marinas@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=aneesh.kumar@kernel.org \
--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=oliver.upton@linux.dev \
--cc=steven.price@arm.com \
--cc=will@kernel.org \
--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.