From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3A42D3A872B for ; Wed, 4 Mar 2026 11:17:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772623034; cv=none; b=alb+KQv9HMcgA/YyUd8ETkOofiRWAoHr1xQzdhpJEKv1vtNR9PbBMtlOt+AXJk12l//NdtzXj4suMM5uFmzUrA2m1QQ+knLsRjv+gRjnk+QKoRZ7+TnoSa/d5wGAgnFsFH4u/OCIZMK8vFR7A5pwK3/5dBuWt3NniqJaL6uvWts= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772623034; c=relaxed/simple; bh=lpe8sK3Q0K5JvrAeURp5jkJ2IjH8tbizxjGa24n/SIU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dACW5X21kS1eSdow+OSGJD7J/JcXq60mfWOkdhuAPuryXcWAjCvyvYBDoafdqrlrcWPEnwLIwVo1/RJN9Ve9nQh78nIAdl+TsK0D2Wspa+jz8vLEwPEWQms3knJlmU3ihl5/v26cez93Qcd396DRP0pM5UMrteYzCmrF+Oqu6pM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6921B339; Wed, 4 Mar 2026 03:17:06 -0800 (PST) Received: from arm.com (arrakis.cambridge.arm.com [10.1.197.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E71843F694; Wed, 4 Mar 2026 03:17:10 -0800 (PST) Date: Wed, 4 Mar 2026 11:17:08 +0000 From: Catalin Marinas To: Piotr Jaroszynski Cc: Ryan Roberts , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, Alistair Popple , Jason Gunthorpe , John Hubbard , Zi Yan , Breno Leitao , stable@vger.kernel.org Subject: Re: [PATCH] arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults Message-ID: References: <20260303063751.2531716-1-pjaroszynski@nvidia.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260303063751.2531716-1-pjaroszynski@nvidia.com> On Mon, Mar 02, 2026 at 10:37:51PM -0800, Piotr Jaroszynski wrote: > contpte_ptep_set_access_flags() compared the gathered ptep_get() value > against the requested entry to detect no-ops. ptep_get() ORs AF/dirty > from all sub-PTEs in the CONT block, so a dirty sibling can make the > target appear already-dirty. When the gathered value matches entry, the > function returns 0 even though the target sub-PTE still has PTE_RDONLY > set in hardware. > > For CPU page-table walks this is benign: 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 raising F_PERMISSION on the unchanged target > sub-PTE, causing an infinite fault loop. This can also happen if not all CPUs support the hardware updates of the AF/dirty bits. > diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c > index bcac4f55f9c1..9868bfe4607c 100644 > --- a/arch/arm64/mm/contpte.c > +++ b/arch/arm64/mm/contpte.c > @@ -390,6 +390,23 @@ void contpte_clear_young_dirty_ptes(struct vm_area_struct *vma, > } > EXPORT_SYMBOL_GPL(contpte_clear_young_dirty_ptes); > > +static bool contpte_all_subptes_match_access_flags(pte_t *ptep, pte_t entry) > +{ > + pte_t *cont_ptep = contpte_align_down(ptep); > + const pteval_t access_mask = PTE_RDONLY | PTE_AF | PTE_WRITE | PTE_DIRTY; > + pteval_t entry_access = pte_val(entry) & access_mask; > + int i; > + > + for (i = 0; i < CONT_PTES; i++) { > + pteval_t pte_access = pte_val(__ptep_get(cont_ptep + i)) & access_mask; > + > + if (pte_access != entry_access) > + return false; > + } > + > + return true; > +} > + > int contpte_ptep_set_access_flags(struct vm_area_struct *vma, > unsigned long addr, pte_t *ptep, > pte_t entry, int dirty) > @@ -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. Instead of ptep_get(ptep), use __ptep_get(ptep). The rest of the function sets the flags correctly for all the ptes in the contig range. -- Catalin