From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CC33CEDEBE0 for ; Tue, 3 Mar 2026 18:40:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A7896B009F; Tue, 3 Mar 2026 13:40:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 156ED6B00A0; Tue, 3 Mar 2026 13:40:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 029E16B00A1; Tue, 3 Mar 2026 13:40:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E38286B009F for ; Tue, 3 Mar 2026 13:40:13 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 824DC1B7467 for ; Tue, 3 Mar 2026 18:40:13 +0000 (UTC) X-FDA: 84505616706.27.11E8B90 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazon11012036.outbound.protection.outlook.com [40.93.195.36]) by imf12.hostedemail.com (Postfix) with ESMTP id 85CBC40014 for ; Tue, 3 Mar 2026 18:40:10 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=apf0YQzL; spf=pass (imf12.hostedemail.com: domain of pjaroszynski@nvidia.com designates 40.93.195.36 as permitted sender) smtp.mailfrom=pjaroszynski@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1772563210; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=i0kmCJMSGIvUOzhTIff6KcMV9QnY2cagi4V2X8P5nsc=; b=qvUvpXjpoR3fm8hE/EvKGTtSwELGbcoLCUfsRyEi3Afyw+Vx4aqEyEcWXYXZX02SV32+Vu qTf5VsgwgHiCerHYCRsd8SYUbPlwSwRumFHP+iO7930aAPmL5+zfJFExfO3fMnQVfX/Tih qPJvZEGFmlzdHwfOkMA1E1y9xFX5NEE= ARC-Authentication-Results: i=2; imf12.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=apf0YQzL; spf=pass (imf12.hostedemail.com: domain of pjaroszynski@nvidia.com designates 40.93.195.36 as permitted sender) smtp.mailfrom=pjaroszynski@nvidia.com; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1772563210; a=rsa-sha256; cv=pass; b=4kX41d8tNg7r00zwa3Dod1l0QBJADQTC0quqqcs0n9LPqfMgW8meaLjqAPHpblKd+CwV6V bCU60HPUqa6PV7QHpn9YyEHAy2PicdiDR1BO+D4sfnSOT+nTvNYFKoFqb00CpPUg4DjfEs wlG0dBI3bpXpXScnmaoIprTraeLJTl8= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gxaZ/qxJVYgx4gsHPCQTMUfkakjubJ7UatyWvzW8aPEczUMcpRh3BPI00BZ6+hO1s8r2D/iu9M8miDZZnrAezGcfWUIz+EyQ+uEcvAGo5+bMDJP3me+StvdK/3SOE8P8gudekx6pYab7G/OOLN56JDjgIMnQa3oqoxSuuXADfeRAPh9qeorRCZYZCdvnHRkdmLn3UKvvrLK6CQ4g5WPu09GZuRbRwNTDxUhlphoL/iobwmFbnNbr++CmQLjnZsOgK1d5NHuuoASD9g5i691AYFq8A+LU6M8ZjIvxJVDGBYGW+IzFTqpN9XKxZFVdgie1WLROCpUYaBlHuKFil52rpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i0kmCJMSGIvUOzhTIff6KcMV9QnY2cagi4V2X8P5nsc=; b=DQIiFFlZvU6OW7B5bzRGIBckT/U2Bv1oaArRH1BbuYtamwwmsH6bIAazyxBqGQ3CRGNDRYxbe+GXBlj/TbqBODGwtnsfHCT1NESRv9YZmwym12ZjPtfdeA9a7TgRVKhFWkBZKRbz2TlPymV1xFbZfV4Dze8oZdI7IZ1P92Tzfo+H6cOvVYzM+N0Dr0vK1Jt6yBdlq55DjwCwriF16kwe1u0jPdbaJUnFDQDzvIr6iULEykbqJss0BsIJJFYlvnU2uc/U1ZeFtIb7Kd9h+33JPc9JCG603GwCyeWMvpnUszHfgXSOP2XX7xHWKuq2Wu8oWrO/ZsWTW4IHi5Z4yQ4QpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i0kmCJMSGIvUOzhTIff6KcMV9QnY2cagi4V2X8P5nsc=; b=apf0YQzLqFQkoOq0XptD62sE+et8KoOsyd4j1n6WScqyRDEJ1EYJhn7/9B/nu8l5R/HWE3Fx6OTTigvZlhQHTeui0GVAX86898TmeHhIYQSVxx8gMFkbkBmILXYRIPYW77x1A6XlXYen7+1szO6LPMH3T+FTxTQg2wXIAgx56smkz3hygpNTSmEnyTaMMY85JKbQBJxJ5poVF2NeFyv1eCn+g7zEGdn00DKPWvsdCmbbGdtvLz0/KNuRSFwGnJK5lBMGQ5Gc5GqF3VIplLpbRxQ69J40f6Hi9lZehI1YP2+Z9iTKHkXJLEf7EFQNHJMRxICcX4Iqjnd8kexmUkDq2g== Received: from DS0PR12MB6559.namprd12.prod.outlook.com (2603:10b6:8:d1::6) by CH3PR12MB7713.namprd12.prod.outlook.com (2603:10b6:610:14d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Tue, 3 Mar 2026 18:40:02 +0000 Received: from DS0PR12MB6559.namprd12.prod.outlook.com ([fe80::3f99:f532:cf6b:ea46]) by DS0PR12MB6559.namprd12.prod.outlook.com ([fe80::3f99:f532:cf6b:ea46%4]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 18:40:02 +0000 Date: Tue, 3 Mar 2026 10:40:00 -0800 From: Piotr Jaroszynski To: Ryan Roberts Cc: Will Deacon , Catalin Marinas , 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> <0a10ea33-937a-4294-b9a1-9323c706434d@arm.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a10ea33-937a-4294-b9a1-9323c706434d@arm.com> X-ClientProxiedBy: SJ0PR05CA0205.namprd05.prod.outlook.com (2603:10b6:a03:330::30) To DS0PR12MB6559.namprd12.prod.outlook.com (2603:10b6:8:d1::6) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR12MB6559:EE_|CH3PR12MB7713:EE_ X-MS-Office365-Filtering-Correlation-Id: c9484dfa-0c78-49ce-6448-08de7954478e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007; X-Microsoft-Antispam-Message-Info: BosTtGqVqQtAUQAKQYda5vD33EBm7kW5kcodZVXVKzc0BjtL1dWOzvjjGD41OTQlzkhhxV45/yInIYDUJ2KztAmeSr6znk2rLf1SjjlNsuk9PJ+lfAAVrgyFlzecjGz+g7EY6BeQ7Uy3kuEiqe63MSzcOezyRs3X4UB3prmj5ZeGE+02jJDFsfEwsvxLXCxDe1rXojfevyiITtd9i/klskzz4ZGyjvJsgMY5xCynXbRkf04CDbf7dQx8iG3B+kQgdgBp3PNrPCglS568A8YAd1PcoU6R0rVaTrbHe+J7CRtfKgJmcvJHd0iPNxoxBUz6j0B0mXHZYKEQ9KiRJZMXmF/Izq1zp/4qaAlFa6faC8x+9ZEorWFCYFBHpV4CJKxM+cYMCa/KCIuz3s2zKrAzAVucwHd4dD3u/EJlubN6H4fTxTOmzTaP5wRoDIxGpt7t1pzeMyHn/8CspNQoqYTM5w8ULrkEGzml9Fn1CbfrsbT3Y9sqcVwSXQ8Vcrl6Kd1qdglrMtIWIiywGM+nh5pOFiCjd82PwueZTbvgI6G686hXRnxm2exzIEfnl9UkVdu2QNsp8oNoZ6fygmea5mtVn5tG3/3Sas1NsbPr04n77jwhYHxwKo1kTyiZ6yN6+Hky/Kznb2S9t/Bv+mPCqGfhhKr7ETlF7ysuMfqzq4KPf4QEi0ZxDBSkPISUVekCsbeNVFBTqPBlP//akrhcG89q+n88XoiTreN7sI3eciORkwc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR12MB6559.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?9A7XCsfi/+4j2QRVU+3OSycnPkNzVuIdwYs/rkYSVh4hb4J/WwvJyZK8ONX8?= =?us-ascii?Q?Oxwi72Bk07o9dCRycj7CNpgDxkOAPpFHOo0cCneuNEC3T/cbF9inH24CpR9L?= =?us-ascii?Q?/yyPnQq8/ilnTpWdq97M3Y5TtCVmmNlJR0gRFBAN7Q81ZHGfx7m6utJ7dnsR?= =?us-ascii?Q?TgReZ44fuL/wNntbDY1fIhpmZHqSY//JBzceZSsA30ibFva/Q+PIokZZmoQC?= =?us-ascii?Q?fFKBYoViqX6MjVO6ZySNFJxkRJ8UrnhFiGxde00lAHBZsqJGG2Kp9tM701st?= =?us-ascii?Q?ypxFSJdPn2Ill+Ei95wIvtjaFYARpLoOraeYbbRWPcLF4GRJ4HBKOlxQGSS3?= =?us-ascii?Q?tNU/KVL+Wu+H2/J8ViJA4v1hQwaax66QzVbS9qCOO3p+KCit50uPhztFx9Zq?= =?us-ascii?Q?M+NsT5rzt2oxkYzK6wPwK+cwgEH32JBMcXLjmGLnK54CF7rl/mEyyc0aseKj?= =?us-ascii?Q?1id4YU12QJvyrNkS514DgwCNg4lRCBlrcUVB8DkMLqvETsrGcEZBzbtH8i5L?= =?us-ascii?Q?wIfDqPcg/naHUuPzQk3Pq+KxgTyp4S2TvMr8huotw8tLPjmKkvZxeB7XrI+T?= =?us-ascii?Q?6WlxD7eTmDbIDrL4HHwb/FvjA29+631SBu1cE0wgtYdWX8WlvHF/S+Aftj0n?= =?us-ascii?Q?IvlbGdvehzUUmJlsvJNMfbLoMwBiUDNlkqiLbn8aqmw0HrAikNgQKYEskg9t?= =?us-ascii?Q?Nli9G4y/aHA3Nv8P7IBjG8at/9jIcC8P5tSyODMrZpzgji2uQIfy9nFrK1Np?= =?us-ascii?Q?+lRf5VJVAn6hLKNBTTT1LbRrTndHAej1iI1S3obYBMbKyb11fkm7nq5l+FiP?= =?us-ascii?Q?EfxoqBChEVOFDUNWeXLEO0aA0wjoeGSyrhLcC9UHOCi/uhrRmXXKloctlNSP?= =?us-ascii?Q?iW0JxhVIjFEXQv5kUc2f8TnGSivnw+ExU5XIg13ohhGqBdsKSuZbU9T2L5I2?= =?us-ascii?Q?WgubbbOgTvE3liDELteo9/80OIQ0VB6ZuRt0PM6MG8ov50MR/ZUiLjsdrlJD?= =?us-ascii?Q?IDdNeKgrt70xkDhOkOLfhjPZ/TuYhagjkMo9On3TOeA/6CxHIPlY7XVDFOux?= =?us-ascii?Q?vB90D37wrq0mzLB+Zb1InrmW18j0YxwFjy/ZKoltsPlTUu/TAGOCebJIp4L6?= =?us-ascii?Q?pkue7m1omXkoePuq+EpNTmV4W3KazkxU7/PAqqnXBXnQe3g3KJRaWfz1C4Bg?= =?us-ascii?Q?j0t8fFMmECnOJ2CKVrvlpk91sR63LkBkwEo1Z/tgnIATwcXwRijbIJS2s2mf?= =?us-ascii?Q?6k/km3px67EC3+cIiI8Gi+OpGWtuuMCsXh5lfodov8efLCDPSJsoAcmluy4f?= =?us-ascii?Q?2SYeCqdSq6kypmnczeStgjGCjKOHIaOJEDqVQcXKRVILnPvGlyjfiq+czYij?= =?us-ascii?Q?QZn9jrRG9tjCofI60nMn1FSAQvxJc3tvDWkGpzE5771lyHV43n0CMWjyrsqq?= =?us-ascii?Q?GTMVrSqTk4SUN/+cSlv59VxNMIliuoW5hXcIniX30x6Fix3D3ofOMqz5yDQF?= =?us-ascii?Q?ZEdZSSUtH+Hc+NlKS6EjqQToCG8UnguUr0zadLQ6hLThomzGdVH40NxlH02o?= =?us-ascii?Q?b7IMIViC3c8eLHMOcXhiZ9CmyIy/Yq2MSO0RTLWm5lV8rdShyFmYVhWpFR5e?= =?us-ascii?Q?U4EWWHtzFlyger5QGJ8WsG2S9JX1gfC7B5hyMN0JSYaRDT5b17+yd213s3Ty?= =?us-ascii?Q?hrazNablXvhoZZKWmxzt4M+4SXgc+w4qkRdlFQAX0arrAODzzyKfeWM9ppCZ?= =?us-ascii?Q?CLLZ/nU40zK8UIIqL7sjqdabF0qwYEM=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9484dfa-0c78-49ce-6448-08de7954478e X-MS-Exchange-CrossTenant-AuthSource: DS0PR12MB6559.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 18:40:02.2778 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +9baL3edZ+y1+Dg3naCoF3LdwZ0jjgphi2EXqmId6dqlHABgImRo01gTdLXK/b3xn9sO1scUlhB3W3faHl4jTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB7713 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 85CBC40014 X-Stat-Signature: jyduo6a3kpk6rmjsh3iq6ekwfceocnoq X-Rspam-User: X-HE-Tag: 1772563210-429590 X-HE-Meta: U2FsdGVkX18OZQ8yr+wq1gLwY7umP0Dp1WfEQiYuVjXm2szmZIhimNPg4wNwCPIaHraEjTRVP+CYV+4kHtsjVn21a/uRhrKkkt37J6khPpbtqh0o8tFSShjwZIkp9DvxhSUTtuaq6CSCRwBrO49a89JLzXcFIzkoQg0Sfx7Ts8Rne2SDciCO1XJeQMny0KZ7Rvz52xVwiziQSu1WcFoJhVlXxLkfCeR9Cz4msQWxaGs0y9ahDgc8bLhbqEhG8e98TQguvQ8PRgLE/yoG3zd2Ur/7iMZVBKs7qhg41+9e32VT2ey4RAkWwMU2TL3gkjHrvMhQ23AyqANYFlRF+nXlUJlB+FRCCjGCXL7OaJqWKXqDlXcT2wjukdZ8k0TVe0yFeH648sMiwW/oi7HejwteDtPzVcGB5S4uqjCxBLEiaUVu5WvtJUf9pxUq/07RydEXrqbyJtIJXwTGAgp4j9vQULrDMz/jdJRUaQiLY0jwhfXDNO3DLXJ8kGGEzQb7Ab8XNNzAql9dB0Bf2NkU1l87jPaDXxLYwtbnZIuXpa2Qd58rWew3sYayDS+3Qea4gtIGDaEaUvECQRNibn9JcYcw2mUwcPdj1L+Xgm5hjvy3tcdmqxi0ppStLs3AqTUShMqE2/c0Y56/Nw+bBMKqjbNZu55QI5o3h8wnUMxczQn17roW8ffSC5uRKwmvsB1phHek9a4ufjMRkc4KicGf76xRKdH+nVuV12D7b8eOsmfKjGe0v9PGy9hECt0siNWn9TNcg1bv+FcsP8RcLjBz0Po/IHk32RYDRd/baaGSJAXN8ULYW9u1b1MCxAJQYAmsWm968A+VbczGt4F5geaiRxoom9msPRQEXX87AEGG1n1pCoQ5nUsqg6OzrK1MFOpbQ4rAYBU01E7m3R5GJngjicyYcfoKsk/+voRNjhZZExhFRKqAgnxHzvkkq/BYDPh4jdHMZADSYdHdYl/Gi4QKBF9 4wKTIQMn jActNm8KJ31CvnpDzyZ07VDdEvEPqJxXMKjq1YXjiFFVPp31FTPPXu4YjG8nb+fyb6rPH/YlJWfBf7h5vJae2CoELyQkbJkS09IRelGMgQyRkIDJcMNnYvJQUOK6eyMov47KawG8KQ/+l6Cbh1YYN1YVENDmIRPgd904CaKYbiEhhwNxXoW4Ti3DvJSRZ4Yw7f9lAfopTBH6GcLQzVlA+dsZpQxxR6wNIOdPFDPE3z5cRuK3TCAwPsAbmmA9tjTH6g0p/ymMwNSkF2MKyYpZnfQEgMS3NeLf+6g+K7EoAwudAHRFBsbSVe35BAW0xrV+6iGT+AQSqt58dCfgFxxxdwCsIJK29PTxy6FXaqBLUFPrTjProR65iZnqoZe0NwHqTtrJbcDcRTTNakTJ6bF+HQL//JilBRW85C9EzNJFklyh7Hi1aEfdrdbM+LwS8atm3zrFKhBdcSmtaT2HPOYXkcN3UHGuZSr14CSpNz7tQZ9j1/ngfJi4+AavEtoxNxY7CFA0Xk2H6k6Ydi855odF7bLbnaDVLsbkvbBbWWyj0oowq43TfWlZST8L0pQZd1/JeOhcoGNmRtvAAe94= Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 03, 2026 at 08:38:23AM +0000, Ryan Roberts wrote: > On 03/03/2026 06:37, 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. > > Ouch; thanks for the fix! > > > > > 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 > > > > Fix by checking all sub-PTEs' access flags individually (not via the > > gathered view) before returning no-op, and use the raw target PTE for > > the write-bit unfold decision. The access-flag mask matches the one > > used by __ptep_set_access_flags(). > > > > Per Arm ARM (DDI 0487) D8.7.1 ("The Contiguous bit"), any sub-PTE in a CONT > > range may become the effective cached translation and software must > > maintain consistent attributes across the range. > > > > Fixes: 4602e5757bcc ("arm64/mm: wire up PTE_CONT for user mappings") > > > > nit: there shouldn't be whitespace here. > > > Reviewed-by: Alistair Popple > > Cc: Ryan Roberts > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Jason Gunthorpe > > Cc: John Hubbard > > Cc: Zi Yan > > Cc: Breno Leitao > > Cc: stable@vger.kernel.org > > Signed-off-by: Piotr Jaroszynski > > This fix looks good to me: > > Reviewed-by: Ryan Roberts Thanks! > > > > --- > > arch/arm64/mm/contpte.c | 47 +++++++++++++++++++++++++++++++++++++---- > > 1 file changed, 43 insertions(+), 4 deletions(-) > > > > 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; > > + } > > There are 2 forms of "dirty"; HW and SW. Here you are testing that all ptes in > the contpte block have the same form of dirty, which I think is the correct > thing to do. You could relax to just test that every pte has one of the forms of > dirty, But in that case, if a pte is sw-dirty but not hw-dirty, then the > PTE_RDONLY bit remains set and the SMMU will fault, I think? Yes, for SMMU we need to make sure the HW-dirty state is correct or it will keep faulting. And while we are doing it, it makes sense to just update all the bits to be consistent. > > If my reasoning is correct, then I think arm64 hugetlb has a similar bug; See > __cont_access_flags_changed(), which just checks for any form of dirty. So I > guess hugetlb is buggy in the same way and should be fixed to use this more > stringent approach? Given sw-dirty is managed by sw, is it correct for sw to ever create a PTE that's sw-dirty but not hw-dirty? If not, then I think it will still work fine for the SMMU case as sw-dirty implies hw-dirty, and if it's missing then we will set both. But for thoroughness it could make sense to be stricter and add some comments there as it does feel a little fragile. I'm very new to this area though so probably best for others to comment and tackle this. Thanks, Piotr > > Thanks, > Ryan > > > + > > + 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; > > > > + /* > > + * Use raw target pte (not gathered) for write-bit unfold decision. > > + */ > > + orig_pte = pte_mknoncont(__ptep_get(ptep)); > > + > > /* > > * We can fix up access/dirty bits without having to unfold the contig > > * range. But if the write bit is changing, we must unfold. > >