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 68A7DC27C4F for ; Fri, 31 May 2024 10:52:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0075A6B0092; Fri, 31 May 2024 06:52:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF8C76B0093; Fri, 31 May 2024 06:52:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9AC16B0095; Fri, 31 May 2024 06:52:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BAEFD6B0092 for ; Fri, 31 May 2024 06:52:16 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 726058172D for ; Fri, 31 May 2024 10:52:16 +0000 (UTC) X-FDA: 82178376672.07.97607BB Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2085.outbound.protection.outlook.com [40.107.255.85]) by imf25.hostedemail.com (Postfix) with ESMTP id 176BDA0003 for ; Fri, 31 May 2024 10:52:12 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=oppo.com header.s=selector1 header.b=TS+7fAET; dmarc=pass (policy=quarantine) header.from=oppo.com; spf=pass (imf25.hostedemail.com: domain of hailong.liu@oppo.com designates 40.107.255.85 as permitted sender) smtp.mailfrom=hailong.liu@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=1717152733; 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=wpwGwvYsX9FS3Z1xMFLY4yjARrUbN+yHSAtMqGPH6+w=; b=Hj0aZrKaiciRxz2YbW9VHWOx5eM2IttUHj4yQBYUEs5HvNIeMBaNZUBNUJ/omRp3ubi/dr iOl2wWfYO/vpcl3NeRM0GHyF7OmPN7Tf76n0rnJhlW8QfjZe7en7B/8xJYpOm84g7jxk+r CNZ3BeXbvObcAgd9X0kGpLG6VXGjy4E= ARC-Authentication-Results: i=2; imf25.hostedemail.com; dkim=pass header.d=oppo.com header.s=selector1 header.b=TS+7fAET; dmarc=pass (policy=quarantine) header.from=oppo.com; spf=pass (imf25.hostedemail.com: domain of hailong.liu@oppo.com designates 40.107.255.85 as permitted sender) smtp.mailfrom=hailong.liu@oppo.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1717152733; a=rsa-sha256; cv=pass; b=t9MQ59B29SNBaeUj0iB1HTGHbLYRs3WzbMjzBBY/kghZFZqvfB9tUO8C0jOperA98sJhjH 6R1x3UvhoZ6weSKMwMba2sQv/ODCVMqG0fTs8qRW5y6OObV5dfL8X3OBbU2QjSll6G5UtL KK/nW1JRXIRSZ8gXqOvHVN16JnYBMqQ= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OsT/hEUc3NG9imI6Jp56zahZ6FVQSUrJSbtBeegItu4gv7sUZsX65zc3w8wvVBZO2FEotRtLp7AkVX49bm39lKKnyiatGIQchqtOmW6nTrlR+J5PZq0ZxFNTloV/hop6SHo5ugZ4B5Wq/GBKFjpI1pyCsSEbTupDyiruQ12IChsCfvwLB6u8R8Ez+3WReleeLNM8J/ZK6s4LeQy4O5cTUGM6/H5WBScft7wnnsse/o6AaYK6VizyjlwYfbxAR+gbv/x9cTBw5Esbw7gEeryOmb6HwGe1cO6QPfIusqE6VBC2OFHzwrc187JPRF84xMsm+qmGzwV0tZlLjs7029h6RA== 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=wpwGwvYsX9FS3Z1xMFLY4yjARrUbN+yHSAtMqGPH6+w=; b=QTWCuSIOHIdqrale6cHKiel9Jwmc3cgliq4RJMNbcl53T4DFZgAuqzE8eLR2JcUEKzkGRLCPBrkR9Iaxyn7O0iy2GhwXLYqLTYZN9UOy0rGj+YKrhnQNYv1YgmNI4AZUQ5sUfc9jZO5vgok6pEL+hAyQyFwzFzzqyYTE+0iO3SoXUFimEDAhsyzrPsZ29wkMd4FdiKcTUtPi5tReJ4gWXpj15cWqs8rXybpxz/gzcSHJNcOKDCw3ak48PabIAAElvP+SjcWvS7eQWom+MRm99sE1raC+PHF4Ip/y3T+w/XVAHl7qj4nJmxMIs1OCKY9r2kH8RLGydBGmx9U6d6v+cg== 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=wpwGwvYsX9FS3Z1xMFLY4yjARrUbN+yHSAtMqGPH6+w=; b=TS+7fAETJ/jaIChEb174vQIfxJJYhF+RzF59OuH3hC35YtJhT2uYt0xmLOqr6gqkLuiTkKAIyXNseerMrHeo5041cN/F7ttLulVlamwENlkzA9Kr4154b1GM/wRtTffZBkDTpegQPPSTtEz+krNLJJYLb5ck4RQu3dHwnl+OFNI= Received: from SG2PR02CA0057.apcprd02.prod.outlook.com (2603:1096:4:54::21) by TYSPR02MB7702.apcprd02.prod.outlook.com (2603:1096:405:33::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.24; Fri, 31 May 2024 10:52:08 +0000 Received: from SG2PEPF000B66CF.apcprd03.prod.outlook.com (2603:1096:4:54:cafe::2e) by SG2PR02CA0057.outlook.office365.com (2603:1096:4:54::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.23 via Frontend Transport; Fri, 31 May 2024 10:52:07 +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 SG2PEPF000B66CF.mail.protection.outlook.com (10.167.240.23) 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 10:52:07 +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, 31 May 2024 18:52:06 +0800 Date: Fri, 31 May 2024 18:52:01 +0800 From: hailong liu To: Zhaoyang Huang CC: Barry Song <21cnbao@gmail.com>, Uladzislau Rezki , zhaoyang.huang , Andrew Morton , Christoph Hellwig , Lorenzo Stoakes , Baoquan He , Thomas Gleixner , , , Subject: Re: [PATCHv3] mm: fix incorrect vbq reference in purge_fragmented_block Message-ID: <20240531105201.3afxxv3jzifuymmi@oppo.com> References: <20240531030520.1615833-1-zhaoyang.huang@unisoc.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: SG2PEPF000B66CF:EE_|TYSPR02MB7702:EE_ X-MS-Office365-Filtering-Correlation-Id: 405cb4b0-885e-4d09-34cc-08dc815fb763 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|36860700004|82310400017|376005|7416005|1800799015; X-Microsoft-Antispam-Message-Info: =?utf-8?B?c2Vic01WVlB1OG5ZRHF4ZWRJRGRwTXo1b0k0T0toM25PTG1FWDFnZkhmQmR2?= =?utf-8?B?YWhTNE5UQzdRblJTbUtQU2pDdkhFZ0hUQ0NHczByL0lsbHIxUEtOaHhPUlBv?= =?utf-8?B?QnRacUhVNHZDakpKeE1WeVVESVdkbGVJTmFtWW5Bb0R3SFJGZThISEdCUnc5?= =?utf-8?B?QVJKYUN6QldHZnZDaFhUeVRjZXd4Wjc3b3hyekJGT080MGorV2JIbXJyVzRk?= =?utf-8?B?V2U5R0Rwb2ZkNG4xYjkwSUdzRCtKeHFsMDR0aVZLOC9HKzNsYlNhS3ZMbytR?= =?utf-8?B?VFlrLzM2UHMzR1Q4TjhvRnMxemZod0FURmFGdGxWZk1kY2FpSnNNS3JaMG5t?= =?utf-8?B?VTEvTWgwY2thbTZpN3c4VElXVG94bzFaem9UbnE2NTRpMk9ublVBVVdjTTBQ?= =?utf-8?B?WDlsMFJaZThjTlFjZGd2OTV4bVd3dHZLb1YyeGRmZk9PdEhOUEJreWxWZDll?= =?utf-8?B?N0xkbjBib2ROMGlsVUpsUTlzbG1FSHJmOWNxUTNJVm40citYYVlmR3gvSm5M?= =?utf-8?B?S090cmRWcjlpTnNzL01DbWhzVmdScTk4anVZM2N2UldGd2pIR3duWHN1WmRK?= =?utf-8?B?aUhwZ1lVWUg4ZUhTNTNMNHFDV1AvZ1hGQkF4NkVPOFhHbTZ3OU1xQ3dYeTdU?= =?utf-8?B?cWVzdVUwaGRLLzZQeDdoMkUyR1ZBL1lIKzBEV2pPS0RWMnlSU3lxSmhKYlNl?= =?utf-8?B?UjlBWFdVenVQMjNCYkRDeFdQcWZhcnNSUWVJTFNOMFFmUnZ1REtJNjd0a1U1?= =?utf-8?B?MTJVSlFuSTNYMW4ybWV2cDYydFFzZG9FYzdxZE5TbnRrck9FUy9hSWRGWTNQ?= =?utf-8?B?cFUrWCtVZGdOamxzZHJlUGtrV1pHME5XQ0ZiZ1VYSmhrMGVTOU10eFpvUUhs?= =?utf-8?B?Q2R4SjJSQVlmWEhBTHBzSDgrQXJzZlQ0V280eS90MlZGU3NkTy9LcVRxV0No?= =?utf-8?B?dG5SNjV6ZW5MenJYV0ZFL01ra3ZrNlpyN2dLMWo3bHhoVEMwQlFYdUxaMDJt?= =?utf-8?B?b2QvMG5PRWQwdDJrNUNaYWR5V0NyaE04VFJKQlNqVlRxeXNWdEZlNEgzMWpa?= =?utf-8?B?NFBHdndvQTFKM0lzSVFUL1lWeEV3ek9xSjhsRGZ3OVQ5eThxK01vbXdGNHR4?= =?utf-8?B?Y1N0OW1kaFVJajlWaHQ4VTg4REI2V2cwWmN6WEhzNDdXSjB3YW5kR0luSDFZ?= =?utf-8?B?SFdvUTI4TTQ2bzRKcEJSZTVRVWcrZDNFODJ6Mm9XRyt2cXZ1WVJidE5rM0Rs?= =?utf-8?B?cjlZaFlMdklES2JIcEFTeG5kTFBoVzk5dUUyKzNtVWxHTUE0QnFaaTliK3lX?= =?utf-8?B?Njh6ZTNQV1k0aHVqWVNaWnQ5Z3JNUUE5UEkrbmhXbCs5MWpjNlQ5cU0wUjh5?= =?utf-8?B?c0FDYnV2R0hORGZVbnllWG0xME1rRjZtYmp5N3dML3hEWjlhNlZMRGthZnpL?= =?utf-8?B?ckNkdjFYbExUYWdabGpxb1Y4RHFjTGR1T0ZnRkdrdTdmcXFTZzhaUVpDZ3hJ?= =?utf-8?B?ZGpsOTFSU0hFMHBmR3ZSVlVyaDlWOGVoY3RIT2pIY3BKOEJPS3NsQmtvQXFB?= =?utf-8?B?UGpqQnBlZEdqNkdrVk43UDFtbTZhOXJqT29HRGxlRVIxQ3pGaTh2YkZEMlFH?= =?utf-8?B?NFhldUdEczJsTi9YcE05R055WmNjcURoNmFiSGJOWUNyeXJLYnBpamVXbHlJ?= =?utf-8?B?eW5DR2VXak1mejdhMEZZL21BMFBxMmVFUnVXcWxBTFVqaVJBRFdWZG5CczZZ?= =?utf-8?B?Y3NkbnJyek9VS2dTRWQwanJ6ZGtCc1FCUUozUXMvQjlhWEhEd1FlZWJNRUVK?= =?utf-8?B?dmFwbmFONnFQc040d2ZNU3pTMUZuMHNsT25rckVQZUJCMFRkVUNMcUV2MTU4?= =?utf-8?Q?oKMS1LNwGHZMT?= 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)(36860700004)(82310400017)(376005)(7416005)(1800799015);DIR:OUT;SFP:1101; X-OriginatorOrg: oppo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2024 10:52:07.7282 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 405cb4b0-885e-4d09-34cc-08dc815fb763 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: SG2PEPF000B66CF.apcprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYSPR02MB7702 X-Rspamd-Queue-Id: 176BDA0003 X-Stat-Signature: rih5uchkuc74ateho6snfdcdqq7mb8j1 X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1717152732-748382 X-HE-Meta: U2FsdGVkX1+O2W9nP7zNtDC7TSXsmb3hz5X7tR5BNnoGy1Fr0ykxORlXxHPfLSYkB9GPZWtRwDp7puAHfB+JXyg8Y2KKCTs91SH3xFWurR+fS82mUaUvjNF0HG6Dj8iwN79dmxyUEs9cw1n433GNdv/K214EkCPmdRHnWPnIiLM62Kjg/XvluVmZYBBM+kvQIf6rVVrrc62YPAD+miu0dmkcJFXd7pp3MCxSk8kYknle0qXGWmMVJQRjW6NRtOLdPQqoi1uTeI42pga75cE33nExwqW+3MnvxpO65tbx5qCrFyMUdxJjoxQlX5XgpZ5hSS/GhrFqx46jldP2SlLytTnJpEst/LtfJyWAUm8Uk4fHMjJbO0N4n6iW+/21iOgNbaZqvlF965y5Z0YOLDU1Pn444nC1oQx0Rx+FIgWAQUrlmYgl3eCCRRqxFuarp82DtqzrDi9C4E6lrUbnyVdYMCMhWbiEuy1XqRbqjw/4uA+CKqf+Y5PYJ5kuYI6HzgvGm9oGTFCeiFqJkCtEVigqMH05p48GFrUTCUJi155cEdPTSycv1OcqQ1WQaK8E8d6KHVZ5xAM21qXau8eULaMCIMyi2Q9Edtixf613B/iDNgZHlFjy7zLOe76/RLb8+dCl9AZPZ//LI97d3H492sDFWw/ETqDzCS5er2BTVVakjuiZgPu0QuTahPEPWy+F27Mk9Wzf5r3gLHu8n3L1p+8MDMpq2oA8A9DpkW6LmneCgobR8dYQhAIpaz3PNlzdRpnC8UGIEnd7M+LVUpksF0Z7kDIYJ7fYzg710SsW5Gvsk2vSrezFCeKe6JM/OsNLVC0kbbafsKZ7FAqEifMmNJiaJfOMvSXlsSDuzcCgSut65ldRvAdLe48EHUUSSBgNwxziwfsTaaUtwxy7hLtNIT3lVoYS/IqkYcURkfDsekFMiIIhheNE9uW/SX3yyCqNgujCLXrPpwlWqagmaoWrS9n BoiyPw6b tuHHnkO2oQQQjnsWg507pXMB+VotpkjOGBehvGexM/Vi6I3UZFOSUq5ivS8+WqXX/++Q2uA4BhbRkwVTJh+VWQat26dYxSMHHAbOoW7BvY6iicl0Hi240rR8mNZESM8URraxrSA2PfNCnNY6O3xsuMku8xNHZyj3Bxtua4553hhxRCiTwPZ2iOxiAoDnKjNdiC4zf/q5a8BrDenQeutYZTSHtlnXedW1+Q/h5Hm7BYEwXz1SMDpm61hwExrznfM+fAoZxuuifsD7Y5HaqTzA96zOjBAXxpajs3S3T6d+7+i3kcHzmn9SSdgdmgBVoexHLXIBfjNXvdtekFkONhliNS8dWAY4HnNihZZPjhAyDKj4yPp1gS/iOrjkYGxI5I/sKy0sIEY6PeXRZAJbjdkCTrO3r+OXvIJCMTt/Sp0dAIhI9N6VIY3fO9/7Bzfpka8S+0BHZKtnUV0tQJrsytWkLMOKHG8/SdVJQn8eL9j1e2xnjrFJ9uCx9ZZ62OHDW+9/atGKkanFh/+5jtkkJv/myKP4Thqsfi3X/3iwT 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, 31. May 18:17, Zhaoyang Huang wrote: > On Fri, May 31, 2024 at 5:56 PM Barry Song <21cnbao@gmail.com> wrote: > > > > On Fri, May 31, 2024 at 9:13 PM Zhaoyang Huang wrote: > > > > > > On Fri, May 31, 2024 at 4:05 PM Uladzislau Rezki wrote: > > > > > > > > On Fri, May 31, 2024 at 11:05:20AM +0800, zhaoyang.huang wrote: > > > > > From: Zhaoyang Huang > > > > > > > > > > vmalloc area runs out in our ARM64 system during an erofs test as > > > > > vm_map_ram failed[1]. By following the debug log, we find that > > > > > vm_map_ram()->vb_alloc() will allocate new vb->va which corresponding > > > > > to 4MB vmalloc area as list_for_each_entry_rcu returns immediately > > > > > when vbq->free->next points to vbq->free. That is to say, 65536 times > > > > > of page fault after the list's broken will run out of the whole > > > > > vmalloc area. This should be introduced by one vbq->free->next point to > > > > > vbq->free which makes list_for_each_entry_rcu can not iterate the list > > > > > and find the BUG. > > > > > > > > > > [1] > > > > > PID: 1 TASK: ffffff80802b4e00 CPU: 6 COMMAND: "init" > > > > > #0 [ffffffc08006afe0] __switch_to at ffffffc08111d5cc > > > > > #1 [ffffffc08006b040] __schedule at ffffffc08111dde0 > > > > > #2 [ffffffc08006b0a0] schedule at ffffffc08111e294 > > > > > #3 [ffffffc08006b0d0] schedule_preempt_disabled at ffffffc08111e3f0 > > > > > #4 [ffffffc08006b140] __mutex_lock at ffffffc08112068c > > > > > #5 [ffffffc08006b180] __mutex_lock_slowpath at ffffffc08111f8f8 > > > > > #6 [ffffffc08006b1a0] mutex_lock at ffffffc08111f834 > > > > > #7 [ffffffc08006b1d0] reclaim_and_purge_vmap_areas at ffffffc0803ebc3c > > > > > #8 [ffffffc08006b290] alloc_vmap_area at ffffffc0803e83fc > > > > > #9 [ffffffc08006b300] vm_map_ram at ffffffc0803e78c0 > > > > > > > > > > Fixes: fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilized blocks") > > > > > > > > > > Suggested-by: Hailong.Liu > > > > > Signed-off-by: Zhaoyang Huang > > > > > > > > > Is a problem related to run out of vmalloc space _only_ or it is a problem > > > > with broken list? From the commit message it is hard to follow the reason. > > > > > > > > Could you please post a full trace or panic? > > > Please refer to the below scenario for how vbq->free broken. > > > step 1: new_vmap_block is called in CPU0 and get vb->va->addr = > > > 0xffffffc000400000 > > > step 2: vb is added to CPU1's vbq->vmap_block(xarray) by xa = > > > addr_to_vb_xa(va->va_start); > > > fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully > > > utilized blocks") introduce a per_cpu like xarray mechanism to have vb > > > be added to the corresponding CPU's xarray but not local. > > > step 3: vb is added to CPU0's vbq->free by > > > list_add_tail_rcu(&vb->free_list, &vbq->free); > > > step 4 : purge_fragmented_blocks get vbq of CPU1 and then get above vb > > > step 5 : purge_fragmented_blocks delete vb from CPU0's list with > > > taking the vbq->lock of CPU1 > > > step 5': vb_alloc on CPU0 could race with step5 and break the CPU0's vbq->free > > > > > > As fc1e0d980037 solved the problem of staled TLB issue, we need to > > > introduce a new variable to record the CPU in vmap_block instead of > > > reverting to iterate the list(will leave wrong TLB entry) > > > > > > > > > --- > > > > > v2: introduce cpu in vmap_block to record the right CPU number > > > > > v3: use get_cpu/put_cpu to prevent schedule between core > > > > > --- > > > > > --- > > > > > mm/vmalloc.c | 12 ++++++++---- > > > > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > > > > index 22aa63f4ef63..ecdb75d10949 100644 > > > > > --- a/mm/vmalloc.c > > > > > +++ b/mm/vmalloc.c > > > > > @@ -2458,6 +2458,7 @@ struct vmap_block { > > > > > struct list_head free_list; > > > > > struct rcu_head rcu_head; > > > > > struct list_head purge; > > > > > + unsigned int cpu; > > > > > }; > > > > > > > > > > /* Queue of free and dirty vmap blocks, for allocation and flushing purposes */ > > > > > @@ -2586,10 +2587,12 @@ static void *new_vmap_block(unsigned int order, gfp_t gfp_mask) > > > > > return ERR_PTR(err); > > > > > } > > > > > > > > > > + vb->cpu = get_cpu(); > > > > > vbq = raw_cpu_ptr(&vmap_block_queue); > > > > > spin_lock(&vbq->lock); > > > > > list_add_tail_rcu(&vb->free_list, &vbq->free); > > > > > spin_unlock(&vbq->lock); > > > > > + put_cpu(); > > > > > > > > > Why do you need get_cpu() here? Can you go with raw_smp_processor_id() > > > > and then access the per-cpu "vmap_block_queue"? get_cpu() disables > > > > preemption and then a spin-lock is take within this critical section. > > > > From the first glance PREEMPT_RT is broken in this case. > > > get_cpu here is to prevent current task from being migrated to other > > > COREs before we get the per_cpu vmap_block_queue. Could you please > > > suggest a correct way of doing this? > > > > not quite sure if you have to pay the price of disabling preempt. > > Does the below Hailong suggested fix your problem? > > > > vb->cpu = raw_smp_processor_id(); > > vbq = per_cpu_ptr(&vmap_block_queue, vb->cpu); > emm, it looks like 2 could race with 2' which also leads to wrong > vbq->free status, right? > > taskA > 1. CPU0: > vb->cpu = raw_smp_processor_id(); > 2. CPU1: > vbq = per_cpu_ptr(&vmap_block_queue, vb->cpu(0)); > > taskB > 2'. CPU0: > static void *vb_alloc(unsigned long size, gfp_t gfp_mask) > { > rcu_read_lock(); > vbq = raw_cpu_ptr(&vmap_block_queue); > list_for_each_entry_rcu(vb, &vbq->free, free_list) { > > IIUC, for_each free_list is under RCU, so .. > > > > > > > > > > > I am on a vacation, responds can be with delays. > > > > > > > > -- > > > > Uladzislau Rezki > > > > Thanks > > Barry -- Best Regards, Hailong.