From patchwork Tue Jun 20 11:18:24 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alistair Popple X-Patchwork-Id: 13285701 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]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57C70EB64D8 for ; Tue, 20 Jun 2023 11:18:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E806F8D0002; Tue, 20 Jun 2023 07:18:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E30838D0001; Tue, 20 Jun 2023 07:18:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD0D18D0002; Tue, 20 Jun 2023 07:18:55 -0400 (EDT) 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 B9C518D0001 for ; Tue, 20 Jun 2023 07:18:55 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8CCBC120AB0 for ; Tue, 20 Jun 2023 11:18:55 +0000 (UTC) X-FDA: 80922879030.09.9F12F29 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2040.outbound.protection.outlook.com [40.107.236.40]) by imf12.hostedemail.com (Postfix) with ESMTP id 79D3F40009 for ; Tue, 20 Jun 2023 11:18:52 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=QGXSFQkx; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf12.hostedemail.com: domain of apopple@nvidia.com designates 40.107.236.40 as permitted sender) smtp.mailfrom=apopple@nvidia.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687259932; 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:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=RON3FyJ218q51xTUwnoGY4rtgJ0r2w6Gqb9v7YBdNS8=; b=2toMCOacp7OMhR47oDx+H6W6fmBZ9PkV5jw/MDn4SWd/qPOpEN+Mb3VyY45yY8rOJBYURM 3sUSame4YhctIIvbGwneLkGYf78FafSCUL9JJr9pQbyVPIROYEkD5vCYlx4qv3W2dpPWbw 6R8GexvuNy4k1oAYDhrPxPeR6fzIJ9k= ARC-Authentication-Results: i=2; imf12.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=QGXSFQkx; dmarc=pass (policy=reject) header.from=nvidia.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf12.hostedemail.com: domain of apopple@nvidia.com designates 40.107.236.40 as permitted sender) smtp.mailfrom=apopple@nvidia.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1687259932; a=rsa-sha256; cv=pass; b=oS7B0lAJIifdbzwkX0Xa+NQLJfxmvxI7qTHtZUCTpXmG48oD4W2MzXeUq6NTXG+XlYBYoC juUmFcGRRlnh0P4QtplTHTtL92K56CUFox9AIDPhMKTMz1DJqcaNlggs9dO1weBfw3kXLl KcPkbRUoCymcE1t5ek7Ivj5sPkTS4/M= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DsrnZdZBLURqFSffYlbxkFrewqP48kaDPmCtPwonmqZ5kkJRm/bNp3AVeUU1wDkMJ5T3yFpJF7Yg4Tm0/xFidgUb1UNp6DKzZTUgplrOy7SEFhmZl2qNp0xnqCPJp71LP6cj4DqFdWKHKfIfWmMnfFVdTrKt9Hlj+h0IIbuZaYfKkrgnbhJXJSCly5nJNFk0shliNO3H4jcQVt2pt3CRi0D/xvMPSky2cuAEU0z/HjaUEzlu9KgaelkHOAuodG3vGsMZpT3M5OjJQ7tvlSv28BdXhOTmfyIekiJSD84IkFvPKZIv4RCfNvo4/9Gh4oEgSZyAYRSJGvBmGr8lvPQ3KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=RON3FyJ218q51xTUwnoGY4rtgJ0r2w6Gqb9v7YBdNS8=; b=Xwx3k+riR1hwytrRi8K/MUov9Q2hU8Fb3snQkKGU+5jDbPwu6WtoeBX+Ry82K4RfB79wAjQZ59/OWUF1AaAdO5bkSCnkHYol9LokPv5uYABMgrXqdv/OzyqflIVAF15L0dNuqfpBXShBUeVTms3Y2r5DRacbgyWMxv3Bhudgui3awjLMvKPYoU/vk3dBoAhnR5vz6iTjbmqX8VLGEwx4IVZYa535kRHWEfUR4Szlj+Z6O589EKSueRu+zbGcPSjKMYkn6Gq4eKwI0ZKTh7A4Gxiu+2MD1/daLToJ/lcA7FDvgGIFsTu+i5Du4qroASc4IeEEBgn+3QB2q2b5exg76A== 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=RON3FyJ218q51xTUwnoGY4rtgJ0r2w6Gqb9v7YBdNS8=; b=QGXSFQkxNCUURFR0ZSVegp4LkvQG9UtqNVQzapOCdSnNxP4LU+cEprhJ0MwULJ1MFWYBjreXz32UluCB4mdr0E08dpYqALivsUtb49UtwNDbmXi6t/5C4Ny23Fbv4bvYEs/VwXHpyCaYlC/glK3QEUBezNaw4PCn1h12F9pnztJXO+NME5NsciRP0gNHXiDVrP/5qebSKVku48k+I1iGp5WsW92QLgoZizmm2xfL9UCIJC170OUhFo9TkAosDwVhajQkrnihjcLQgpPLM0XcZbT1XkhL5TUAi9QWPMpA+gkaedUuSGGmontZ6bTONjxfi2FdZtPwOQ1iRp9/B9gyFQ== Received: from BYAPR12MB3176.namprd12.prod.outlook.com (2603:10b6:a03:134::26) by IA1PR12MB9031.namprd12.prod.outlook.com (2603:10b6:208:3f9::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6500.37; Tue, 20 Jun 2023 11:18:49 +0000 Received: from BYAPR12MB3176.namprd12.prod.outlook.com ([fe80::4854:668:e67e:b61d]) by BYAPR12MB3176.namprd12.prod.outlook.com ([fe80::4854:668:e67e:b61d%3]) with mapi id 15.20.6500.036; Tue, 20 Jun 2023 11:18:49 +0000 From: Alistair Popple To: Andrew Morton , linux-mm@kvack.org Cc: Robin Murphy , will@kernel.org, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, nicolinc@nvidia.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, John Hubbard , zhi.wang.linux@gmail.com, Sean Christopherson , Alistair Popple Subject: [RFC PATCH 0/2] Invalidate secondary IOMMU TLB on permission upgrade Date: Tue, 20 Jun 2023 21:18:24 +1000 Message-Id: X-Mailer: git-send-email 2.39.2 X-ClientProxiedBy: SY5PR01CA0040.ausprd01.prod.outlook.com (2603:10c6:10:1f8::6) To BYAPR12MB3176.namprd12.prod.outlook.com (2603:10b6:a03:134::26) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR12MB3176:EE_|IA1PR12MB9031:EE_ X-MS-Office365-Filtering-Correlation-Id: ce89a065-45a9-45c4-4277-08db71801f1e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uMzN2pbYEr9GM6/DfrLEK3qGW9HNTJUvy63jyvuShBWybG144RD25dKu/kCB8nbrhfGJQS6ZG4+0WluGKj+QoRtJulH5xVvA117hVnEU4XXS5TXD7CYzo2MjPLf6QICT1wmccVdNmAzDQGZenVVwW6UuPnS/WU0f1M7n8r/NBCNjFzQw5dRWWV1wdEnHDnvPsF8bVCsFtL0fgu6SjpDv9FbzZPuiwVWWm/P+qZTfaNHWKaABznIdjwbO/YfMYJnvhc/rQEWVUU17bQzjxDh8Ll+L2FXtFIlhxOXtgrnShPS40HeeHeVCaZbnUcOC4ScUp+VgTu6oi+tb60VURhSitg8b0y5bDzhIb8p/BB0/K/pyOT4q9lSaPsyvIwRiNgnXkZABYyH5q8duUv2VQMINElUM+MdPmSluiBJBHeaGxTeijlN+X1HBJ/ehdKYSFadRf6hZVDTQ7fbrluHyyvTXpQ/d6w4jdsQVv534vScqCP28PdTxxjPoDqOXJBcXl0+5d06zbc4uhPLdN+SI2rXEXZwE9n27oUc2r/hVp0M+G/XN7S9+XSmJjdykiEvpGn43XX/k4xFaHHGWPz2keqom4GiPB2DNb5nrLZ1TzfUUfJe/8ZFa4UTXZICx8nNF2EoChrtjl17mOHv/rugfYwZEXQ== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR12MB3176.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(376002)(136003)(39860400002)(396003)(366004)(346002)(451199021)(8676002)(8936002)(66946007)(186003)(66556008)(66476007)(66899021)(5660300002)(54906003)(4326008)(26005)(6666004)(6486002)(316002)(478600001)(41300700001)(36756003)(966005)(6506007)(6512007)(38100700002)(107886003)(7416002)(86362001)(2906002)(83380400001)(2616005);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: G/eBYveVd1JkDZXnI22LGrgqBDiX3i2/hwLtDRLZoqgeemsSyUNW69Vdq1G32RiPH/k+RVQFGxBktPZsNcrRQVleYNIK6DW2Zw/5s80s3OtQ5neBKhC2yDywsPGkUmd9C6PcBGqM1WgwEHPfqmLit71xnXICF7roUOnlEgP3dyCVQfT6Ukuwflbmn04KzlqfYHebjFT4rVnI2PRPvDv8wSCL8X/g+fvQ3ff1j+OdOwrKhHm1dCHbwudLTVubeMDcLbFFFmh70WrwCGyYWYITuBITO3jJBN1YYF+1TVLwSYActnzk8XpEtIgJzIl2fY+ytqU3GOBFstv0V7fAUhsnHELMV5LpW2EzSBoo0/nbxW4AijRGWDn47BjDA7I47yGfVWL+SU6cE1PSI3sf82oPeyB+2GN+sOCTmpRTWtadlOzP9K87Nj643X0dYraBKY1DBxhqOVS0wNSUjyZ/8dTI2K0p1uOgzK1alpsMkqQAg1/9JlKHd7TztGmb5Ch8Dw4afiEXJbc0RP3t4bpPx6AnPKcm7AvECSwgPMGYOTWgVj6rdV+jd0tMNIinQPAb8l33+RzFBri1xJpfx+AUm0N87DFRmrElCyjBu15D7DeQqwkFZOAhFS7KAR29t3mfCtWwKopkIH23ekViyn8eiss7FhjoQxOERyOAup3EXPaUawCGd4vxpPrbaBst0enQFSvGM6jL79CIE5JBzSNBGgNzjhpCw9pRtD2z7LHzQFXa82uBfFZ3IXFKE8sQ/WSSslyPwjGl8Zs06BLv8DL/w4aXj3NWOjo6NU3opHqgSSO4U05hTx97QpyEm7CiqLBzZIHwo25mLhBebeTWTqrUVz5u/1dlAiwm+ZAMSNvaU6WWx57LIjSdVOi5SW9M6AKZPwwvnBay1gorkiNRpQRE3bl0hb92pm+G/fheGFz9YigB7RCRmQiUx1Ht4JWVDtfQOHZIZNJN+yncphgX8SPiMP7+/C8L7w0ZgDySZ0j4QHgqA2K91S8WsNVjWiroSPqKUhSlEPUsAXrG4k+7CiLOsQYBwilevGLLjBQ/QT5Rbq5P7naCx0bPHAiP0RlkGvobXrXPQpXhAAiIpAG1n5bjymNHd3jyp2h67APhKa5pIIKp1MnWg35O9XJK3HWS7h1HS9DJWeVS5Aavncdb1UKEu5wTsqk55OH9Xp252hmAe2dCtPR8bG+BJNeL23DK1UsdpGp5eOOrj7JBTNgylniaHWrkc7P3FLuOEMAXKZwGWR6yPozZE9M9SaO3834p9Xj62PaMpCh/6XDr6VdAuzdczhN1k9ADMzoOit7nNjtqK7d31O62xwB0S/ogSH1cw9GaZHIEPagmE54hzoPKr+PDuo48h15dMhlJmcI4+BgeQbJoYryoCIyTNhQq1PVYsbDoVD9Ic/PuDaL7ejOV2qVXnTQzahnkhgbpeV5TMnz3y2gRaXXAI9yA4DWa2iwpzSHusElo6KkOXtMNqYEM/GaS/3SPCWEJ4PqeyKwI++tmeR5Y5HwFVrMXSQN/wD3T4N8TT3Gwg5EDy4Q0raOD2Qiv/wIF/LQO7hNdaPMxKYjrjNb3sJxe0G5e0kfJiVgKzoRAxRGW X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce89a065-45a9-45c4-4277-08db71801f1e X-MS-Exchange-CrossTenant-AuthSource: BYAPR12MB3176.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2023 11:18:49.6452 (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: zvutrk7GOIlB9abPjywN6A6sm4oCzePqBIY0mLbx/Sj0gvbKiZkjnDDyiUDBwXxDPUMk9dwp35bkIzLCFTmJKQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9031 X-Rspam-User: X-Stat-Signature: rrd1in1qbscjes54tmaagh5k76p8gug8 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 79D3F40009 X-HE-Tag: 1687259932-785792 X-HE-Meta: U2FsdGVkX19zxIl9G0bhb9pFds8UbOw2kcU5qKgO+qYeHtMe3Ai/PnvmV9ns+QawvnK2TWFRTjuMn6GsmW87Y/bWboNDpai0ppHMSDwWmlSuUlWgk7OVj11ZtfA1lmrSO7v2vJi69CKExMOJh7zoH70ayMLmWLtj3iZAXBLgohL/QS+m8XbDUDiagTWuB33xrwJx1qU+2eK0Mrk5UIMaOBq2tLhAfHyukAVct4CL0//MjbC698l/TVyCyaxWAdj1y39kH/4o5WnlVa6VIVyI86yQlX3mHoonPhQuX+nLHxQBh4kYuT8g9W/hfq4Zrz5FACkn/0p45+V3rbOEPghBxDMhzPBliJ6/wuUl7hmi08R+yxplS3/7XU7IqJ8glblrEZK5Z/V2JyS3bjdsOQOg2xWkqpD+7G2znW/OigW/LSnXBXDd4x972rcFwxbjuocV78xxCoXO3A532AheUdTqQHjs2B5/CfcgKdcY9c+9Po5Wuyr1E/4JkZ1nbjnUhRDGigmKTLGfcZAhNoP8H/sjUQkQ1+ZudzRi37zu/yBQ6GwSTuQrAGY5H7ovVmxDD7gHYJXAuwo+EFxJBO+ouMP59W2SalSFeLYIKbTFGYoLKI6DOYl9FS/9wY3bdnaEEdt6lkHE7foEzV8/Ts9DVK6Z+P5q/8arhrZsSY1/N+xyPnoaH9jJnQFPEOWiZyXzh/Al2qjNsW5Cxd6/h/aJRAowVYNxWWfc3vVx6w1uCzBttlIVJKoAE7ahTJbaNktcjF0HKXs7CJu2KTm0VnKqciQHAk/qZvLKuWABP13Qb7YRg/NrvPRfELPTE5ej+XYJ+t6FoYlwkoKYdMrobQcjBA40n5721RFxR8tRXlCWeogKwqGZ0kF3N6Ar61G/G16l+guiUo0CSfbpYieEijudRxRCS1j+PokjgY9ZzWM5GVfneSrREoiVWmDhDTPx5JlLvU5CDWnk0xIiwBebCscuhFL i9XLLfbA 3lzZfNNm5rLlUViQnpDCoWqADNNCJadBQB0uTepR+s3Z/zNOZBEHV3xZZa/Lz0NN/kYpd/vWOkYPsbYcNjLRCKCRvWl/eqdwXRHlYFxKKQwJxPUNl9wJWV4kv8O+9kNYiiZadk9IBX+d2Z4875bp27C5ZlyoZ8+lo6RDIyzGzdzmv1EERwQ1CS9oGjXdiQ+cEcl2KnosLaWG/2Jf5/daYq/T/YyDkuwOYrZdopJ2MH4VKyh4DVdZudqCtCyLoZyDZEvJa1tH6LnIhMmwzHBnw4sAuKS7KP+Pz6E0FOKC2rJpNtRqiewVRM4AE8sgY6gs5EptxZGA2ueFNEGAqa+y7jqh0O8NBxVY5pfuzf/OEIaWYkrarRtdcTRx3so9IX08gPpBfeSK79tAtENoAlSC31zLJMPkxQR2udM9LEyem8jJT2HcqF+GW/s5cg38ertZJfrDGCMvPwHxUOKVmcUcFihYbgg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: ========== Background ========== The arm64 architecture specifies TLB permission bits may be cached and therefore the TLB must be invalidated during permission upgrades. For the CPU this currently occurs in the architecture specific ptep_set_access_flags() routine. Secondary TLBs such as implemented by the SMMU IOMMU match the CPU architecture specification and may also cache permission bits and require the same TLB invalidations. This may be achieved in one of two ways. Some SMMU implementations implement broadcast TLB maintenance (BTM). This snoops CPU TLB invalidates and will invalidate any secondary TLB at the same time as the CPU. However implementations are not required to implement BTM. Implementations without BTM rely on mmu notifier callbacks to send explicit TLB invalidation commands to invalidate SMMU TLB. Therefore either generic kernel code or architecture specific code needs to call the mmu notifier on permission upgrade. Currently that doesn't happen so devices will fault indefinitely when writing to a PTE that was previously read-only as nothing invalidates the SMMU TLB. To fix that this series first renames the .invalidate_range() callback to .invalidate_secondary_tlbs() as suggested by Jason and Sean to make it clear this callback is only used for secondary TLBs. That was made possible thanks to Sean's series [1] to remove KVM incorrect usage. This series is currently in linux-next. From here there are several possible solutions for which I would like some feedback on a preferred approach. ========= Solutions ========= 1. Add a call to mmu_notifier_invalidate_secondary_tlbs() to the arm64 version of ptep_set_access_flags(). This is what this RFC series does as it is the simplest solution. Arguably this call should be made by generic kernel code though to catch other platforms that need it. However only ARM64, IA64 and Sparc flush the TLB in ptep_set_access_flags() and AFAIK only ARM64 has an IOMMU that uses shared page-tables and is therefore the only platform affected by this. 2. Add a call to mmu_notifier_invalidate_secondary_tlbs() to generic kernel code. The problem with this approach is generic kernel code has no way of knowing if it can be skipped or not for a given IOMMU. That leads to over invalidation and subsequent performance loss on the majority of platforms that don't need it. 3. Implement a new set of notifier operations (eg. tlb_notifier_ops) specifically for secondary TLBs with a range of operations that can be called by generic kernel code for every PTE modification. See [2] for a prototype implementation of this idea. This solves the problems of (1) and (2) because an IOMMU would only implement the operations it needs. It also keeps the layering nice as theoretically there is no reason a secondary TLB has to follow the main CPU architecture specification so is free to implement its own operations (although I know of no hardware that does this). However it adds complexity for dealing with a problem that only exists on some implementations of a particular feature on one architecture. For that reason I think (1) is the best path forward due to simplicity but would appreciate any feedback here. ============ Other Issues ============ It is unclear if mmu_notifier_invalidate_secondary_tlbs() should be called from mmu_notifier_range_end(). Currently it is, as an analysis of existing code shows most code doesn't explicitly invalidate secondary TLBs and relies on it being called as part of the end() call. The disadvantage of changing code to explicitly invalidate secondary TLBs is generally it can't take advantage of IOMMU specific range based TLB invalidation commands because explicit invalidations happen one page at a time under PTL. To solve that we could add secondary TLB invalidation calls to the TLB batching code, but that adds complexity so I'm not sure it's worth it but would appreciate feedback. [1] - https://lore.kernel.org/all/20230602011518.787006-1-seanjc@google.com/ [2] - https://lore.kernel.org/all/87h6rhw4i0.fsf@nvidia.com/ Alistair Popple (2): mm_notifiers: Rename invalidate_range notifier arm64: Notify on pte permission upgrades arch/arm64/mm/fault.c | 7 +- arch/arm64/mm/hugetlbpage.c | 9 +++- drivers/iommu/amd/iommu_v2.c | 10 +-- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 13 ++-- drivers/iommu/intel/svm.c | 8 +-- drivers/misc/ocxl/link.c | 8 +-- include/asm-generic/tlb.h | 2 +- include/linux/mmu_notifier.h | 55 +++++++++--------- mm/huge_memory.c | 4 +- mm/hugetlb.c | 10 +-- mm/mmu_notifier.c | 52 ++++++++++------- mm/rmap.c | 42 +++++++------- 12 files changed, 125 insertions(+), 95 deletions(-) base-commit: b16049b21162bb649cdd8519642a35972b7910fe