From patchwork Fri May 31 02:48:20 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Hailong Liu X-Patchwork-Id: 13681075 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 90467C25B74 for ; Fri, 31 May 2024 02:48:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A2EC6B0089; Thu, 30 May 2024 22:48:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 152B56B008A; Thu, 30 May 2024 22:48:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 025B06B008C; Thu, 30 May 2024 22:48:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D80166B0089 for ; Thu, 30 May 2024 22:48:39 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5D368141153 for ; Fri, 31 May 2024 02:48:39 +0000 (UTC) X-FDA: 82177157958.14.8641F60 Received: from APC01-TYZ-obe.outbound.protection.outlook.com (mail-tyzapc01on2081.outbound.protection.outlook.com [40.107.117.81]) by imf07.hostedemail.com (Postfix) with ESMTP id 066994000D for ; Fri, 31 May 2024 02:48:35 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=oppo.com header.s=selector1 header.b=Dn2ixvYN; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf07.hostedemail.com: domain of hailong.liu@oppo.com designates 40.107.117.81 as permitted sender) smtp.mailfrom=hailong.liu@oppo.com; dmarc=pass (policy=quarantine) header.from=oppo.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717123716; 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=QSsPEhSqYtAUWFgSxFfeptI40ZNsE6nLejj9bfMpIkM=; b=uSWQIZ33Rm+1ZHUuofSE+uweb5mIO2VGsbm35uM9KK92L7lv7lyQqiXs1T43YL6nh5dOqq duV04bo2ZrbwhwtvqzYeW97sIuTzDcDnPQuY/JDFm2VGw7c976Wq9/dobpiUz+TRpe97Z1 IcPate+Acmj0NpQ7Eo5deeLgL3NvsIA= ARC-Authentication-Results: i=2; imf07.hostedemail.com; dkim=pass header.d=oppo.com header.s=selector1 header.b=Dn2ixvYN; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf07.hostedemail.com: domain of hailong.liu@oppo.com designates 40.107.117.81 as permitted sender) smtp.mailfrom=hailong.liu@oppo.com; dmarc=pass (policy=quarantine) header.from=oppo.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1717123716; a=rsa-sha256; cv=pass; b=EMiRmWYeXKMpfw2l4CJxX/JJhm8NIKNgj5qHq3CU9kPvJklQxYTRB4EKAIxxqjRrXbFQjN BZhbvB9WJ5vTI2HgkcjhNUfz9kb54hldzz/+zIJ+N6SfzVwMNM1WmIgeHLiJey7u/ruJVn O8M8QGb5fdM8RpKUI7RRLRP+PaE/Nqk= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NHWEyK5tjZ5ihFJWL5jVv6mKGLQTj/E/2wtEUgJ/fSYXWkVdBspDbD37l//cU1qFyqYKOEUeFNoX3aKyG67/nAd3Xqb2mwVVfuqNycZ+Wgwab2HoeKYyuMvSpnjHabrFeIdy9rZo87vFIPkRXypr/TxDk7AbJgii24NlWt9uo9UCFlwtKQ1LoirRSwKdXBLE27NAjL6/YNs0liJr9YsCMbCiL3bm0MNghUyY+phl2PfljNKm5Cg51VF6LTnxJdbomzJ2p+d+/Sd+RsvK3S9CTpTt3pR5Cv/Oez688wMHZmmxCha1ynBp1iUQqbGe1SKfPlvl5B+dH56F1tMkcAKY1Q== 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=QSsPEhSqYtAUWFgSxFfeptI40ZNsE6nLejj9bfMpIkM=; b=TYn+Bf4f7o30sXgZJnFfGUQYdoFHxFyF1y2cF7/ADmIMb2lkqAftuLD7hi9U/uXr8UFyaLT5fmZZZioOGUKt40Mu81VVmxZcNo6Q7QXMvN89tD1EUEubEVlTamYTo8V0sdwy1vheTNM1q4zeeawhxv77K2m04ns6xVJrA9cd1TYP5WyQRcFbKOhyhSwX5Es16SLdwh7Jgmjg6qSqDmYmn+fWCdoJsCvf3+dQrZ+cIdBTXCgleLwh8/76BTrExD/CHfET86FwNwDIX0b+lfgf+zbJUQQxFCw2uvUktZvWySxRPY+dgTD5m5iyL/JE/XYJqkL5qUupo72RMuULBOwICQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 58.252.5.68) smtp.rcpttodomain=linux-foundation.org smtp.mailfrom=oppo.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=oppo.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oppo.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QSsPEhSqYtAUWFgSxFfeptI40ZNsE6nLejj9bfMpIkM=; b=Dn2ixvYNJsOYfge4J0vfGC+ksLHOeWCIz9VGjwa+8LE4iLVJjEW2EkxDmLx+9KweYJW7RWvfAytmgKxUnXp+IK51MzRSMLLnMYhsors/V6/XbiruBc5ZiKKSpFaHWjLVGK8xogctXLQErdsCV8ci6TCTQxPXUU9trMcS5tycAqs= Received: from SG2PR02CA0002.apcprd02.prod.outlook.com (2603:1096:3:17::14) by TYUPR02MB6276.apcprd02.prod.outlook.com (2603:1096:400:35e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7611.30; Fri, 31 May 2024 02:48:29 +0000 Received: from SG1PEPF000082E1.apcprd02.prod.outlook.com (2603:1096:3:17:cafe::94) by SG2PR02CA0002.outlook.office365.com (2603:1096:3:17::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7611.22 via Frontend Transport; Fri, 31 May 2024 02:48:28 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 58.252.5.68) smtp.mailfrom=oppo.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=oppo.com; Received-SPF: Pass (protection.outlook.com: domain of oppo.com designates 58.252.5.68 as permitted sender) receiver=protection.outlook.com; client-ip=58.252.5.68; helo=mail.oppo.com; pr=C Received: from mail.oppo.com (58.252.5.68) by SG1PEPF000082E1.mail.protection.outlook.com (10.167.240.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7633.15 via Frontend Transport; Fri, 31 May 2024 02:48:28 +0000 Received: from PH80250894.adc.com (172.16.40.118) by mailappw31.adc.com (172.16.56.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 31 May 2024 10:48:27 +0800 From: To: CC: , , , <21cnbao@gmail.com>, , , , , , , Hailong.Liu Subject: [RFC PATCH v2] mm/vmalloc: fix vbq->free list breakage Date: Fri, 31 May 2024 10:48:20 +0800 Message-ID: <20240531024820.5507-1-hailong.liu@oppo.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Originating-IP: [172.16.40.118] X-ClientProxiedBy: mailappw31.adc.com (172.16.56.198) To mailappw31.adc.com (172.16.56.198) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SG1PEPF000082E1:EE_|TYUPR02MB6276:EE_ X-MS-Office365-Filtering-Correlation-Id: 6fb0567e-223a-4246-2485-08dc811c266f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|376005|82310400017|1800799015|36860700004|7416005; X-Microsoft-Antispam-Message-Info: =?utf-8?q?lJUdXVxA5pG+/+IKAfAuCZEcULcDLCt?= =?utf-8?q?i/MN9BoakJpDS0CfG9dl+0G9aCZVijQVGGTYqWBTOJhr5d3EXVa3g8YS0I+JpEQUp?= =?utf-8?q?FikSWVvZzofXpITgNnWXPdKJTu8RhkjxTrr9pdrzNm+eKro7iacGP9AxIxVcDU4Qy?= =?utf-8?q?zujOhjW2beWsnl6qOz4XvcFNtjbTMDXeQtsimhq8KVGNFCbVUxGprSQ3qd1fv5yvw?= =?utf-8?q?RRzHQ8IzVIlA+4hb1maVM3aGpqR8x/UNAVjZV8Lp6moxuLgngOjpUxiRGmDRxPwJH?= =?utf-8?q?uosLaXhQCBrG7E9XodhN11zqfmuxfUNBRc4aLFWGmtCqqdKRRhOUwXg6lDTHtd+91?= =?utf-8?q?MiNFj0T0YQxjUOyQrjFdx35LGmSOb7+gh2t+7T3WkKcHJamSVNTdARnljEjKrxHW4?= =?utf-8?q?b0erPb2sbH1SCzGHVX5M/yjtwYK8NRDRKAV+uxLRR5HmxT3wwxvRaHr4DYcZRvGEu?= =?utf-8?q?EjIHjtJt8/QGX/wsUUl2mR85LMEGRpK17OkagP1c71Gtn/+FAOz1szkNkE5HHz+kn?= =?utf-8?q?rRVL0Ynq0c3CnkVIizAH9pBTMC5MWMmXs7P9UhR4QZ6Y68Y3Pv8/1OxTQsdODX+oK?= =?utf-8?q?Tu3LmQ0SId070GMMKZx6UtyplNVQE1kVPgBF4GZjR97Mrr1ijrdzF1IAMwB6dUoeZ?= =?utf-8?q?XLvfKoPs75rliYKAaFGjy/Zd+u1Ar0byKzEmq4uFNv+Yhd1ylVKnQnIAUlIX6ax2E?= =?utf-8?q?r2P9kJNODOp4qFOlZJK6R8saxFsFqU8rl+z1lNUZ0yhyyCleIRf7HU6frnQtpcFTD?= =?utf-8?q?6Lq/1kP8LufMb8Qt5yUPSf32ErzGnCTD7TETbN3iWntOHJulz1YbXDrQbg2/NuYaZ?= =?utf-8?q?sJTy8J7Yd2GO+kG8qWTShkPX1QKS2wfl9Iyvyj765D6zjY0ZHL/sstjq3IE5wfr15?= =?utf-8?q?L70u5gCPGjOyk7szNbrTmfDZfUa75aaBBzWUI5EKuJOYvUeF/VfB8/FznX2EmvdMs?= =?utf-8?q?XPVP9OKoQN0GhGXrzpLNRjNWPbkn8H1f2k+lT9pD5j11tkI/1ReCOYmZESBNTocbm?= =?utf-8?q?tuoHlYi15Cq5nCs6NsIsPQjGrMySRSi/MYnf4IkjshvavZGojNZEMtzd0xULaO4Vb?= =?utf-8?q?TjDZOP7SOXoTxN4L4fcuzktvZ5Q0s4ga/mq9EGWXBsuYzCtvK6UrdCk2C+yltGqc2?= =?utf-8?q?Q0qa2wUJr/rGg+ydt3nyIxCYB3H0hXCJ7/jXaJSopf8WRkJcILPTPOmcKcEUv4RRh?= =?utf-8?q?oiUg1InG6yZ9VzF/DMwy/MdqF6keVcOQQl+bKd2x10t2JEpqyVEQO6WzOCT2pJd+4?= =?utf-8?q?JxUJDFogStg1a?= X-Forefront-Antispam-Report: CIP:58.252.5.68;CTRY:CN;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:mail.oppo.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(82310400017)(1800799015)(36860700004)(7416005);DIR:OUT;SFP:1101; X-OriginatorOrg: oppo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2024 02:48:28.2559 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6fb0567e-223a-4246-2485-08dc811c266f X-MS-Exchange-CrossTenant-Id: f1905eb1-c353-41c5-9516-62b4a54b5ee6 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f1905eb1-c353-41c5-9516-62b4a54b5ee6;Ip=[58.252.5.68];Helo=[mail.oppo.com] X-MS-Exchange-CrossTenant-AuthSource: SG1PEPF000082E1.apcprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYUPR02MB6276 X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 066994000D X-Stat-Signature: mfiegm95koneq43rij5wp8tfy117y4hc X-HE-Tag: 1717123715-593686 X-HE-Meta: U2FsdGVkX1/w2763XHA2W/bVizR1d3HmnkuBYvCKgsuQp5fZaTSDBmBPlnTimGYEDQKx/amy054dX5xf2+7SGwgxUWAnos0CrUOF6EGYSXlGlK4/r3jMolVStMKJH8KGIpjPESTujRpz2Nx8X6Fi1nIrAP/0RXXG92XDKiCvcnTKdM+YSMnrLxeS+U3fR7VuO2J27GETC8XMKUk7h7Em12AymMIhPvnAGSDG32FCtbfBAlw9jAUvVVvDa7WZsbInLq/2qAZGxJH4d07oXt7ViavkKddfQkjLY/59B5v+Zh867ojYYu/iB4geovgk4pAKyawAg+SFmhYQnK+UrU3zueo7aLDHucOKVbcGngDzlW0Jl2KfOM4LcqNMsrhJ9Trv/wu0cnjnyNM9u61RT8jTjaDdCzbx9sQH5NqF3doqUV3oS3REV+cBBSppZ5+H4tzmXzt27+QWTJbZerInji5gXb2nuukG4Egji2fGOZFtFCAR9IYWhUGhaqhEvp9g/iBkjh2DFmX9b3V2B0+7TotvSqPtdPPd+6PvPTcbvKi8EdxiYRDpKztBBM1MBfGxxV5E6p1eNKs56zlooMA+/rc6Kb0u6Y6fvTD7iXIBeCf+CFl/5IcTDyonTi/Rdx84g1wq+gr+bmZH1vKnlncTGYsj66Mq0NsTtcvdpCesehgYsG7pCKd4Ky7A4sBciRVoLFi2TMDnfYk+H12oXbEa0gIkS5Gtsm7vuRflBcdQ1Id9u4m5nclYk2NSotJUWOHFWi3y/4HbUYdXS0b0LC1I737G/ZyI4wBGPh48dne9eLaFC40kq5XRFnthMGXZGDGYNgctljZxIOq+i+i5TmwjTStL7RyB12rNmHlxLNiGxZuUo42HE42HxAd9lYzJ7tSRS3loMlNYOCVAAuaCmvqpPCW28NzRhhVmaGt6be0sFKHoR1NkVuCxSpFuu5swsnvboOXz/HR5EgATuMUhfP8aDKi OcQJnFoQ n0NXOoqls6eCszaQ89sfWCJhqBegsSsXsUPVeubGFm6/NnSA2OFpVPIDNrG/YT8bYhKqfcxf5Lv1DXtkzpPunCTX5YH6Vpd0wf5fGoERT4svo5TiFF9yD/vWMbhbpfouLghyp+doK/5IcRAMoXGNU/NKZYPNcEtMF7b8p2i1bqWMdn15uPwGNDeby2Cn9NobFCxgZHMDfJZmSIjE/MiZ9DJPzPWl3dtbUBijGaON9hUuWzeEagRv+7XdvU8633714FSIPGagqZL8Oe9KSncoL1Jdu2O2+Nv0famBQYcmb86O09CjfZhzoYOBfB1iP0ijzbDbZxvz6Cl0WdteQtowhfFK9yXDFck3WT+e/BcrRnGG6Ij+k9lt8wud0NfRVKEDDKWCSNaYdN9ZOTZR9+YcNbKoclMqyUk9HSDDtwYusVqhdRQ5YXUhzbXJV4tacQthOhJBpp6MYbW3yNwMnLn4lfyHZyNPmBoERHAIW7iS+z3IF7g5SE7ubtFnWEMa/ZlZDIH5VK0D6ef88tlfuNpUq4DJARg== 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: List-Subscribe: List-Unsubscribe: From: "Hailong.Liu" The function xa_for_each() in _vm_unmap_aliases() loops through all vbs. However, since commit 062eacf57ad9 ("mm: vmalloc: remove a global vmap_blocks xarray") the vb from xarray may not be on the corresponding CPU vmap_block_queue. Consequently, purge_fragmented_block() might use the wrong vbq->lock to protect the free list, leading to vbq->free breakage. Incorrect lock protection can exhaust all vmalloc space as follows: CPU0 CPU1 +--------------------------------------------+ | +--------------------+ +-----+ | +--> | |---->| |------+ | CPU1:vbq free_list | | vb1 | +--- | |<----| |<-----+ | +--------------------+ +-----+ | +--------------------------------------------+ _vm_unmap_aliases() vb_alloc() new_vmap_block() xa_for_each(&vbq->vmap_blocks, idx, vb) --> vb in CPU1:vbq->freelist purge_fragmented_block(vb) spin_lock(&vbq->lock) spin_lock(&vbq->lock) --> use CPU0:vbq->lock --> use CPU1:vbq->lock list_del_rcu(&vb->free_list) list_add_tail_rcu(&vb->free_list, &vbq->free) __list_del(vb->prev, vb->next) next->prev = prev +--------------------+ | | | CPU1:vbq free_list | +---| |<--+ | +--------------------+ | +----------------------------+ __list_add(new, head->prev, head) +--------------------------------------------+ | +--------------------+ +-----+ | +--> | |---->| |------+ | CPU1:vbq free_list | | vb2 | +--- | |<----| |<-----+ | +--------------------+ +-----+ | +--------------------------------------------+ prev->next = next +--------------------------------------------+ |----------------------------+ | | +--------------------+ | +-----+ | +--> | |--+ | |------+ | CPU1:vbq free_list | | vb2 | +--- | |<----| |<-----+ | +--------------------+ +-----+ | +--------------------------------------------+ Here’s a list breakdown. All vbs, which were to be added to ‘prev’, cannot be used by list_for_each_entry_rcu(vb, &vbq->free, free_list) in vb_alloc(). Thus, vmalloc space is exhausted. This issue affects both erofs and f2fs, the stacktrace is as follows: erofs: [] __switch_to+0x174 [] __schedule+0x624 [] schedule+0x7c [] schedule_preempt_disabled+0x24 [] __mutex_lock+0x374 [] __mutex_lock_slowpath+0x14 [] mutex_lock+0x24 [] reclaim_and_purge_vmap_areas+0x44 [] alloc_vmap_area+0x2e0 [] vm_map_ram+0x1b0 [] z_erofs_lz4_decompress+0x278 [] z_erofs_decompress_queue+0x650 [] z_erofs_runqueue+0x7f4 [] z_erofs_read_folio+0x104 [] filemap_read_folio+0x6c [] filemap_fault+0x300 [] __do_fault+0xc8 [] handle_mm_fault+0xb38 [] do_page_fault+0x288 [] do_translation_fault[jt]+0x40 [] do_mem_abort+0x58 [] el0_ia+0x70 [] el0t_64_sync_handler[jt]+0xb0 [] ret_to_user[jt]+0x0 f2fs: [] __switch_to+0x174 [] __schedule+0x624 [] schedule+0x7c [] schedule_preempt_disabled+0x24 [] __mutex_lock+0x374 [] __mutex_lock_slowpath+0x14 [] mutex_lock+0x24 [] reclaim_and_purge_vmap_areas+0x44 [] alloc_vmap_area+0x2e0 [] vm_map_ram+0x1b0 [] f2fs_prepare_decomp_mem+0x144 [] f2fs_alloc_dic+0x264 [] f2fs_read_multi_pages+0x428 [] f2fs_mpage_readpages+0x314 [] f2fs_readahead+0x50 [] read_pages+0x80 [] page_cache_ra_unbounded+0x1a0 [] page_cache_ra_order+0x274 [] do_sync_mmap_readahead+0x11c [] filemap_fault+0x1a0 [] f2fs_filemap_fault+0x28 [] __do_fault+0xc8 [] handle_mm_fault+0xb38 [] do_page_fault+0x288 [] do_translation_fault[jt]+0x40 [] do_mem_abort+0x58 [] el0_ia+0x70 [] el0t_64_sync_handler[jt]+0xb0 [] ret_to_user[jt]+0x0 To fix this, replace xa_for_each() with list_for_each_entry_rcu() which reverts commit fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilized blocks") Signed-off-by: Hailong.Liu --- mm/vmalloc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- Changes since v1 [1]: - add runtime effect in commit msg, per Andrew. [1] https://lore.kernel.org/all/20240530093108.4512-1-hailong.liu@oppo.com/ BTW Reverting other people’s submissions is a foolish act. But we need a mapping from vmap_block to vmap_block_queue, I saw zhaoyang already send a patch https://patchwork.kernel.org/project/linux-mm/patch/20240531005007.1600287-1-zhaoyang.huang@unisoc.com/ use cpuid. pls free to use my commit message here to help others clarify the issue. fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilized blocks") IMO, if caller could call vb_free, it would be not used address again. so I don't know whether we need to flush TLB here. and loop through from free list looks more resonable to me. -- 2.34.1 diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 125427cbdb87..4c65e9678b83 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2806,10 +2806,9 @@ static void _vm_unmap_aliases(unsigned long start, unsigned long end, int flush) for_each_possible_cpu(cpu) { struct vmap_block_queue *vbq = &per_cpu(vmap_block_queue, cpu); struct vmap_block *vb; - unsigned long idx; rcu_read_lock(); - xa_for_each(&vbq->vmap_blocks, idx, vb) { + list_for_each_entry_rcu(vb, &vbq->free, free_list) { spin_lock(&vb->lock); /*