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 ED9EAC25B74 for ; Sun, 2 Jun 2024 11:02:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 210566B0095; Sun, 2 Jun 2024 07:02:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BD626B0098; Sun, 2 Jun 2024 07:02:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 085556B009A; Sun, 2 Jun 2024 07:02:45 -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 DA4336B0095 for ; Sun, 2 Jun 2024 07:02:44 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 53760A02E3 for ; Sun, 2 Jun 2024 11:02:44 +0000 (UTC) X-FDA: 82185660648.29.8F8FF46 Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf13.hostedemail.com (Postfix) with ESMTP id 733742001C for ; Sun, 2 Jun 2024 11:02:42 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cLX+TLcD; spf=pass (imf13.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.177 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717326162; 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=OvyOhWiM2rQIHomj4DY7TiG5cgjCTqPWZhY6q6i+OGM=; b=F518HXeioZkVmSzQimgCGMhf0jbErV5ZryIy9n1z3vgdDiSz066zJpI5kcHaYNI6gq527W 0jSq5pfnIDALjeM71YfHWC+PJw9IpaJ2HJmTnbFs6GtVshg/rLAWohXatvfZILf1GbisGr v9SV6DoqfNnPeUKVImCUoZdkyIfn+Ww= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cLX+TLcD; spf=pass (imf13.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.177 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717326162; a=rsa-sha256; cv=none; b=DvroYGsg1I0vdtFBfdwYsQvThi88PKoEEehWl8jMgZv3WkOidLS040uo2AWpTS3lsZUJpZ qa8KsalRCmmggFvd/WwlgrUftyRBBFYGs7y/1EyzkSMYHLP/F16PRwJ8BVUJ1HLIHNbm55 Ny1kVyYJ0FcWlGEsiDWNgli9RciZBfY= Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2eaa80cb4d3so8138791fa.1 for ; Sun, 02 Jun 2024 04:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717326160; x=1717930960; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OvyOhWiM2rQIHomj4DY7TiG5cgjCTqPWZhY6q6i+OGM=; b=cLX+TLcDhYbon1LLfrH73JNrENAoaDnpVPnkauz1TQjtCXgU5kSPAKbogxIDrwVZsW BhtLLiS1us7ijVwPox3RYhpb02MPnwvsF4cDwndiAqqZabSiaZFvyhOPClDuhH8xQWsf fFy7PV3JZCPnGMcVMiJk0BW84WxGSPYTJA5YU1aDlPbJeM1nbOa8onKEtWGtBhUAyi0Y flv/dtmlV87zACYJfSu7HuKqKor3HTbePEWDjl/RBImnmJTDSS4t4DVTJFQAL4qrFde0 u0gI0HOapHg63ZDW7JM5GiMYHWtCCDL0r7JgoFP6BFvXnuPRpYDr4W+6K66BKBibTmbH vr6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717326160; x=1717930960; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OvyOhWiM2rQIHomj4DY7TiG5cgjCTqPWZhY6q6i+OGM=; b=tJwyVahB1BZl0Qod1xxzPoEuoWbNj00zm4JTjx4ICFUTM5ngPoXcOMV1qktSPEBzrJ GxFBTe8iIOwLL5TiFI/VG9/38VQiX92L7WGIBh325F4hx6D44D5ueOZdSptq1yHgAbpG TiSbopSp6kGSIrPLCM1MNVaYQMN7z5xwAZVg5DpwDwWsKsBgg/vFqpRFaX44thUkKnq9 RTpA3zvL0y3EGOIjhjj6OPqlotejYjuhbTwXTpMrRhDX6R/oOjHR/IwRnfBTMTzoWavn zJ1nDks4Pyw0ALEmiggCjGeHez46X6ZK5dTpLANlu+1nvXMYrMxuWl0LMOGkhBKB8vmb eq+g== X-Forwarded-Encrypted: i=1; AJvYcCUjOjd8RfAL+JMfov9h415iN5LRzQKVhmweWrCoAI5vAgZYlH2v98VyS90OlJU+HgNFB0AMzVibrFJccQdkWu9m780= X-Gm-Message-State: AOJu0YwvUvpyqCUPWe+As7b04j8AXL35vwS8l6zlj7P97AOY0E+4nY02 zuKeSKLACk3O7Re9qWk1KGambJHjWGnMr2MEhSR4usWh11Ag+/VFUY72ClJQfrnmV8wrilZM/9/ 3ukRWYQa7cPWPWAJ9yNkoC0/rPvY= X-Google-Smtp-Source: AGHT+IG6h0NcNH5Bcu9B8dU0JMMQsTv7A0rDcHHCnyDQqR7bpE7UOVdW0pJP2DJASH2WC5TyzC3zulLosvryES0NRUA= X-Received: by 2002:a2e:9ec6:0:b0:2e6:935f:b6d3 with SMTP id 38308e7fff4ca-2ea9510e721mr54272811fa.14.1717326160067; Sun, 02 Jun 2024 04:02:40 -0700 (PDT) MIME-Version: 1.0 References: <20240531030520.1615833-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Sun, 2 Jun 2024 19:02:28 +0800 Message-ID: Subject: Re: [PATCHv3] mm: fix incorrect vbq reference in purge_fragmented_block To: Baoquan He Cc: Uladzislau Rezki , "zhaoyang.huang" , hailong liu , Andrew Morton , Christoph Hellwig , Lorenzo Stoakes , Thomas Gleixner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, steve.kang@unisoc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 733742001C X-Stat-Signature: dxmbtni19tuhrb7n1wxopq6iorw3i4ic X-HE-Tag: 1717326162-221032 X-HE-Meta: U2FsdGVkX19oRJBxOi9Q8v2Z1x1cJmRHV53gXAkTlOSNi7jDnpADAgU8L0g2vhtiHzO6yw7LUZUXkQ9lLmpShbclwL59771KxI+3tJ//UD8lUhoNkq6BCxvF30DpEXFlr4zfHfp4DtzYh4UDoi8QXUbmfshSGV7wFYZc9njZV4zgyWfV6/+XgYDWxhxBWzk/6fMFeLPqxXSmHbsqIhNKpjpfrRFY1EOLArZjTUC/LcEe/VCEZtzG/ARBNenyMfEh78Y043pqjaU+ME91nBOg0AxQVdbf1B8H8p3dlDH0bKQUvaZXjTMuJyFcRcYAXySGWMcFck+MIDus5roop75LxugbaZ+A1+KDvjenChgadbXoY/Ny1frjUoWNUr76VX/FvyWVY//y702XELAwTXT2wbrPKO9wgwvgXv2HFuRGea4QCWYAoi/r+0ylW5GSIRvvnM5nL0yxmijBGu7Y2XfcyQwuw4GD/vyjM4Ypu5G7/2viV1MeTwV79l8fiHpB2gonYhLeESbbaktIX79kI7Q4Shtdh9cdwR6JzDzdC8ZWslVuQC5VDtO2igolvrPkunsMnFoOwmV3rVPo9OMvyjiyETO/qEGBSioJ+WDhSTX38IMYh0mH3Jv+46zPv00v83roi0igWuQ1IeqTTY79EYPfnWkdtkNbsN7MfETkb+bLdjbz1QXZ1xRKmASw8Nj9HNmGnG/fxUZOuiikQHBv52KCWWtE/iIguM303NaU5wa4mqUEeGqzY/VVjbnOhfb81im/lPfQ+72CvBJsC9tC8sRyR1jgOivEWdhHf+Xled+0iuAbYuCE4EoT2bfmmsM60sYUWSh6KshPuPqpjWwFCURIsLButkLBbiRt4KE192DfLfb6ayqbywXXE5c3+dQwHO7cPDsAmyUA4SbHaM1YFs3Ub+HBy1g+I97eXz8qDuUgyNJe/vB04D+FBxcMkn9nj2IwqVvK8qnLyPgMvm1FZ0L aBDMJnrU lVhUDO2RMhLDz5Ty2CQ/5K6zTvhDKAnbGIJafs4ftcwwrCUkDIzOjCllzk5yP/9yWReGZHyXGUPb9Cs0Q1pDQVZuoWJV7uBns+emBN+SBbizGf+F/NCVbOhfbBjXIoFJb/lcnSRzaP323MGPeO4lZmwvj6T4WpWSXW9jyF62KYLxVlQlTY2YbFD0+MRbJ8Qak4k3UBoBvqWXBDxsRjBw5+FRVnOxo6T8N9uJ2hefyr4UyPEJR3kI89qCY+yaDAeGpJDXDKBP1m8ka9eAPUTsEoh009BWGrgwOnSEPL1MVYWWxczsaMg0emBURlGOF5HrHc6eP3M3y5ER+xKHHwvpFo0PyPLnuXNSnSQ+to+rT9asRY7zt4SnyYY5HXhGtG41dQabfIioL0n4injcT2iGkyKNCjVurjZRO9km2X6C84kkK4iS86se9FLFCDfUYwENaZxTHh+O00kTe4vsu4+/Y6uMLFXBmzfAvEqd4/naWYT7P7o/9zmoBJGXkZtlc1fFgu8PLkiyqGHTOVXw2+qAb5wtcgxga6oZN7XlR 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 Sat, Jun 1, 2024 at 10:34=E2=80=AFAM Baoquan He wrote: > > 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 lis= t > > > 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 ffffffc0803ebc= 3c > > > #8 [ffffffc08006b290] alloc_vmap_area at ffffffc0803e83fc > > > #9 [ffffffc08006b300] vm_map_ram at ffffffc0803e78c0 > > > > > > Fixes: fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilize= d 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 prob= lem > > with broken list? From the commit message it is hard to follow the reas= on. > > 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 =3D (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); > + > + return &per_cpu(vmap_block_queue, index); > +} emm, I am wondering if it make sense to add addr to vbp[CPU1] from CPU0 etc which is against per_cpu variable's goal? > + > /* > * We should probably have a fallback mechanism to allocate virtual memo= ry > * 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 =3D raw_cpu_ptr(&vmap_block_queue); > + vbq =3D 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 >