From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC45A1B4257; Fri, 6 Mar 2026 12:27:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772800022; cv=none; b=Yl0kKKS2MCmRyq9q3pUVyOwzjUQ3ZZ1oQPbeRJzBNJhJ3L7wF8NpNzbCRUhNxv3uVAe3xrrwAYSWg6cUg1GKUR6H9PL6vQC5V2UABStBZCjWbNHWqweR/JDdJj5fQAHWG/QaOMLsCZlcUxe9TVIR/GTRRmrPRdynCpdqnanlZck= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772800022; c=relaxed/simple; bh=7Hk7fAZvQF0ye88ruxvV6p3f98XYs2WUnmaeYiPvIvM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HDtpjA27zzceq59fvQnKCpGp8xgvAaYiybDa3zNXKqSUo/4zjG0jd2fLB/GzhYmquCcXfufO8RlROh/0RAI2X9hSVjC6AFiStO9Ne/oWPW99Y6YS16YlMCnYWfgViZ1r0+V9Xt0Lbi9au5hcHcdGL4PODJBvVqV2h4rnHUCoiDI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UqhzYvMQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UqhzYvMQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAF5EC4CEF7; Fri, 6 Mar 2026 12:26:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772800022; bh=7Hk7fAZvQF0ye88ruxvV6p3f98XYs2WUnmaeYiPvIvM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UqhzYvMQwShy+yX4ebcbqbL3BTg7VeWu+fXcy9+1csqA9F/dXEuQrIdJpJZu+7/L0 5TgSSRj+V3KcV7JHs2tslveU3OM/HEYLlNmh+4YUzsoBAh4S6ubp5FHWLY5EUcu9EQ OkVIHTdTid6voTnxnBvJKAlGOAF3Ripzjnz7eDX//RBm/16v4Hna2W4f4iFMguIVUB +9hIYILu+nbENLitc+lrZibMpnr/KTamNWDgb9h8+w/LtfkCWWYWjCazcILWVhZQlq BXBIEmeXIrmRql3AlTl5ui/O85GYlhV2RXy+Jqajab5bro4mwmJz5963mPzfM8Nggo OZZrrPC3nNl1w== From: Will Deacon To: Catalin Marinas , Ard Biesheuvel , Ryan Roberts , Mark Rutland , Andrew Morton , Piotr Jaroszynski Cc: kernel-team@android.com, Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, John Hubbard , Zi Yan , Breno Leitao , stable@vger.kernel.org, Alistair Popple , James Houghton , Jason Gunthorpe Subject: Re: [PATCH v2] arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults Date: Fri, 6 Mar 2026 12:26:52 +0000 Message-ID: <177279636044.453548.11482786576662988237.b4-ty@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260305-contpte-fault-loop-v2-1-0216f0026d7f@nvidia.com> References: <20260305-contpte-fault-loop-v2-1-0216f0026d7f@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, 05 Mar 2026 15:26:29 -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. > > [...] Applied to arm64 (for-next/fixes), thanks! [1/1] arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults https://git.kernel.org/arm64/c/97c5550b7631 Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev