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 38D34C25B75 for ; Fri, 31 May 2024 10:44:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9006E6B0088; Fri, 31 May 2024 06:44:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B01C6B0089; Fri, 31 May 2024 06:44:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79E8C6B008A; Fri, 31 May 2024 06:44:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5CF896B0088 for ; Fri, 31 May 2024 06:44:47 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 12A20C17A6 for ; Fri, 31 May 2024 10:44:47 +0000 (UTC) X-FDA: 82178357814.17.4BC0B8E Received: from mail115-95.sinamail.sina.com.cn (mail115-95.sinamail.sina.com.cn [218.30.115.95]) by imf16.hostedemail.com (Postfix) with ESMTP id A2496180014 for ; Fri, 31 May 2024 10:44:43 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.95 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717152285; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=htrW2LGw8XNvBQSGUJ8M4yG3V3LJnckqLfagr+W5ZuY=; b=jYaqng7+wt9nGyE0MHI8pbFFcfV2UeATwZjeQcmCBwX7k/GyFog6Z1i/EKlDYA7Aj9Huvx 6AUEMzUYoE62+1kWFTcjc06F7L41JGUGbITefcfpEQrYKf3QmN+vvu82MXF4jbBYhWNARM +gAYYLQtkb0ityA5/6OXrhpjZfcbxoo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717152285; a=rsa-sha256; cv=none; b=vMmMZaTjzRu9cafJAMbQTqxO1XjFL8SmxaHR8/za/JS82+m+qQ2JDGzhc3qmoS8TT/dQJx uDHv78RflLoypZ2rqd+Sv0XNEk+K7o9Ad2Rak7qnQASxmboS1cqgAh+tGyw2b7+Rw3AAK3 KwXmuxwfWufm2BF+lYcNhLcextg1mRg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.95 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.118.65.235]) by sina.com (172.16.235.24) with ESMTP id 6659AA1200007FB7; Fri, 31 May 2024 18:44:37 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 4469045089358 X-SMAIL-UIID: 76A9980702114039A99F5F596098C318-20240531-184437-1 From: Hillf Danton To: Uladzislau Rezki Cc: "zhaoyang . huang" , hailong liu , Andrew Morton , Thomas Gleixner , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv3] mm: fix incorrect vbq reference in purge_fragmented_block Date: Fri, 31 May 2024 18:44:25 +0800 Message-Id: <20240531104425.3262-1-hdanton@sina.com> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A2496180014 X-Rspam-User: X-Stat-Signature: xph97ow9trz55j6ujoifya1mxsh98nrb X-HE-Tag: 1717152283-553896 X-HE-Meta: U2FsdGVkX1/onzGrb9s94l/lCrQemwBW/kca858kaTRhI2pY97PXeX/weaG4RHTkUJeeGkDEz3DtVv6l8pI7vVOwIuCJU/zbSQ3gv7zsqvUwVE9/Gs4NWsVPQc9binAGflffpsQlUxnFK+8sS4Q6sBx0UoZefctK49WtVdCS2XZlBXrvucdtlUUv9uy/tdpxnH4oR16qQlC7GfesLT/zaW5KBM1t69JNwJwU160cojHJ5+V0cus7KjdvXsOJc9aTQ2roXmCsd+5i4gNeyp15LOdWpa9nhEscNsc+MlCghuSm5znOc0U8lnJ9n9FFTF2+0J+drIiBPuQ/VIXytRc5Z9ep41pSMBM8ivPlBmI2FtBaANTTf+Qk41hoes76TDswkZgAZFG1B+bKsuYL7bF4rK477r7Xlm1ZAdfQ9qLVGUV8IMk48CcEdbd8CSx7agksmhGKF7djUBezYmnwfORMnM2w731SqEDrWhyAeJC2yQNZDGgsHYerRgMvbnN/UmgxtYnGxjVK+Qb2GxE0VZ/Okhc8UvKPfKxHH0/595dSR1RTOEdgpunJ6pbffQwU09UpTgemVo2EVz19J8BzQ+Hj4ajtttnUB9A+61y7aH2OyG89jqi2zvNMOrUuGxT3GDGyw7jfA2PYYAEDDIeWqm6Hq4/E7rzVbvst+TeKe9ZueUjNeLFJ0SPYCw98aX1A560IMUuuujOxHNP7syC/VhvDSJIkIjX6kLanN8LhfiGT4kQqEv1P9hmh7p/840aL9QLpPAt0tRD1iLgERMlU6DdqoGLep4ppEh736hV5i1VY2jyj2r7hAgUelz9jyq4FiIJJ1uMBCrIHpRMaR1kotkARzVGdgSaVMEBSNMe0ysisbqnXn/+BCZHNi4vSH+1IA2bvCGapwqShOI9pNKfveQ6thb4Mot0ideFxdymlpn4YmwMmZKbU+lU27eZkoA1z+DrjAZuqWhZgI5X9rm+KEK2 xFXBvzcf h0v5g8AB4ePzGXVkemyJ72qQ9nIn4LhWdw03xv4bxf7Hmelg7DkySsvnY/+PuFGQbN0H7VGYckfxU/k/zzGc5D2uN/2I4DNIuyK2j66ysNOCGi17sRbU6hHZomuLh8qySEI/KewKncnWdNOhPY2WsOxh6WsFbuDPA/3oSQ0Xdij4i9E+eUmC3leN6CYTIJQZ08fNt4fA1TV4gxZb4kZGPaw3XM/RRVbHmHcHGqKD6AsKWN/W5oVOvaCC+Ng== 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 10:04, 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? What they proposed looks correct IIUC --- l/mm/vmalloc.c +++ v/mm/vmalloc.c @@ -2067,7 +2067,7 @@ static void *new_vmap_block(unsigned int return ERR_PTR(err); } - vbq = raw_cpu_ptr(&vmap_block_queue); + vbq = container_of(xa, struct vmap_block_queue, vmap_blocks); spin_lock(&vbq->lock); list_add_tail_rcu(&vb->free_list, &vbq->free); spin_unlock(&vbq->lock);