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 A3A06C25B74 for ; Fri, 31 May 2024 01:40:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 18D096B0098; Thu, 30 May 2024 21:40:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 13E4E6B0099; Thu, 30 May 2024 21:40:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F1F9F6B009B; Thu, 30 May 2024 21:40:17 -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 D3B6D6B0098 for ; Thu, 30 May 2024 21:40:17 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2BE61409E8 for ; Fri, 31 May 2024 01:40:17 +0000 (UTC) X-FDA: 82176985674.30.E47A7F2 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf14.hostedemail.com (Postfix) with ESMTP id 3D073100010 for ; Fri, 31 May 2024 01:40:14 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=C7KGtDFY; spf=pass (imf14.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.172 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=1717119615; a=rsa-sha256; cv=none; b=BpNTD/r197p9aAm797ZEQ/ofAsiUQljT/DiBXfPWbh0ZHgpWxb0UgMM9Xvvuz9oQBrFMBL 1CyCR+UCFe2XdH4X9aWD7cpTDIJmgx//SDjKaExgFVeTBRJE5a8LW33T4S6q7GW9A6BaHH 4KJdz5HO+y6UPyJwHl864LDQvlzb14Q= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=C7KGtDFY; spf=pass (imf14.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.172 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=1717119615; 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=2t5EcuhFKFYbv2Rd9t0NV0fJiuW2dSu7qfxhtP3jFNE=; b=UEPuKOshX9Ddpl3aou+a54khOTv6YkwmRialn6EVsrFcz5d/nvAxG1zU1LL246Dja2s6fw qs9HynF623t4uIPHKJlMSaS4RAQpXzysw6+NZVUW/gRnJrv53m0ZKy/kd5YIOLoDJ5A+gU KViC7UYZZZpf4a03FK7zdqCo06S7Lcc= Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2ea24dfd508so15664681fa.1 for ; Thu, 30 May 2024 18:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717119613; x=1717724413; 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=2t5EcuhFKFYbv2Rd9t0NV0fJiuW2dSu7qfxhtP3jFNE=; b=C7KGtDFYIgYaqnzxbR4zRuGsAWwzLRK2HbNz4whLju+SINVLgl1DQfoS/pvsuFnPrM lX2953nKv0Mes4ewM+d1usk+obdrk3MZ760cN2G7Vjw0y94F+ARl21So2Z6o1kEgsCuI z9CuBNsuGsmVjBW33G6NGcyCVyspdi/sCvOgsQ7GJDvSXWFUPpi5vS2uBZpuddLHcVZe ozeppPv5heZJ3I4WQVPaCGjQ9BmVR8j9S5BTgOo7Y58odJXQ0zzbHKJUnwMVUPk82MVH ni4482KPuJ51yanHA0AXEZEdf+OvdQ9PEL1eDJYeYHDjh/b6tgmYo9ef1l0d5AS8bHMg hdMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717119613; x=1717724413; 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=2t5EcuhFKFYbv2Rd9t0NV0fJiuW2dSu7qfxhtP3jFNE=; b=Ox8TX/V+BagOODMGBg1iq65It3IVfpdep/pGPSwwEg5B+RQdo5zqXheSj247e/0FaB hqpBkmgqafK/qkFHEsvEXsqG07/QWxc2X+6P4lbZBsyZQcVac+xpeHjJKkiK08uUHQWs LHu5UoFAoFtGT0BQoBuNZNYU7M8/7CLTe4zQJ2uYHHCwtv6oweKPw/pdhoUVNHSpORCu EMs2k5wkkMSFQwmEZizU9O+cS0IP9GhhQM9tOTdVRCdNN1WeBldCMV5vGsZ7X551tiM1 Odk4pfm+XKuZOvZKkk4OsD0l1bwGHkZ89/iQ+R7gYKqCIw2p6X4qBo5mFRCZHM6Z9+ES Qa2Q== X-Forwarded-Encrypted: i=1; AJvYcCWTSu+bPY62EQKBXhC9CuKMpOFQw52zdouuE2nxnZm+C4rrQwOpejITi/Ox+XODGxNWwGpOhKV6SnV+lXkGJl0Ns+g= X-Gm-Message-State: AOJu0Yy4cJAOb+rPzIWl5cRt1F9PN4z4mw/zpU0nMUHX37jeZHuryAfG 3xn7wJQoLX1IrnXxiM6sHNnRH9Xv9PygJ47aF/dJpJ1C5+K1pW8g+wpKcToyrkquravePh8iW8V WR3BxsBoMjZqCinYEAJ7Og4ig0DY= X-Google-Smtp-Source: AGHT+IFYFaEZ3Edx2O6D+oSsu6WVUMhuF7NpJWdVA2LsYC1KQJArdEwMeENxSf+oreH0QS6Xx4QwchMHH4tdb5pxcLQ= X-Received: by 2002:a05:651c:2112:b0:2e4:d378:7839 with SMTP id 38308e7fff4ca-2ea950a6bedmr1765251fa.4.1717119613165; Thu, 30 May 2024 18:40:13 -0700 (PDT) MIME-Version: 1.0 References: <20240531005007.1600287-1-zhaoyang.huang@unisoc.com> <20240531012718.ogitylhpsrrvvczo@oppo.com> In-Reply-To: <20240531012718.ogitylhpsrrvvczo@oppo.com> From: Zhaoyang Huang Date: Fri, 31 May 2024 09:40:01 +0800 Message-ID: Subject: Re: [PATCHv2] mm: fix incorrect vbq reference in purge_fragmented_block To: hailong liu Cc: "zhaoyang.huang" , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Baoquan He , 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: rspam06 X-Rspamd-Queue-Id: 3D073100010 X-Stat-Signature: a6burfefowd1spjw7b11p3e69b1r8zda X-HE-Tag: 1717119614-814173 X-HE-Meta: U2FsdGVkX1/eVDIwDkGAWWXjZ394OCbFLVRxTTTQRv84/SoSEy9I/hRddoqPC3e61e29HfdLVqGQmUMwvR+Jmb+95gKXqRxMWksuut2hJqI1jqYrTslrRlKKFTGvp6w1wRdVIS8Sc5/jvF626dIQIWsw/AxFCBBjJsRoZVVtlDLDxIinES3Z6Ft18f0ABykPfhkky51niwGS5ZT/7e8O884hrKuLBP+61HWN4dnsETX1AfId0LtA5FpdPe9HEBzecCUJBMRSFa2CkYiN3zkHbU38fyi993g4WFtzv/FI+JGIiereJ36dOqFEHpbALVmKyFQGyvHSlikhGBtNlRDHcIh5ENhDZgnByGvfrxLySOFf9VmttdPlZqhf9fWrizMf4Q92CsWX4XPwdr9bo4X8t0EUK/zvvgn/4TwFEzXp0Z6ncTEyVjuqk0870osuUeJ3NSOeqHUZXanTFrOtNP9s8wJZ8YhuYEZLESDt8yabekPIU4382oPtcx1eu3tmvrNBXwsc9yVQIsKgkCbm7cuH/qoBG5TmnWZ6DT2hshDDNSQRflGF6plsh1+6FZlwHm8NNqHva42jFBhizbPdqQgRZPNfk9CjlnsB7dIQo9ONRgIdYlpRsOa3WU70A+dR+hY4eERmio9b84O/S78z0AMDG9SOUGfKpS/GOJ8LD2XH3KbfsSpqibQY+EDJ+4IJrXkLwSSOPNwhsluaXS2J2o9p9riA75HkHqq1F2aOrg6hWYzVxhc2FHv48aKyXwEzGFKmZE9SBtWXYUz7IyXCINeH7gnKrBpyoxohCczoBYeL8N44OyDNsOl5eKiYEoZ7Tyy4drbFvwq1vAJfp20v0UO0zN6ofd+P2uZl6uJEdXeNcFE3ZtCIoYeO22L6i2DHlJBjhfMhaPF5Ow651G8PTPZkV4Vzd0eb9SxwU8ZyUip9JHKxBq9cv6qkczFWGHHE8lxMyyYPtiu/WTmsxpNZxGm hpRUPeIR 2mg+CMAX0CMlGoCtoQJMfBfOUtkZ1Cl0k4MVe77iMazzzA+3JZK9vryFraOapKkS3pROkJYyvO9UuZY6bfrCJHchM7r5LIcbPAWDI8IwCSWu9zpgz4oOQ7eIgU/T30AUX4zoBDmoysjYAYBCeOlJAAzEuCyxgvfymf6kHqXW6mhxwnQC4QT0MGZz4dXgW1ACEcWAuF+6z0x9ULQABrH44g2yJMBPAg7G2GjDjn2skMZ+96BfIFRQvVXOR2dKIfvLU8qw3MLOH8F34sG8qZ2sHYcOZe0V7dn5SHZ7weQ5ydN/jCfPByNMHaPLZiUnEr2ju669IVpVNK4lTBOrG6Qy2eA/mHYnzutVQCrepV716kzo6+mq1U8jXVwJlZ69ncSU4DjVvxM/s+e5krX8xsAXdlCEa0QGXA5P92jwfoO8Qk5jVxNpJ3kmTc7xKbW++Pa1aswQ6MmtgFdY6SwRRwMs0/yiPThKrUQyusGnhccpMRj6d0QjEXYzux0qbm3At2yiFfbZIvaYbUUdoIrw= 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, May 31, 2024 at 9:27=E2=80=AFAM hailong liu = wrote: > > On Fri, 31. May 08:50, 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") > > > > Signed-off-by: Zhaoyang Huang > > --- > > v2: introduce cpu in vmap_block to record the right CPU number > > --- > > --- > > mm/vmalloc.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 22aa63f4ef63..ca962b554fa0 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 pu= rposes */ > > @@ -2574,6 +2575,7 @@ static void *new_vmap_block(unsigned int order, g= fp_t gfp_mask) > > vb->dirty =3D 0; > > vb->dirty_min =3D VMAP_BBMAP_BITS; > > vb->dirty_max =3D 0; > if task migration to other CPU at this time, this may lead to get incorre= ct vbq. ok, thanks for the prompt. If this works? vb->cpu =3Dget_cpu(); ... put_cpu(); return vaddr; > > + vb->cpu =3D smp_processor_id(); > > bitmap_set(vb->used_map, 0, (1UL << order)); > > INIT_LIST_HEAD(&vb->free_list); > > > > @@ -2614,9 +2616,10 @@ static void free_vmap_block(struct vmap_block *v= b) > > } > > > > static bool purge_fragmented_block(struct vmap_block *vb, > > - struct vmap_block_queue *vbq, struct list_head *purge_lis= t, > > - bool force_purge) > > + struct list_head *purge_list, bool force_purge) > > { > > + struct vmap_block_queue *vbq =3D &per_cpu(vmap_block_queue, vb->c= pu); > > + > > if (vb->free + vb->dirty !=3D VMAP_BBMAP_BITS || > > vb->dirty =3D=3D VMAP_BBMAP_BITS) > > return false; > > @@ -2664,7 +2667,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 +2804,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, fals= e) && > > vb->dirty_max && vb->dirty !=3D VMAP_BBMAP_BI= TS) { > > unsigned long va_start =3D vb->va->va_sta= rt; > > unsigned long s, e; > > -- > > 2.25.1 > > > > > > -- > > Best Regards, > Hailong.