All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Aneesh Kumar K.V <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>,
	Catalin Marinas <catalin.marinas@arm.com>,
	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 3/4] arm64: mte: update code comments
Date: Mon, 28 Oct 2024 18:09:05 +0000	[thread overview]
Message-ID: <87ldy8t7zy.wl-maz@kernel.org> (raw)
In-Reply-To: <yq5attcwcs2l.fsf@kernel.org>

On Mon, 28 Oct 2024 12:47:30 +0000,
Aneesh Kumar K.V <aneesh.kumar@kernel.org> wrote:
> 
> >> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> >> index a509b63bd4dd..b5824e93cee0 100644
> >> --- a/arch/arm64/kvm/mmu.c
> >> +++ b/arch/arm64/kvm/mmu.c
> >> @@ -1390,11 +1390,8 @@ 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.
> >
> > How? This comment is pretty content-free. TO be useful, you should
> > elaborate on *how* these two are used together.
> >
> 
> I will add more details described in commit d77e59a8fccde7fb5dd8c57594ed147b4291c970
> Should i quote the commit there in the comment?

The commit is not relevant. What is important is an indication of how
the race is resolved if that's important. A reference to
try_page_mte_tagging() would probably be the right thing to do.

> 
> >
> >>   */
> >>  static void sanitise_mte_tags(struct kvm *kvm, kvm_pfn_t pfn,
> >>  			      unsigned long size)
> >> @@ -1646,7 +1643,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> >>  	}
> >>  
> >>  	if (!fault_is_perm && !device && kvm_has_mte(kvm)) {
> >> -		/* Check the VMM hasn't introduced a new disallowed VMA */
> >> +		/*
> >> +		 *  not a permission fault implies a translation fault which
> >> +		 *  means mapping the page for the first time
> >
> > How about an Access fault due to page ageing?
> >
> 
> IIUC access fault is already handled by the caller kvm_handle_guest_abort?
> I can add that as part of the updated comments?

Maybe. The thing is, you are removing a pretty essential comment for
no good reason, and now there is no rational left behind the -EFAULT
that is returned.

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2024-10-28 18:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-28  9:40 [PATCH 0/4] Add support for NoTagAccess memory attribute Aneesh Kumar K.V (Arm)
2024-10-28  9:40 ` [PATCH 1/4] arm64: Update the values to binary from hex Aneesh Kumar K.V (Arm)
2024-10-28  9:40 ` [PATCH 2/4] arm64: cpufeature: add Allocation Tag Access Permission (MTE_PERM) feature Aneesh Kumar K.V (Arm)
2024-10-28  9:40 ` [PATCH 3/4] arm64: mte: update code comments Aneesh Kumar K.V (Arm)
2024-10-28 10:33   ` Marc Zyngier
2024-10-28 12:47     ` Aneesh Kumar K.V
2024-10-28 18:09       ` Marc Zyngier [this message]
2024-10-28  9:40 ` [PATCH 4/4] arm64: mte: Use stage-2 NoTagAccess memory attribute if supported Aneesh Kumar K.V (Arm)
2024-10-28 10:54   ` Marc Zyngier
2024-10-28 13:28     ` Aneesh Kumar K.V
2024-10-28 18:37       ` Marc Zyngier
2024-11-08  7:59         ` Aneesh Kumar K.V
2024-11-12 11:51           ` Marc Zyngier
2024-11-15 16:23             ` Catalin Marinas
2024-10-28 14:44   ` Oliver Upton
2024-10-28 14:52     ` Aneesh Kumar K.V
2024-10-28 15:07       ` Oliver Upton

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=87ldy8t7zy.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Suzuki.Poulose@arm.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --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=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.