linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Piotr Jaroszynski <pjaroszynski@nvidia.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
	Alistair Popple <apopple@nvidia.com>,
	John Hubbard <jhubbard@nvidia.com>, Zi Yan <ziy@nvidia.com>,
	Breno Leitao <leitao@debian.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH] arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults
Date: Wed, 4 Mar 2026 15:01:51 +0000	[thread overview]
Message-ID: <aahJX0NwtYHy1ILe@arm.com> (raw)
In-Reply-To: <20260304134313.GM972761@nvidia.com>

On Wed, Mar 04, 2026 at 09:43:13AM -0400, Jason Gunthorpe wrote:
> On Wed, Mar 04, 2026 at 11:17:08AM +0000, Catalin Marinas wrote:
> > > @@ -399,13 +416,35 @@ int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
> > >  	int i;
> > >  
> > >  	/*
> > > -	 * Gather the access/dirty bits for the contiguous range. If nothing has
> > > -	 * changed, its a noop.
> > > +	 * Check whether all sub-PTEs in the CONT block already have the
> > > +	 * requested access flags, using raw per-PTE values rather than the
> > > +	 * gathered ptep_get() view.
> > > +	 *
> > > +	 * ptep_get() gathers AF/dirty state across the whole CONT block,
> > > +	 * which is correct for CPU TLB semantics: with FEAT_HAFDBS the
> > > +	 * hardware may set AF/dirty on any sub-PTE and the CPU TLB treats
> > > +	 * the gathered result as authoritative for the entire range. But an
> > > +	 * SMMU without HTTU (or with HA/HD disabled in CD.TCR) evaluates
> > > +	 * each descriptor individually and will keep faulting on the target
> > > +	 * sub-PTE if its flags haven't actually been updated. Gathering can
> > > +	 * therefore cause false no-ops when only a sibling has been updated:
> > > +	 *  - write faults: target still has PTE_RDONLY (needs PTE_RDONLY cleared)
> > > +	 *  - read faults:  target still lacks PTE_AF
> > > +	 *
> > > +	 * Per Arm ARM (DDI 0487) D8.7.1, any sub-PTE in a CONT range may
> > > +	 * become the effective cached translation, so all entries must have
> > > +	 * consistent attributes. Check the full CONT block before returning
> > > +	 * no-op, and when any sub-PTE mismatches, proceed to update the whole
> > > +	 * range.
> > >  	 */
> > > -	orig_pte = pte_mknoncont(ptep_get(ptep));
> > > -	if (pte_val(orig_pte) == pte_val(entry))
> > > +	if (contpte_all_subptes_match_access_flags(ptep, entry))
> > >  		return 0;
> > 
> > Actually, do we need to loop over all the ptes? I think it sufficient to
> > only check the one at ptep since it is the one that triggered the
> > fault.
> 
> With CONT we should not be thinking "the one that triggered the
> fault".
> 
> The PTE that triggered the fault is the PTE that the HW happened to
> load into the TLB, we cannot assume it is the sub PTE we are faulting
> at. For instance it could be a sub PTE for a completely unrelated
> access at a different VA that got cached.

Good point. For the AF bit, the hardware is not allowed to cache it in
the TLB, so we can't get an AF fault for an unrelated VA nearby. We can,
however, for the dirty bit since PTE_RDONLY is allowed to be cached in
the TLB.

> Again, the requirement here is that a fault on a CONT PTE must fix all
> the access flags to be consistent or fail. It cannot resume the fault
> and leave the sub PTEs inconsistent as the HW is always allowed to
> load the RDONLY one for any access to the CONT.

It should fix all of them to be consistent if it got a fault. I was
wondering whether we can simplify this with a single pte read (but still
setting all in the range). It only works for the AF bit, not dirty. We
could add a check if it makes things slightly faster on this path.

Now I also wonder if the `pte_write(orig_pte) == pte_write(entry)` check
to elide BBM is still valid if we have hardware that does not support
DBM. I need to dig some more into the Arm ARM.

-- 
Catalin


  reply	other threads:[~2026-03-04 15:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-03  6:37 Piotr Jaroszynski
2026-03-03  7:19 ` James Houghton
2026-03-03 12:45   ` Jason Gunthorpe
2026-03-03 21:40   ` Piotr Jaroszynski
2026-03-03  8:38 ` Ryan Roberts
2026-03-03 18:40   ` Piotr Jaroszynski
2026-03-03 19:12     ` Jason Gunthorpe
2026-03-04 12:20       ` Ryan Roberts
2026-03-04 13:44         ` Jason Gunthorpe
2026-03-04 11:17 ` Catalin Marinas
2026-03-04 13:43   ` Jason Gunthorpe
2026-03-04 15:01     ` Catalin Marinas [this message]
2026-03-04 15:39       ` Jason Gunthorpe

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=aahJX0NwtYHy1ILe@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=apopple@nvidia.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=leitao@debian.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=pjaroszynski@nvidia.com \
    --cc=ryan.roberts@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=will@kernel.org \
    --cc=ziy@nvidia.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