From patchwork Fri Jun 14 02:13:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "zhaoyang.huang" X-Patchwork-Id: 13697719 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 3D856C27C6E for ; Fri, 14 Jun 2024 02:17:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1C1C6B008C; Thu, 13 Jun 2024 22:14:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA4DC6B0098; Thu, 13 Jun 2024 22:14:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1EBD6B0099; Thu, 13 Jun 2024 22:14:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8017E6B008C for ; Thu, 13 Jun 2024 22:14:43 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F389A140404 for ; Fri, 14 Jun 2024 02:14:42 +0000 (UTC) X-FDA: 82227875604.03.70C81AB Received: from SHSQR01.spreadtrum.com (mx1.unisoc.com [222.66.158.135]) by imf07.hostedemail.com (Postfix) with ESMTP id 085F940005 for ; Fri, 14 Jun 2024 02:14:39 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf07.hostedemail.com: domain of zhaoyang.huang@unisoc.com designates 222.66.158.135 as permitted sender) smtp.mailfrom=zhaoyang.huang@unisoc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718331280; 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: references; bh=S6xfLMdfr0522AFJXRGKuFo0rDh/8DxBAgLd7t7USVc=; b=4CUDe4Ycq8x5V4NZ5QJxldvOcpB22PELlpkfrF88mit2MYXyH6j7Pb05E/XB3u+HAqXWro VF5tcuxVDK89itotjYtf68MKsL4AQ4vgSv4f1z1OaixSTJjytIxwFZy+0fZwT2jzXVNm3b 6UXhaAR2Wn/+hxG2h50d64QyPK3qz1U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718331280; a=rsa-sha256; cv=none; b=gtyJTiRpb/BeGjrAyWkrbPvqEbHZlF74p1bPA9V4Hvo3Jy6lLyUswFAfwN2BufO0mzFSBU FN836BZWiJ04fStj+Y24AcOSwePaKQf9DHIhccg7q3xxFbmLdddkJO/vyrn91V837bBi3C OiVV6CMNp1h0ymzu+s2ly/3eaOM+ZyE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf07.hostedemail.com: domain of zhaoyang.huang@unisoc.com designates 222.66.158.135 as permitted sender) smtp.mailfrom=zhaoyang.huang@unisoc.com Received: from dlp.unisoc.com ([10.29.3.86]) by SHSQR01.spreadtrum.com with ESMTP id 45E2E5ZK058868; Fri, 14 Jun 2024 10:14:05 +0800 (+08) (envelope-from zhaoyang.huang@unisoc.com) Received: from SHDLP.spreadtrum.com (bjmbx01.spreadtrum.com [10.0.64.7]) by dlp.unisoc.com (SkyGuard) with ESMTPS id 4W0jQf632tz2QqFKS; Fri, 14 Jun 2024 10:09:46 +0800 (CST) Received: from bj03382pcu01.spreadtrum.com (10.0.73.40) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Fri, 14 Jun 2024 10:13:56 +0800 From: "zhaoyang.huang" To: Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Baoquan He , Thomas Gleixner , hailong liu , , , Zhaoyang Huang , CC: Subject: [update PATCHv5 1/1] mm: fix incorrect vbq reference in purge_fragmented_block Date: Fri, 14 Jun 2024 10:13:52 +0800 Message-ID: <20240614021352.1822225-1-zhaoyang.huang@unisoc.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Originating-IP: [10.0.73.40] X-ClientProxiedBy: SHCAS01.spreadtrum.com (10.0.1.201) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com 45E2E5ZK058868 X-Rspamd-Queue-Id: 085F940005 X-Stat-Signature: jkiezdfaei8et5gkic5ezcq11dnypss6 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1718331279-138510 X-HE-Meta: U2FsdGVkX187vPw+xGW05Go/jyKEHVfZIScpxJb1t5gmRXq3W468Fdq3ejZLnCA+P2GU0nr7RTTZSV9n6ICjr1sdtGlAZgHhupmfXIqlo5UBu5X+q8SO/4b55Dld5jcZFTs/C++EDl8FQF6czupTKzNgnEMkywtofQMsO06nzSLmbC0NVBPX72+xcj1su5V3TQ66vcRZbB1kVgOC0EwSo81/8zRPgjGd+HMm/0mrF1RF1JDba6sc+IAcfj9HygB67jxl/GSac6UUQLvYu5IRA8z9ZyJggtj5aijNrOJVJKr8PniiXFuUMZzOyMNSFjcSNFYiGzSVsXMHnG+2rRdSCmWTicUkcANqYNc/kvkfsoMJq2U2XQ8S7zio9LKXeKZWGLJiWO97lTx4gvsLQzaqkRssJaOnELcbcB4Yx9IV9CQotk7aFBvbbmdduJKsqQH5XICMAukHDvHicCk4r6DTxmSasJZw0n/QjELnoQBWhQTui+LdXYl0+SurTcPR19VE/8kplQNBZagbroS9JZNoNhrePf+ucEdY9SJlaN5NOITsavgbnO5uMltQ7bZxmMa84l/7s6b6BY4+M8vfY4UeblkEsvXDvuqpm0/D5Lxt9XzFYKY873FaQX3bcshjYFO37Obya/kMP22B1pBXYIRCRGCrWl11LCwyig5L5cXWpK2u8Leo+DZnB/EqWT212MojpEiRGVthcOI1fv26DQmJaQehad/Eia3ZDXa/p0wVpaSCh3in8mNhTgx379RRSU/ceyLH6oXgQECOQQX4RhzcU73ieAURg9bghYRRQ6aYb9GCqGq6x0TpwelVqNhxr6+SgchIFuh6Bx6rVVPhtun0q2bs3a9gfOvWy2SNfs4Vv9lBStHQpQHgkwSswMksJI3nsrw0BewFbKn/+c1vEv4BWInBKD0OGFoIj2RoGr2F5YLkarygyCHHLHze+q3AizEAhNA6NGFl8hfW/laftys 9JS8XPcy pas0Vuz2Rb9E2HBJqeIBTJpS10vCnvMLDnQJOXW9k7ZMdh2Fx5rJ8D5t5to+0niLhOWppvtKlNx60btXAiYuti69zqWlnFoZPl8ylChxJSowfgSijxbmY3tg7WuS29f7akO+IVnslG6MVPbXeouTvrREVuvDxa14qEwK4cdUBkIo+zlQEv849PuKQ67eJwTsdvHB8bNFGiyuig+/eohIgsYfzJfyNq17Zj++OuecZjweZjLpKU2cn+njyJSTHF6ezR9E2ceRNbx4sPezDzDffEGOC1eDUdwY2eRIsYZFYNfA+O1Lpqo2gkst4/d3Pe/GPLGeMeFqjiz605D9T0mDzIYazFae+QRXcprdH 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: From: Zhaoyang Huang The function xa_for_each() in _vm_unmap_aliases() loops through all vbs. However, since commit 062eacf57ad9 ("mm: vmalloc: remove a global vmap_blocks xarray") the vb from xarray may not be on the corresponding CPU vmap_block_queue. Consequently, purge_fragmented_block() might use the wrong vbq->lock to protect the free list, leading to vbq->free breakage. Incorrect lock protection can exhaust all vmalloc space as follows: CPU0 CPU1 +--------------------------------------------+ | +--------------------+ +-----+ | +--> | |---->| |------+ | CPU1:vbq free_list | | vb1 | +--- | |<----| |<-----+ | +--------------------+ +-----+ | +--------------------------------------------+ _vm_unmap_aliases() vb_alloc() new_vmap_block() xa_for_each(&vbq->vmap_blocks, idx, vb) --> vb in CPU1:vbq->freelist purge_fragmented_block(vb) spin_lock(&vbq->lock) spin_lock(&vbq->lock) --> use CPU0:vbq->lock --> use CPU1:vbq->lock list_del_rcu(&vb->free_list) list_add_tail_rcu(&vb->free_list, &vbq->free) __list_del(vb->prev, vb->next) next->prev = prev +--------------------+ | | | CPU1:vbq free_list | +---| |<--+ | +--------------------+ | +----------------------------+ __list_add(new, head->prev, head) +--------------------------------------------+ | +--------------------+ +-----+ | +--> | |---->| |------+ | CPU1:vbq free_list | | vb2 | +--- | |<----| |<-----+ | +--------------------+ +-----+ | +--------------------------------------------+ prev->next = next +--------------------------------------------+ |----------------------------+ | | +--------------------+ | +-----+ | +--> | |--+ | |------+ | CPU1:vbq free_list | | vb2 | +--- | |<----| |<-----+ | +--------------------+ +-----+ | +--------------------------------------------+ Here’s a list breakdown. All vbs, which were to be added to ‘prev’, cannot be used by list_for_each_entry_rcu(vb, &vbq->free, free_list) in vb_alloc(). Thus, vmalloc space is exhausted. This issue affects both erofs and f2fs, the stacktrace is as follows: erofs: [] __switch_to+0x174 [] __schedule+0x624 [] schedule+0x7c [] schedule_preempt_disabled+0x24 [] __mutex_lock+0x374 [] __mutex_lock_slowpath+0x14 [] mutex_lock+0x24 [] reclaim_and_purge_vmap_areas+0x44 [] alloc_vmap_area+0x2e0 [] vm_map_ram+0x1b0 [] z_erofs_lz4_decompress+0x278 [] z_erofs_decompress_queue+0x650 [] z_erofs_runqueue+0x7f4 [] z_erofs_read_folio+0x104 [] filemap_read_folio+0x6c [] filemap_fault+0x300 [] __do_fault+0xc8 [] handle_mm_fault+0xb38 [] do_page_fault+0x288 [] do_translation_fault[jt]+0x40 [] do_mem_abort+0x58 [] el0_ia+0x70 [] el0t_64_sync_handler[jt]+0xb0 [] ret_to_user[jt]+0x0 f2fs: [] __switch_to+0x174 [] __schedule+0x624 [] schedule+0x7c [] schedule_preempt_disabled+0x24 [] __mutex_lock+0x374 [] __mutex_lock_slowpath+0x14 [] mutex_lock+0x24 [] reclaim_and_purge_vmap_areas+0x44 [] alloc_vmap_area+0x2e0 [] vm_map_ram+0x1b0 [] f2fs_prepare_decomp_mem+0x144 [] f2fs_alloc_dic+0x264 [] f2fs_read_multi_pages+0x428 [] f2fs_mpage_readpages+0x314 [] f2fs_readahead+0x50 [] read_pages+0x80 [] page_cache_ra_unbounded+0x1a0 [] page_cache_ra_order+0x274 [] do_sync_mmap_readahead+0x11c [] filemap_fault+0x1a0 [] f2fs_filemap_fault+0x28 [] __do_fault+0xc8 [] handle_mm_fault+0xb38 [] do_page_fault+0x288 [] do_translation_fault[jt]+0x40 [] do_mem_abort+0x58 [] el0_ia+0x70 [] el0t_64_sync_handler[jt]+0xb0 [] ret_to_user[jt]+0x0 To fix this, introducing cpu within vmap_block to record which this vb belongs to. Fixes: fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilized blocks") Cc: stable@vger.kernel.org Suggested-by: Hailong.Liu Signed-off-by: Zhaoyang Huang --- v2: introduce cpu in vmap_block to record the right CPU number v3: use get_cpu/put_cpu to prevent schedule between core v4: replace get_cpu/put_cpu by another API to avoid disabling preemption v5: update the commit message by Hailong.Liu --- --- mm/vmalloc.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 22aa63f4ef63..89eb034f4ac6 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 */ @@ -2585,8 +2586,15 @@ static void *new_vmap_block(unsigned int order, gfp_t gfp_mask) free_vmap_area(va); return ERR_PTR(err); } - - vbq = raw_cpu_ptr(&vmap_block_queue); + /* + * list_add_tail_rcu could happened in another core + * rather than vb->cpu due to task migration, which + * is safe as list_add_tail_rcu will ensure the list's + * integrity together with list_for_each_rcu from read + * side. + */ + vb->cpu = raw_smp_processor_id(); + vbq = per_cpu_ptr(&vmap_block_queue, vb->cpu); spin_lock(&vbq->lock); list_add_tail_rcu(&vb->free_list, &vbq->free); spin_unlock(&vbq->lock); @@ -2614,9 +2622,10 @@ static void free_vmap_block(struct vmap_block *vb) } static bool purge_fragmented_block(struct vmap_block *vb, - struct vmap_block_queue *vbq, struct list_head *purge_list, - bool force_purge) + struct list_head *purge_list, bool force_purge) { + struct vmap_block_queue *vbq = &per_cpu(vmap_block_queue, vb->cpu); + if (vb->free + vb->dirty != VMAP_BBMAP_BITS || vb->dirty == VMAP_BBMAP_BITS) return false; @@ -2664,7 +2673,7 @@ static void purge_fragmented_blocks(int cpu) continue; spin_lock(&vb->lock); - purge_fragmented_block(vb, vbq, &purge, true); + purge_fragmented_block(vb, &purge, true); spin_unlock(&vb->lock); } rcu_read_unlock(); @@ -2801,7 +2810,7 @@ static void _vm_unmap_aliases(unsigned long start, unsigned long end, int flush) * not purgeable, check whether there is dirty * space to be flushed. */ - if (!purge_fragmented_block(vb, vbq, &purge_list, false) && + if (!purge_fragmented_block(vb, &purge_list, false) && vb->dirty_max && vb->dirty != VMAP_BBMAP_BITS) { unsigned long va_start = vb->va->va_start; unsigned long s, e;