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 896DBC25B7E for ; Sat, 1 Jun 2024 02:34:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 189816B0093; Fri, 31 May 2024 22:34:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1149B6B009A; Fri, 31 May 2024 22:34:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF4AE6B009E; Fri, 31 May 2024 22:34:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CB56B6B0093 for ; Fri, 31 May 2024 22:34:29 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 52FC4160C02 for ; Sat, 1 Jun 2024 02:34:29 +0000 (UTC) X-FDA: 82180751058.17.8FE5FA0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 9FF0B180008 for ; Sat, 1 Jun 2024 02:34:26 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=RCHadP66; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf24.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717209266; 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=NzTTL+MfzvlfKZfQtB4qseGdRfAHinOsvS8cm5FA5Qs=; b=udqmH+ZfpD4X5UaF02VicxaPwHuNqr9LMDr4KMGFPsAEiHUQdzGClQlyxb5VqpufAiDkNj /jaInctvDFg0Inr+i+tPi/LqAIKQvCZ2hwAuNCJhkuA0K9v8QJuLqyRWxiOPJ1pwqhGJMr jHWSV3IrWnn6Df+Rw8DYrytqhwU/EXE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717209266; a=rsa-sha256; cv=none; b=LqNqDhBZSNUhfQg2rh54S0A5sUAuVZmHf1402ZYh9jyxxrtcs7mp6kHGqznM6cCaInoVrY UVQUayBP6X5oceQUKRaKFHRkV9t/k+O5YphiKvcSLz11sGNFY1/M78GFYkwN9rkXtdWy14 /jJsvsrsrZQUKwQSCQDu/AIV5gRlDa8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=RCHadP66; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf24.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1717209265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NzTTL+MfzvlfKZfQtB4qseGdRfAHinOsvS8cm5FA5Qs=; b=RCHadP66gmPgwsbPtx3ADPJbtCiB94spUfaVDzCDBTfZar6wZmq7pfKTWn58Dlr1PB7Pgr 3gMFUBP3gyB2NnGDdqYhpiwhEsxUfhW7pqGxl7D4ZA+UDBGklFfMtKHEpZ2TArPZC8nPze deihy3It/X0YNEyGKYd9DX0AwFQJqoI= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-561-VCSY1c3tOcKlKUnpHLrdyw-1; Fri, 31 May 2024 22:34:22 -0400 X-MC-Unique: VCSY1c3tOcKlKUnpHLrdyw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A387B1C05129; Sat, 1 Jun 2024 02:34:21 +0000 (UTC) Received: from localhost (unknown [10.72.116.39]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8A5663C27; Sat, 1 Jun 2024 02:34:18 +0000 (UTC) Date: Sat, 1 Jun 2024 10:34:15 +0800 From: Baoquan He To: Uladzislau Rezki , "zhaoyang.huang" , hailong liu Cc: Andrew Morton , Christoph Hellwig , Lorenzo Stoakes , Thomas Gleixner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhaoyang Huang , steve.kang@unisoc.com Subject: Re: [PATCHv3] mm: fix incorrect vbq reference in purge_fragmented_block Message-ID: References: <20240531030520.1615833-1-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Stat-Signature: ae5j1gczqci9e44179fhrnx67rnbzqxb X-Rspamd-Queue-Id: 9FF0B180008 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1717209266-805171 X-HE-Meta: U2FsdGVkX19GHGiDjzus7qbRKHt+aNjYEuPjDaH2Rr9ghfgGUfkrInGWcAEApb/qAIC2V8q2yT4ssepz/n6WnT4VKuWIpT/r7lwhESxvIshcx6C+KDI8bYEzOi1z63V9fsii8BpmlpIlb6Ris3ehDBCE1qEXzxKBB9P1BhxjBpcLu7JZ2IRGdZh2FNmae/gqArkEKVc1WEU383Oer7fplUnVc9LFnWistS4zE/LyW25XEGwff2XiUPOmUrYOteQtZ48N0k3FaSq/3tg/LW3XmHqOrJyCmEBy0PezexTZVASBhWRZwgDqmFeek77vmX2jbEUo5a2p2kJQ1miAC8KChbEvWovz6oFC+/4WZQ+PEf0lDkxd7DvmXCnYt3b7J73S/jLisaPs0yIXECWM+OyD9vfEbKMjf/BrMeKgzJl1V8fGVSGqDitEmtlATeddXXFC7kqAKZfvhJ5DGM8sVkFzsvnd+rhMT2j9Plh/kVjCWfC7R34+u1FgCiUaFjf8tt6xD+MKwX5SU30yu+/CiGsVJKqljbZ6g1816mzMcqDlFybVW0BkauIVSYWVS2fz1hVtV6uQs8RKlEU3IiW0frPGolOar78eZ2voQhwBtwbguwGjqxkgnHL9DV+gvdZK9F5MaAsvW8cEU1R/Q50enS/k8i5YAGrJ4vrnw4nKU/O1lB7GVfWvgsywu3S9J9o/pe17v/qDWw7BKXGRyZJSOI89eo8BA6PxHLPtlPeImy9sSvVs6L6WZz+LBv8fkjy0uQgIKaSJGu9Rgt510eaVT0GjR7le6A8fxKjwlQyKj1eZaeXFGtP+5J741FJnhercbS3nhLM7HtLqSZOzoCgVl/2lCzdaT836boyn5srJVAT2oCf3Hln1DoyIfAFnOyfhXYuESiF5JmUOaDAgbYhHLp7SGoFnHdNxfqHJ0bKrWCHRfI+MbS1SxuXMbSz4l1lVhhhrmIKiQ/Dx7tNswHdSLhP +FKGDFdA fEllYnD/C3bmq5U21pKV7zOY1ZsLe5MtsmKlL81GQrdei9QyK9UpvIxa38tbzKF/CQxuHmvV+7TVLxOBO9PD0FtWO2GE+RrA8N0IU1IJavO5m7Nbb7lIllvp2+DwiYajYcuyOrHN9LZKjqlM9z4HqJNYKAm6HRhZvR/lls3CFlUV+LjW+NNgKoHMkqqXV1V+3fsfs35A1S410fJgEgl8OjOvttstJP93LDSHiAzlJt0JKPeY84XE/bSinIsNRRfZHKwXOhGnHv9AMgjG9Qm1jWWu39N4efpK6OuKUs0hVJJXL6qzP2h7yqGoPgWB3+osB7V1ptoM5fNYrwIlgUmCR/g5AQ+S+GTjyOBeUgXoEHzdeqNR2LtEQmWiQRFbZr8V5MAbhJhnhwTsVkxs= 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 05/31/24 at 10:04am, 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. This should fix the broken list. Hi Zhaoyang and Hailong, Could any of you test below patch in your testing environment? >From b56dcc7d98c4dbb7ea197516bd129c30c0e9d1ef Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Fri, 31 May 2024 23:44:57 +0800 Subject: [PATCH] mm/vmalloc.c: add vb into appropriate vbq->free Content-type: text/plain The current vbq is organized into per-cpu data structure, including a xa and list. However, its adding into vba->free list is not handled correctly. The new vmap_block allocation could be done in one cpu, while it's actually belong into anohter cpu's percpu vbq. Then the list_for_each_entry_rcu() on the vbq->free and its deletion could cause list breakage. This fix the wrong vb adding to make it be added into expected vba->free. Signed-off-by: Baoquan He --- mm/vmalloc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index b921baf0ef8a..47659b41259a 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2547,6 +2547,14 @@ addr_to_vb_xa(unsigned long addr) return &per_cpu(vmap_block_queue, index).vmap_blocks; } +static struct vmap_block_queue * +addr_to_vbq(unsigned long addr) +{ + int index = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); + + return &per_cpu(vmap_block_queue, index); +} + /* * We should probably have a fallback mechanism to allocate virtual memory * out of partially filled vmap blocks. However vmap block sizing should be @@ -2626,7 +2634,7 @@ static void *new_vmap_block(unsigned int order, gfp_t gfp_mask) return ERR_PTR(err); } - vbq = raw_cpu_ptr(&vmap_block_queue); + vbq = addr_to_vbq(va->va_start); spin_lock(&vbq->lock); list_add_tail_rcu(&vb->free_list, &vbq->free); spin_unlock(&vbq->lock); -- 2.41.0