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 BDBE8C27C4F for ; Fri, 21 Jun 2024 10:45:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 44F2E6B05DD; Fri, 21 Jun 2024 06:45:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D7826B05DE; Fri, 21 Jun 2024 06:45:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 203C06B05DF; Fri, 21 Jun 2024 06:45:39 -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 F23406B05DD for ; Fri, 21 Jun 2024 06:45:38 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6C4B940CE5 for ; Fri, 21 Jun 2024 10:45:38 +0000 (UTC) X-FDA: 82254564756.25.EE600EB Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sgaapc01on2044.outbound.protection.outlook.com [40.107.215.44]) by imf22.hostedemail.com (Postfix) with ESMTP id 05031C0022 for ; Fri, 21 Jun 2024 10:45:34 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=oppo.com header.s=selector1 header.b=gBsxRt9h; spf=pass (imf22.hostedemail.com: domain of hailong.liu@oppo.com designates 40.107.215.44 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=1718966722; 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:in-reply-to:references:references:dkim-signature; bh=jlVvWLkDz8GUbyHNkXsElcbog7x/l+YsIFtAHSBM2aQ=; b=YXMXYt7vvzf/znGrkdDHTSm6spRHRkW3aYtOWNlC2TzFW9+mHvg5sV86vMHoBDeInvpai3 YQk5btkdbYWZaJhEZRTS9You9xZUwoO8bZuuZnO/bLHYx6E6nuShmjL82O2qSJTaoWe712 La3O6bqBIRWQxEYg9C+bqoDKNLcZG2o= ARC-Authentication-Results: i=2; imf22.hostedemail.com; dkim=pass header.d=oppo.com header.s=selector1 header.b=gBsxRt9h; spf=pass (imf22.hostedemail.com: domain of hailong.liu@oppo.com designates 40.107.215.44 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=1718966722; a=rsa-sha256; cv=pass; b=xPH4xMlUcKtai8ZBvZAN+9nIwlamM0mwzm6zsB+3WH7deg3es5h1uWcQ+0rCCLcdggHwF5 TSjUd7fB+W/161xGZibIx6PUsaeM9JJoaakft2PVSReuKoYJhnzg2OP7yioI3ErO1+f+h/ bA0aOj6obbnWyyXFdu6GM5I61HtU3Os= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DzoZGrGMaNqc40GZYZIauB486WpIkcTOOGGhoQcjjWUqDaDSUplQHqGKxFLZZRjrJU3eibL+/KbFS8mL3/xc++3Ccfj3lOKZzx4l18vknZetGUrI+awlvlpUHFhyGDYbQbhjnKGjKTKhURZbwQyWqf60aigCO2m+Uqe8SbvIU7PJ6dQxDZt8ZR6ixWcgnlRPuAoWl6Nr7xNRUEYyo6TmuE8HOCyCRG7PO5mFekwcJJoBfAuPtO80VH4RB1dTMjNRrjJfuxMIPxJD1FLPMQ+NzsOy4oS1KixQYHsBSV73RyVe8iESvtKP2wQhkA2eRQniOmYz2dRSbv6k5YgLf3dkfQ== 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=jlVvWLkDz8GUbyHNkXsElcbog7x/l+YsIFtAHSBM2aQ=; b=h7dccqUERyrK0lAviDrXZcYiCVUJWVBui1g8bz9OaJG4p8/e4yKlV5ZDrPTMqG7gwPUREegwkQ2Cx8K11bPkVy85VaRTyzZqm6Yiyr7VFDl2tuqjK/Tg9pY9ZUBnYXiVmohZnyqdCkG1eVqpFijARL5tG9s4nlhwrJtEpwDKxbOfnyNbpORxmiHwOGdAxut+OiJqjrQ3UUePZKtgSIhug2cBewwrtwCBDvgwM/tO6c79WcbisL/awACx5NOY77CnHz7xv8NF2QDXQZkD7yBZteAearL001IW2l0wu7/xFJvotP6BA1yWuacanfKFEZ08PN7sam2DdYV3xu7/bnmYhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 58.252.5.68) smtp.rcpttodomain=gmail.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=jlVvWLkDz8GUbyHNkXsElcbog7x/l+YsIFtAHSBM2aQ=; b=gBsxRt9hyBXzvCNVi+l1e1Grw8nEMgHzQYdAp2uPxpHLpSeeDhsH+Ntxzik/5McAjzvshbBFpAfrcGyFWqp+l48OgzDNaNE8KFoq/8ORM7KMc+gDWflb0AWGa/0RJG6ORhPtZLsBWzCNWSofRwd6pFuAgVz94zNBh1vr+dH2PdI= Received: from PU1PR01CA0035.apcprd01.prod.exchangelabs.com (2603:1096:803:16::23) by TYZPR02MB7080.apcprd02.prod.outlook.com (2603:1096:405:2f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7698.19; Fri, 21 Jun 2024 10:45:28 +0000 Received: from HK3PEPF0000021A.apcprd03.prod.outlook.com (2603:1096:803:16:cafe::5) by PU1PR01CA0035.outlook.office365.com (2603:1096:803:16::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7677.36 via Frontend Transport; Fri, 21 Jun 2024 10:45: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 HK3PEPF0000021A.mail.protection.outlook.com (10.167.8.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7677.15 via Frontend Transport; Fri, 21 Jun 2024 10:45:28 +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; Fri, 21 Jun 2024 18:45:27 +0800 Date: Fri, 21 Jun 2024 18:45:27 +0800 From: Hailong Liu To: Uladzislau Rezki CC: Baoquan He , Nick Bowler , , Linux regressions mailing list , , , Andrew Morton Subject: Re: PROBLEM: kernel crashes when running xfsdump since ~6.4 Message-ID: <20240621104527.hzu3tsu2pwhxbhzt@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="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: HK3PEPF0000021A:EE_|TYZPR02MB7080:EE_ X-MS-Office365-Filtering-Correlation-Id: abde0a8f-c712-4d7e-b04a-08dc91df43fe X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230037|82310400023|1800799021|376011|36860700010; X-Microsoft-Antispam-Message-Info: =?utf-8?B?aU9WVHhPSWg0R3JKTTVXMGVSU3FNVGcxUFhUVld3S2hMZ01qSDg1bFAwalJZ?= =?utf-8?B?QnBjSHNRNWVHR25uYmVUWVRrb2llSGlRKzRHQVJTdkM5R0o4RDQ5U2JwUjlk?= =?utf-8?B?dFk0QlB6RXhuT2xZdGhOOE16UitLcjJ4QnRKWFMxd0xPTnhsTjF4OVEyUUJt?= =?utf-8?B?U0RKQjE2dmk1N3FCcDNGbU1VQ2RWNkkySnlxbjIxSldDSkdKZWJDVy9wNDEx?= =?utf-8?B?VitlTjRIdFBhWHNuYXBwbU40MVArS21YM2tnb1pIZC9ZZ3JUd2MzZ0k3ZVFV?= =?utf-8?B?TnRhVTN3dHlPRXljUC8rTFB4dTdqeWhHNnllYitnZmVZWXVZdEpRK2p1K1Nt?= =?utf-8?B?VzVjOGRnbENSbkQwYXp4cDd4ZUZBbmJBR0tJcXpyOUpXOGFnWGNicDRaUTVo?= =?utf-8?B?MUxkZDZqamcxckprUFhYUjcyL0hLQ0xXMkhsZldLMSt3cWFBeG0yM0ppbDRJ?= =?utf-8?B?Q1RpUDZZR0s5RUpVTzk0YWIrSWVlMGkrK0h1bFY1azJXRXNvb1hFQXE3TVQ2?= =?utf-8?B?ZGFYd1o5NXFHLzJhNTl0QUNFeGpzZEpPOUJ2Yk82ZXczVXduZGNqSlNReFMr?= =?utf-8?B?OXg1S2VOemNIMURiTlBwcUVQQTFHenM0N3VhK3pmTEQ2TVBmT3EyVXdOMGxq?= =?utf-8?B?WUgyQ3pKVXMzQWFiRy8vNkZGUXJoS0tpNmd0dGpmUVNSTGpxSXRib3ZvREJR?= =?utf-8?B?UzY1ZEdHcEd3c1paWnJNcWJLRWp2bGZIQkx5VGIzbzVXZFBldXNnQzk4QmtC?= =?utf-8?B?T3M5d1g0QndZVUdaOTRXc3NkY1E2MFk1R1Q1S2JZUVh1aGQ4WE01WE90c0Fn?= =?utf-8?B?bjB0ZGdxQUtuTkdOSm5wSi9waTl4SExSajJJRXpwaVJDRGNHK3drZk5CZFdN?= =?utf-8?B?cHRCWkNDSTA3SkgxN0dJTmJFQWt2aWJPcU5VRUpCQjN6WHNyZDZYY1Q1OXlj?= =?utf-8?B?UzF3WTlNQjhKYmFMYzh0c2NhSFFPNTVzVStiZmNqbGFJQ2NWT3crckErQlZF?= =?utf-8?B?bkZ1bDJUSjVMV1FPbG1sQVAxRkplZzFDaVdMSGZuSk1nalo0TWdYMHJkN3hY?= =?utf-8?B?c2lkMTBRN2hhVXpxeVZHN082ZHlvc0Rrd3JpeDFKMTNQN244WFk0MzduMlVV?= =?utf-8?B?cHhLUE1ISFNOSDRoc2c3OThFL0VNb2RWbFhjamtpMGYrdU1ZSjl4Z3NaSkFa?= =?utf-8?B?K1l0eFJ1ZzVtU3pKN3VHMWhUbkxDUHZaWitIWHJaQmlidnR6dGJlWCtnT25j?= =?utf-8?B?OFZoajBXeXlEYXArcFZRTUkwU2NpeUhldnFlMEVBV0VGTklENDZlVVprZWJ1?= =?utf-8?B?TUEzRmtVSkQ3bXBqbzlLMVNFRFdVZndieTVlL21JN2tIY2ZjbDcyeVZ0ZnBq?= =?utf-8?B?cFkrRURGcElHREVXNXBVdG96TllFUlpTbUhiY3NQTnA0WWVVaFJtdnU2cy9x?= =?utf-8?B?SVVBQUUreVlqVzlLNmp3VkJndmJkYzJ2cXdXR0IzQUNBVGVmc2FQR2tZTkdO?= =?utf-8?B?UkdCMEJXK1AyTWQ3dUdEeXhJcnJrdW5kWjhEZisrdW5qSGp0bXNqdW14bU1j?= =?utf-8?B?blAwMmFEQzNEc2pnL3F5SFY4d2cyZWRtWS9VL3hGNUJ2U2N4VUVsUnpybk1N?= =?utf-8?B?MGlGMkVSZFAxbi9McHlMOTh2TlU3Z3lmVFJOdWw0VGNPalorcUVnbkh1N3Fy?= =?utf-8?B?U0srYnh6MzJYOGhOc0hsK1hjM3kwK21DM3g3N0tBdFU0aWZWbUh0Yy9jdVds?= =?utf-8?B?Qm9ZKytiVU5nQjVyOSt1NG5hNm1oVXJickV3cmEwRWpVMFM1RzNFL2l1VGMy?= =?utf-8?B?UDdtSmVNU2hvbUNMV0dMZlpUQm9HVE1aODEwc2Q2MGJ4SWk3MjlDVkFZWW9N?= =?utf-8?B?RmUxQ1FvbHZKMTkvdHhwNUo0OVJwdml6RWQ3alRYOWNVZkE9PQ==?= 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)(82310400023)(1800799021)(376011)(36860700010);DIR:OUT;SFP:1101; X-OriginatorOrg: oppo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2024 10:45:28.2548 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: abde0a8f-c712-4d7e-b04a-08dc91df43fe 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: HK3PEPF0000021A.apcprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYZPR02MB7080 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 05031C0022 X-Stat-Signature: 4r6ffswkq9jqcqjjuf3rswx3uyxtfqzj X-Rspam-User: X-HE-Tag: 1718966734-645578 X-HE-Meta: U2FsdGVkX1/ZmI2NBMsidsukHnxrBPxCf1LcOG/YfTOPlAZTDfJNtoq1NDlt4MgGVcDTsqHtkdZn3C/xVPuFqw8pTysLyWUtoY8c+srWIfzpvBuLnEEkjDz+QpoepdJzSZhjstm1f2FTyVMj1qc7gx3NtdpEKUVGlFauL5JfI00kHZuZ1IyxVPwfYsSoPSXJIXi1NcWTSGxLr6/RxpkkesHz3GazOd/SV0Zl8YxgYTUSf3gONrXXatCMBx32TWg2rnw5gt9svbAul7tYfa50GogA0tm0VmV3FnpE8xxSwAEGtjLV1m7ppLpiS4b4ixL+suuNvfsYhbqo3MCnlKGleidp0u7w85mWbuSfs6d3JjG5GmUaebFAZP/fHxLCuk2ehir5CqHJDJP22qXbPqZFkIl5ldjNOoNiUjk0s8YGJOnmqMx15/z0AeSxjJ/vZnbV5ybqUJX0T+XYRmEk7SX6x8LUYx4ut/RMYN6zR01bw3ZnfkfKoGSTOPXx8GzDsVn42C/ri2QNoh4gTeVefsrKZqp5DmPG9j6XphSa/Y/vI/v3dtisujOlBjB6et5cjUMb56D9E/4yitK1nhmHMcA4hIf0ReqsA1tzbFOaatN0NnYbuzM25l3Hg4dyWN/0tDvkGBIKIjB3DzUMnVSrPDEUqRjKfm/aNy2l/hQI6WFMJveVc8I6fq9mKIWDYpWJGZF6gcsfndzBy1GkL/WU9rB8/xvOt4xiJRMeQtzJMov7UuOA3504GkAPcWNWBAYY0ZMCqJCjPAQux1i2PQcVNussBVajhJK7s0ZFXpnZvreHnW/2ZIbSxyYGjuE0h7h+yluWTeJzoRjzJdr3QaRigGUqG1ZEyS1DhlhfqzDv3m8AR0KNUCjwBM9iAAbi5KHErL4rvNGXW4pHaZl+kczTYVxsZTMawBau5spcEI5W8WO0zQHfBYB4Ylekw0/jFVE3jIO6Mwmz8g0yqDVRLT6Aquf 7r6zOyhI WcyD8tLu1BCJOe9g7eFXk/gPL05mnvUQ9wr7VVI0jV7TQcR6bKe0PcZNrwXYIhKnPIIisybnKn8Wsy0oki+rS8PHdG319aeCKeYOwbRc8yo43cwqOjww4XBypp827qQPnYzZNm6DyY3HjFGY1Q3vnaMds2NbgzES1btw3v4Hr0suKt5ON1Pdw2qedGQ+vAmOG1rntOlhLiKAc1ZhoSCQTOqRIkchW1sa25z4hvYTAL3VBy762D9vmJswAUUgLn/lXpVKQAFvgvXCSCeZEIfMA3Dr6DZItvSvJSJkJY7XXXl/Nl0PzTI7YgHj8teuOHoI5KrJoKRLXywgTOeogkzq/rpp7OliB8xyofNVOvKvlHpedFfK2UAgK/VIroMcUXdA8s0/evfoHdeHHua1S6phym7zFW0JqZb3FEehKQtoecDKnHIdnPuIWCvKCI3UxFAc0Y50S 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 Fri, 21. Jun 11:44, 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: > > > > > After upgrading my sparc to 6.9.5 I noticed that attempting to run > > > > > xfsdump instantly (within a couple seconds) and reliably crashes the > > > > > kernel. The same problem is also observed on 6.10-rc4. > > > > [...] > > > > > 062eacf57ad91b5c272f89dc964fd6dd9715ea7d is the first bad commit > > > > > commit 062eacf57ad91b5c272f89dc964fd6dd9715ea7d > > > > > Author: Uladzislau Rezki (Sony) > > > > > Date: Thu Mar 30 21:06:38 2023 +0200 > > > > > > > > > > mm: vmalloc: remove a global vmap_blocks xarray > > > > > > > > I think I might see what is happening here. > > > > > > > > On this machine, there are two CPUs numbered 0 and 2 (there is no CPU1). > > > > > > > +Baoquan > > > > Thanks for adding me, Hailong. > > > > > > > > Ahh, I thought you are right. addr_to_vb_xa assume that the CPU numbers are > > > contiguous. I don't have knowledge about CPU at all. > > > Technically change the implement addr_to_vb_xa() to > > > return &per_cpu(vmap_block_queue, raw_smp_processor_id()).vmap_blocks; > > > would also work, but it violate the load balance. Wating for > > > experts reply. > > > > Yeah, I think so as you explained. > > > > > > > > > The per-cpu variables in mm/vmalloc.c are initialized like this, in > > > > vmalloc_init > > > > > > > > for_each_possible_cpu(i) { > > > > /* ... */ > > > > vbq = &per_cpu(vmap_block_queue, i); > > > > /* initialize stuff in vbq */ > > > > } > > > > > > > > This loops over the set bits of cpu_possible_mask, bits 0 and 2 are set, > > > > so it initializes stuff with i=0 and i=2, skipping i=1 (I added prints to > > > > confirm this). > > > > > > > > Then, in vm_map_ram, with the problematic change it calls the new > > > > function addr_to_vb_xa, which does this: > > > > > > > > int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); > > > > return &per_cpu(vmap_block_queue, index).vmap_blocks; > > > > > > > > The num_possible_cpus() function counts the number of set bits in > > > > cpu_possible_mask, so it returns 2. Thus, index is either 0 or 1, which > > > > does not correspond to what was initialized (0 or 2). The crash occurs > > > > when the computed index is 1 in this function. In this case, the > > > > returned value appears to be garbage (I added prints to confirm this). > > > > This is a great catch. > > > Indeed :) > > > > > > > > > If I change addr_to_vb_xa function to this: > > > > > > > > int index = ((addr / VMAP_BLOCK_SIZE) & 1) << 1; /* 0 or 2 */ > > > > return &per_cpu(vmap_block_queue, index).vmap_blocks; > > > > Yeah, while above change is not generic, e.g if it's CPU0 and CPU3. > > I think we should take the max possible CPU number as the hush bucket > > size. The vb->va is also got from global free_vmap_area, so no need to > > worry about the waste. > > > Agree. > > > 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); > } > > Sorry to trouble you. do you mean as follows: @@ -4480,7 +4480,7 @@ void __init vmalloc_init(void) */ vmap_area_cachep = KMEM_CACHE(vmap_area, SLAB_PANIC); - for_each_possible_cpu(i) { + for (i = 0; i < nr_cpu_ids; i++) { struct vmap_block_queue *vbq; struct vfree_deferred *p; That’s exactly what I was thinking for the first solution as well. However, Do we really need this for the impossible CPU's variable initialization? How about using the index to find the CPU? Just like the following, but this is not the optimal solution, and it also wastes a lot of CPU time :). @@ -1994,8 +1994,12 @@ static struct xarray * addr_to_vb_xa(unsigned long addr) { int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); + int cpu; - return &per_cpu(vmap_block_queue, index).vmap_blocks; + for_each_possible_cpu(cpu) + if (!index--) + break; + return &per_cpu(vmap_block_queue, cpu).vmap_blocks; BTW, Using raw_smp_processor_id in this manner is incorrect; that’s my mistake. > 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. > > Or i missed something in your patch, Baoquan? > > -- > Uladzislau Rezki -- help you, help me, Hailong.