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]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4767C2BBCA for ; Tue, 25 Jun 2024 11:20:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A6526B02F0; Tue, 25 Jun 2024 07:20:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1556F6B02F1; Tue, 25 Jun 2024 07:20:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE9DF6B02F2; Tue, 25 Jun 2024 07:20:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D19046B02F0 for ; Tue, 25 Jun 2024 07:20:12 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2D306C189E for ; Tue, 25 Jun 2024 11:20:12 +0000 (UTC) X-FDA: 82269167064.13.027701D Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sgaapc01on2068.outbound.protection.outlook.com [40.107.215.68]) by imf20.hostedemail.com (Postfix) with ESMTP id 772241C0006 for ; Tue, 25 Jun 2024 11:20:08 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=oppo.com header.s=selector1 header.b=Y1hu+Ik7; spf=pass (imf20.hostedemail.com: domain of hailong.liu@oppo.com designates 40.107.215.68 as permitted sender) smtp.mailfrom=hailong.liu@oppo.com; dmarc=pass (policy=quarantine) header.from=oppo.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719314389; 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=WZJIX06pp3yB4FbFPKqcCmRxoWu5HS/PJHew8jMD4lM=; b=XDd+ssMeLGzEvm7RKxsJNAyhNt6/jUDf68wKmexdufochpYYfcy0qcic3/VLhDRXM8m5b+ ul8gV20ESWHiGM+9khWUxV4Ij8fJF8Z6ySl0ixt7Xq7SB4dBtQ6H4eXJ4aobf0K9sYxfBs jrvAAIubyj0Bdc0tJCzTfOXIfD11pvw= ARC-Authentication-Results: i=2; imf20.hostedemail.com; dkim=pass header.d=oppo.com header.s=selector1 header.b=Y1hu+Ik7; spf=pass (imf20.hostedemail.com: domain of hailong.liu@oppo.com designates 40.107.215.68 as permitted sender) smtp.mailfrom=hailong.liu@oppo.com; dmarc=pass (policy=quarantine) header.from=oppo.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1719314389; a=rsa-sha256; cv=pass; b=Qpn6+vig7dD6jhsE0qpbmEsWq2Z8TwpC31crx491uSaue2XDvkIeU4IHJFCbK1ya1Iy15e +w+9D/PDUnKkP/K9nCALXwbgqEHTIFEQfDlKnxxT5Vgu1LIdoAyrOhXYm4r8iqPEe7YDuZ prl79c1X+12XPZnxJh4qSvk9ipTdS+M= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J2Kzm4ItFKj6p8pHhz78DG0ozmzWFEpYqL/dkbQOp2goWr+z4SklXOXGBKterbJOd1JHBqFTNo78xzq5L3cBdvluxVBuKPlXCWNPoAtJGmDqLPcflJS9SfO6KZ/ILJCmnD2tB61o7IXEtvlL9Dpd7vVkZBVuleFNrobN4KDP5PLDqM5BtCf7pX0I8YDIja5Md2BmwSn+A879gGaJhlhMGjQSMP1ir/QZ6aP/LJmYfHybDe+U39OBUSMP2g0A/xhOMs10wJBOvekgusGTerE7EvpsgX/NIbeVVGb8RgV/xBMrreWV+iE+CHaX4odgpjgZSMPu1uf5koTNCc1jw7Hw9A== 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=WZJIX06pp3yB4FbFPKqcCmRxoWu5HS/PJHew8jMD4lM=; b=lel+kc4m60h543iLA+b+1+6IKegVXI+ge8PaGpcjUFto/6YsMLujH6aOQFHCUkZk0zrFsKKm4w3UkBj7DvXDkrKhsD7Nll5Ai6cGvk1XQ67LbhvfyIC0K5i9HAo9zx1kIGub5dn/4GOLSoHY5UlRHZCnIZApEAIeAibgh+WdzU9gGK57uXM7zxjtAuHRMBhYuzPjcZehElvqyHmqLaIT9RC1cwPWIq3ZwmnpIz6kDUjqD5RSdpUAhxlwrAFer8iixn2vx0oyOlAfvpgxjt29P9BhNKF0eIbP1cHbHmhFrx2FE4FFAYn6fhxGnrSQhO4cNB0a31If/g5OclqOZYaNhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 58.252.5.68) smtp.rcpttodomain=redhat.com 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=WZJIX06pp3yB4FbFPKqcCmRxoWu5HS/PJHew8jMD4lM=; b=Y1hu+Ik7iPeZmYz2juG8Nf30J2EpP8wREWV7+eeU36KiKxQQY44ncZyhkUFBo9/5h8qojfKZhyoKXuH8V4Pq+z4DJXKzsWZqb0kZH8ADj69MVR7kzRnpcMeuGCZHdXkYaSeeHIZ+KsClKJD1xnkj3oqdLHNENZv2r98xPwfyT4Q= Received: from SI2PR01CA0050.apcprd01.prod.exchangelabs.com (2603:1096:4:193::21) by SEZPR02MB5885.apcprd02.prod.outlook.com (2603:1096:101:70::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7698.27; Tue, 25 Jun 2024 11:19:59 +0000 Received: from SG1PEPF000082E1.apcprd02.prod.outlook.com (2603:1096:4:193:cafe::41) by SI2PR01CA0050.outlook.office365.com (2603:1096:4:193::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7677.38 via Frontend Transport; Tue, 25 Jun 2024 11:19:59 +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.7677.15 via Frontend Transport; Tue, 25 Jun 2024 11:19:59 +0000 Received: from oppo.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; Tue, 25 Jun 2024 19:19:53 +0800 Date: Tue, 25 Jun 2024 19:19:52 +0800 From: Hailong Liu To: Baoquan He , Uladzislau Rezki CC: Nick Bowler , , Linux regressions mailing list , , , Andrew Morton Subject: Re: PROBLEM: kernel crashes when running xfsdump since ~6.4 Message-ID: <20240625111952.sbeuw2kbx3b465rb@oppo.com> References: <75e17b57-1178-4288-b792-4ae68b19915e@draconx.ca> <00d74f24-c49c-460e-871c-d5af64701306@draconx.ca> <20240621033005.6mccm7waduelb4m5@oppo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: 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_|SEZPR02MB5885:EE_ X-MS-Office365-Filtering-Correlation-Id: e29e50a7-3ce9-4d25-e89f-08dc9508c005 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230037|36860700010|1800799021|376011|82310400023; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?+Tv6U9t64cUDu6lOVeyYVSmHavkfksJ8yQrZ+cirpZI9hcvasucgm14lzH6E?= =?us-ascii?Q?WVqqNeYURD3MX+OBszdu+RX/WuO3fr3wFDcu8gjUglLxEWQnJEwXbvXZnebW?= =?us-ascii?Q?ZSt+G+g17rwtg9yToZutZJ2hi7YxRMEnCkOMYiDPUQyXFZY9S7zGx53RBosQ?= =?us-ascii?Q?NBrrFbgIESkh+XTepScILVevNMO7psNm3g45fdj6l5sqvIFILmPfPLyvtiOM?= =?us-ascii?Q?YuW9esp/C0WnZGL6Fugv4hXfOh+ufHzIJ072PbzN7/JRsqYm3MVchd9dgZcB?= =?us-ascii?Q?GyBI65KNKItwkbEj8C7SzuSAFUNVYsTgFi+aRSk2B1oCmenD9DgSqWlD2q87?= =?us-ascii?Q?i6L1gnJVtjL3twv7/aLbfhk7BZ4YsvATM4b5+X+jzuDXynb3+LDZW6W4t0Gi?= =?us-ascii?Q?1v02kibMuiB6H38Ar4f6L8aNOvdXcyUk9N3zlVu914+YOp+518DoJglHapIT?= =?us-ascii?Q?Zz8cnF/sh5/4rzq3G8ADuoSzwFlsed8g5oDWU6ZoH0sxwBilGRj3QZF+9HAb?= =?us-ascii?Q?1fuMXNyy0lk8CupjRbEvR0qWIWNCAn9WnEFqoBLsJJgNEOYsS9OJYKnwRMFK?= =?us-ascii?Q?Mxfk/eCkzJ4Irq6RY/uNv8obBwLZPuG91ID2+bp+IgnbhQkcPTxzeNwonSG4?= =?us-ascii?Q?rlZLnFdTBhY/dPG14NOrFtbU2/U9z8d2DxgIT8pYJCig+2Jb+ZLxXj7tU5mF?= =?us-ascii?Q?z4bB+9IcfdemaHFC4f/rv7SDZ8uXIRpHXJPBcdReTsoL7ZpTHCLWhEpgKFuK?= =?us-ascii?Q?cG6aNjcL0eULrvk2TP3YZNlEp6rU/96Vsa0kiHv9vuk2NGj+5iEKERV4GdOM?= =?us-ascii?Q?2scCEqVEOWhrbyrJ5K1MKhNTrS1P+aaKkjgH+jaG+O6W4znyfryKI55mYNZp?= =?us-ascii?Q?kvqhmJ5EXXkC7Fxk4w4a76SplqfxPSdYfipHcnkQXe0TbtgwNj+VvON623pD?= =?us-ascii?Q?yREWpPqxxcsQQ/xrVR9sodJJzakuL8YG8ltcLDUVExgjhiRNl1Dd9MnevAk/?= =?us-ascii?Q?Gk9qPPn/xtOaNM/eLLF2O8dY7XpZQoNhmL3Ma3I0iGGVeZ6Syy/EylgFRmfV?= =?us-ascii?Q?tRzUEYGGxMnT30pVKYclk/oYij7910xFlQvcq0mVzozJG3tz1BBoisEp/CJj?= =?us-ascii?Q?rjsups65JdaZxzFcfBhrKWx394qJyA51OxAX423y+eNs41YX4QhX+lkcyjMZ?= =?us-ascii?Q?wkFASsuSGKSN1cRbrusFStzunXzVOIzlrIuVLEKACablCQ/6pgUYQY3uTHL6?= =?us-ascii?Q?w7tMOckh1XM89+rW30A5QmPDb0Z2HCWthrbmOA9Fw2yAtcP273TZGmiUNIxy?= =?us-ascii?Q?MWg2b4dJ186WdP0ymL17QTNh+W/UVkBHs/SD6xZnO98cm1DahlRz1R8brSvm?= =?us-ascii?Q?yeAtd+WAc4tVuEe35KUrUT84oWl05w0jo+fabFK3yYbg0QTG/g=3D=3D?= 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:(13230037)(36860700010)(1800799021)(376011)(82310400023);DIR:OUT;SFP:1101; X-OriginatorOrg: oppo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2024 11:19:59.2720 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e29e50a7-3ce9-4d25-e89f-08dc9508c005 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: SEZPR02MB5885 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 772241C0006 X-Stat-Signature: 9gafeohdqjebp651mdkujzw7fz637134 X-Rspam-User: X-HE-Tag: 1719314408-980702 X-HE-Meta: U2FsdGVkX18nzbn6pLyWX2xEantBJsvm92xNxViLVpkAb+JaLWVZAkFsuBBHeSBwDi2lfkjWEnuLfbWwJuW4P89snZgvIa7q4T/T7YJEnMIxOBwLVwnj4OYfN3EAoye2jZXqq6E4StjhCiTjO/hvT3+qEhn7xJ/u4BIm5TusNstbBUoLXxyv0kF3GgIhgPHudeqpr+uMxqUKFlDHQwM1tSAEssAfkpsbxsLinHw/KMYGilyM82U7iUJNUMTDPmJc+lR8/cCAsRLO39EdEunaEPBskAcrMzIKNz0DRUA2ZHoRDnyguMETd+YrhEsDzUDbW8lOywjF91FmoPiWsboBBesGrw20bYamzbYdL46Lz47DKp6Vca5gKatCV7PVbyCraZh4ClH/p1XeECIqcUXbS6w7eJHekevtLud5unvzqzfs+7cTD5lpTphiqZAbkenCPrAThxhNNjGzBB1VBkuSu9aTGDgIQuJ5SBhNrfaItVCZZRFpD1k9DuMKWpvQSGpW3a0YUqxq05Y87x+ESYXWOJNL5vesHT3J7POOoAMvG5Fe59AJJoWGsi7YHH1imEa1tKVaF/v2Yd34fiWRgU2RqcYL4tMxlZ4GxeowQatb36pUVVqbl5zz5zKDcnESC1dQ5Ji/CRq5YQzU3V2qr1DRPvNs+6lhqSwbkzew0ZI7iDkPfNrDlVcSF873qQT+KevUAl/06Zs7uT/VQL/jpEwIDi5kMYzDygKx9oPw5gDpRbFx3il9lcfQCSNQwfLGppN6WH4sw7vuYk+4fFO2V5GcC793AhFNWFBRiFP+uAALcGTNgmpVg+GoROEMiDFlo5ouNHEvsvN6cOm0hySbnXYw8izea4K744ot+o6I1pSTlKjnD2idQlB3YAwcjy/MFMGQnScWPgBpXIXx/53JKaw5z2cnfmXqjy1jrOlFhX+8ekt22e2adb/UDQtJ2aLKnH083Rd9H+3h5dk13tjTXRj RTwItCLb KmlxJwlEGwTwCwEU1poTuGPwV5LxV+VwvVB1LplXc+ha6cM39ylEMgLCmxt7WIdnz3rkYIPLSrcf/3MyOYyMP9r29UE/HwVSZ+PG/CJ0C63FQAb9n0QMhAv3R4BWpOMoU0jP6H/T6PiNlqkIMeYUWZR7ddRyCOrXv9uc0DR7Bm2V/PvPFH/Cl9ysGND8zvEYHlde+VS/wDgBob2TCv2b2TW5XxHKGubEd6PlrTs5U8UYSrh0KQZSlPhIjJhgAJTepYoKZ/pSxKBmyXeQiQQ6aV8O/R2xpCVNQW50rgDcGJXjIhKyyQfufiH8NcOqr5daCVYu6LnPFgGgLmgNdpruI8Vwltth8tLeUueinOa36An4+vPkgU0M2vcs4rhryyXVbRyQO90pwSC1F8sc= 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: On Tue, 25. Jun 11:30, Baoquan He wrote: > On 06/24/24 at 02:16pm, Uladzislau Rezki wrote: > > On Fri, Jun 21, 2024 at 10:02:50PM +0800, Baoquan He wrote: > > > On 06/21/24 at 11:44am, Uladzislau Rezki wrote: > > > > On Fri, Jun 21, 2024 at 03:07:16PM +0800, Baoquan He wrote: > > > > > On 06/21/24 at 11:30am, Hailong Liu wrote: > > > > > > On Thu, 20. Jun 14:02, Nick Bowler wrote: > > > > > > > On 2024-06-20 02:19, Nick Bowler wrote: > > > ...... > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > > > > index be2dd281ea76..18e87cafbaf2 100644 > > > > > --- a/mm/vmalloc.c > > > > > +++ b/mm/vmalloc.c > > > > > @@ -2542,7 +2542,7 @@ static DEFINE_PER_CPU(struct vmap_block_queue, vmap_block_queue); > > > > > static struct xarray * > > > > > addr_to_vb_xa(unsigned long addr) > > > > > { > > > > > - int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); > > > > > + int index = (addr / VMAP_BLOCK_SIZE) % nr_cpu_ids; > > > > > > > > > > return &per_cpu(vmap_block_queue, index).vmap_blocks; > > > > > } > > > > > > > > > The problem i see is about not-initializing of the: > > > > > > > > for_each_possible_cpu(i) { > > > > struct vmap_block_queue *vbq; > > > > struct vfree_deferred *p; > > > > > > > > vbq = &per_cpu(vmap_block_queue, i); > > > > spin_lock_init(&vbq->lock); > > > > INIT_LIST_HEAD(&vbq->free); > > > > p = &per_cpu(vfree_deferred, i); > > > > init_llist_head(&p->list); > > > > INIT_WORK(&p->wq, delayed_vfree_work); > > > > xa_init(&vbq->vmap_blocks); > > > > } > > > > > > > > > > > > correctly or fully. It is my bad i did not think that CPUs in a possible mask > > > > can be non sequential :-/ > > > > > > > > nr_cpu_ids - is not the max possible CPU. For example, in Nick case, > > > > when he has two CPUs, num_possible_cpus() and nr_cpu_ids are the same. > > > > > > I checked the generic version of setup_nr_cpu_ids(), from codes, they > > > are different with my understanding. > > > > > > kernel/smp.c > > > void __init setup_nr_cpu_ids(void) > > > { > > > set_nr_cpu_ids(find_last_bit(cpumask_bits(cpu_possible_mask), NR_CPUS) + 1); > > > } > > > > > I see that it is not a weak function, so it is generic, thus the > > behavior can not be overwritten, which is great. This does what we > > need. > > > > Thank you for checking this you are right! > > Thanks for confirming this. > > > > > Then it is just a matter of proper initialization of the hash: > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 5d3aa2dc88a8..1733946f7a12 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -5087,7 +5087,13 @@ void __init vmalloc_init(void) > > */ > > vmap_area_cachep = KMEM_CACHE(vmap_area, SLAB_PANIC); > > > > - for_each_possible_cpu(i) { > > + /* > > + * We use "nr_cpu_ids" here because some architectures > > + * may have "gaps" in cpu-possible-mask. It is OK for > > + * per-cpu approaches but is not OK for cases where it > > + * can be used as hashes also. > > + */ > > + for (i = 0; i < nr_cpu_ids; i++) { > > I was wrong about earlier comments. Percpu variables are only available > on possible CPUs. For those nonexistent possible CPUs of static percpu > variable vmap_block_queue, there isn't memory allocated and mapped for > them. So accessing into them will cause problem. Thansk for pointing out. Indeed, I have very limited knowledge about CPU-related :) > > In Nick's case, there are only CPU0, CPU2. If you access > &per_cpu(vmap_block_queue, 1), problem occurs. So I think we may need to > change to take other way for vbq. E.g: > 1) Storing the vb in the nearest neighbouring vbq on possible CPU as > below draft patch; > 2) create an normal array to store vbq of size nr_cpu_ids, then we can > store/fetch each vbq on non-possible CPU? > > The way 1) is simpler, the existing code can be adapted a little just as > below. > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 633363997dec..59a8951cc6c0 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2542,7 +2542,10 @@ static DEFINE_PER_CPU(struct vmap_block_queue, vmap_block_queue); > static struct xarray * > addr_to_vb_xa(unsigned long addr) > { > - int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); > + int index = (addr / VMAP_BLOCK_SIZE) % nr_cpu_ids; > + > + if (!cpu_possible(idex)) > + index = cpumask_next(index, cpu_possible_mask); If cpumask is b1001, more addr would located in cpu3. > > return &per_cpu(vmap_block_queue, index).vmap_blocks; > } > @@ -2556,9 +2559,15 @@ addr_to_vb_xa(unsigned long addr) > > static unsigned long addr_to_vb_idx(unsigned long addr) > { > + int id = (addr / VMAP_BLOCK_SIZE) % nr_cpu_ids; > + int id_dest = id; > + > + if (!cpu_possible(id)) > + id_dest = cpumask_next(id, cpu_possible_mask); > + > addr -= VMALLOC_START & ~(VMAP_BLOCK_SIZE-1); > addr /= VMAP_BLOCK_SIZE; > - return addr; > + return addr + (id_dest - id); > } How about using cpumask_nth to get cpu id ? It looks simpler and more straightforward, it may waste some cputimes :) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 11fe5ea208aa..e1e63ffb9c57 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1994,8 +1994,9 @@ static struct xarray * addr_to_vb_xa(unsigned long addr) { int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); + int cpu = cpumask_nth(index, cpu_possible_mask); - return &per_cpu(vmap_block_queue, index).vmap_blocks; + return &per_cpu(vmap_block_queue, cpu).vmap_blocks; } > -- help you, help me, Hailong.