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 66C8FC25B76 for ; Thu, 6 Jun 2024 02:28:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE0966B009B; Wed, 5 Jun 2024 22:28:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A90C56B009C; Wed, 5 Jun 2024 22:28:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 931EC6B00A2; Wed, 5 Jun 2024 22:28:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 754A46B009B for ; Wed, 5 Jun 2024 22:28:19 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 14D591408BB for ; Thu, 6 Jun 2024 02:28:19 +0000 (UTC) X-FDA: 82198879518.30.DABBC85 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf25.hostedemail.com (Postfix) with ESMTP id 33866A0006 for ; Thu, 6 Jun 2024 02:28:16 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gr2K4umI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717640897; 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=VHMh/PZ5hRlBQq//Nja97uI/czGva41PtV0OcxeHB5I=; b=Nk1RjcxNCWC8LlPRH5F9Gd3YDLNbadaD7QUMAcImnkaXTwlkO1q2EsPA7YWcAzBubRxIht 1EWNYEJu++nOiZ2fpG+N4tx+w0FyWCAxu+YoA8cIcjrgc6p0KxZkYmvpIzi/yvw1TzFiuC 0cV9XudBk86dz2zbgbpmVTeCv/Eq7fo= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gr2K4umI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717640897; a=rsa-sha256; cv=none; b=0gu4VXQYVBxyc0gyTofbgY2cpbKg4DXdF5xaSdTRyUJVsG5PG0gjxdBsSKyVK+3dWyOsZ4 /mXXuPA1RidOdljuSVwWJlrgZeZJm+8mSY00uYZS1LdJIjmS8601LgAhpDJLE2o3k/Jr8Q T917PRc3zvPZR7S8TVZzELV1AcyOZgM= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-52b87e8ba1eso659306e87.3 for ; Wed, 05 Jun 2024 19:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717640895; x=1718245695; 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=VHMh/PZ5hRlBQq//Nja97uI/czGva41PtV0OcxeHB5I=; b=gr2K4umI7xiZg4NEZapfjWbqishOkEVC1Ny2sIK3EKRh44NK0lCp2xj8KNcVEmK2qe Au7NhrThDnZs9GjmBjvq2pjTRAQv8AcZMavpWYT08doCPQw95CeaUzYmBwpQACWED+zv g48FjoZeDHqLsHeAlJ2zI0xN1ONeaB8m5nATvcdwesStSLIxL9fzpjxZXMqDk/BCpyxW CZt3MTrCcMI4W9cOzv05FA0q8fKG8TZDXusYdrTzsctvb4NAWtYgZZu0pgWaGNnre7Me tgiU7p+Tadjx2KYiiQ7DP8ahvTzs8peC6CgG7jUPUCoFGSrgpDNRD5tVAhNAhwuXbWqp 6HgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717640895; x=1718245695; 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=VHMh/PZ5hRlBQq//Nja97uI/czGva41PtV0OcxeHB5I=; b=CR8ULNHVd9WCKNALvl6dpsPY8VgF7aHYVkwxN7LDu6K/f/OcFUDidq0H0JT7uOH353 dC6HtnYm7fehmu/c/oxpam7rktnYkxQgpuCC55ih9FvDR2pLPpzCDCGv0dIhe/0O/Xor EDZ8/Xm2i81VSwk2T7Eaae9Y040sh9lKAWExN2lgbOiytSCPDn27dwa8CPCxyZqUZUCS t4TaKNyDSzEVjkLtsE4JeaWYcBayld2K3UAYpUMnyTfdh48+GmjxRSFs1KjU05WHYq5L kiAel7hbVv8A6WwMXztez+s5htKrXnYns84TbLJsNqApCFtsnNn8KdL5IMFRqaMSaOzS v4pA== X-Forwarded-Encrypted: i=1; AJvYcCWlMqtf4FuAzmwFtplmLas8lZXdnv4iBocgfebt2jgULeLya6tzs62aD9yTHdRh5F3Eooa06d9QxxBa/GguOT465IM= X-Gm-Message-State: AOJu0YwksSIAHt4tSBG9DQJRPSWFn9DGblFPWtHGGV/OzueH156rEMkU eVCcI49yZp+w6Lq49tmGo5JnJn9ZYzrmsdbstF8KEl6YVb4U49gTwn9VcrivdeRKM29xP1fznOi //Q4pREPZ98od2qCD0ftBKFkoQmw= X-Google-Smtp-Source: AGHT+IFiNiF6n0TTdIzUtQYTp1Y4mPTYhbra86Wu7SO1hrfpM3738KffG5vCrSHmT7IK1z17wS3Ot1njFKQJTLRWJM4= X-Received: by 2002:a19:e053:0:b0:52b:8411:20e5 with SMTP id 2adb3069b0e04-52bab4dd189mr2947152e87.15.1717640895226; Wed, 05 Jun 2024 19:28:15 -0700 (PDT) MIME-Version: 1.0 References: <20240604022232.1669983-1-zhaoyang.huang@unisoc.com> In-Reply-To: <20240604022232.1669983-1-zhaoyang.huang@unisoc.com> From: Zhaoyang Huang Date: Thu, 6 Jun 2024 10:28:04 +0800 Message-ID: Subject: Re: [PATCHv4 1/1] mm: fix incorrect vbq reference in purge_fragmented_block To: "zhaoyang.huang" Cc: Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Baoquan He , Thomas Gleixner , hailong liu , 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-Rspamd-Queue-Id: 33866A0006 X-Stat-Signature: ybfjb79zm7h76dipxzx3iubjxfzjpw11 X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1717640896-531552 X-HE-Meta: U2FsdGVkX187Ko24YReh4Qnp6PNA6Govmt+iXyMnMQlurtgjRHxWGaxmICdYFSsH9JwoDQoB+dtRu7CNUAnLhB5LhqYNhvsF+8Pjci10NGrlpRu3I3NBfmWme0pALY0VE7CrdcuFowGokFE6pjGOVhLMhJcD9guGX5+0nTJWxB6xc0bUZzKXHNoOtuEaBiDl22NH2qcPOvKLQL1wXIgtRebLqYyT2bG5LO/wKIghdi3r29tekpmfFWI6KO7tdX0lYiwMOQg7AmqQRAvpNJMqgcUq2egXevXShe4rh46lcbFFhP203tf+jEYPMwIq1+kXsIzBOQAJvXA77ogTgV0PcVg/DffoE2eby8Ohz41vs7P5d1Le3aUOahyLMR2bB84jOqvbM5I2DaHV2PrW71Vfqs6LJTCEEP8ktM07KqmRcUt6DhO22/hojyC6fOINUA2oW7BFXOXfKYTn2F9PhzDS2bhKwmjt6zSsOCbcf04i8C5V7ZszMInAT796AearnsrclsAjJdzEHy0+IbDfNBJQANDvLR0tiOOpBlVdrmedvdQ9JoMZh9L2Fcov+Z1aRoUkxVKik5WaSfvRqa1HWi1k5dEI+4nuRvyifFxai0KtKbWoriT/CQ+3iUkNgxhsvKVNqufVUs5yyLxBfqSawp/VlxI9mX77R6S7qZUvNB7bKlqwOq5zK7EkWpPtmwo4Kxmq1rt8V3+G0G6uLk9pZlAOgKsPF4WHyKmvxQ2zgeboLQanRgxHWWAL2CrhUrbXwcvcBeVUYdm/JR1FwVC9xftJXq1/lshhqyuhwwY7dx76LWhehp35rb0fUAnKSre4rI5WKgOROtfkskYpx66SNlZPbRsBYiLUnYMfbxk0nviDymUAXP7U5Hkc37Go+6rmW+i6jlYL0xQJgBS8uco2VVqe6AmUdXbYbuntNYIbefsEUSVcKVhuxC7irx/n5f7Ke03NeGid+i5wxkMbn9wd/eZ zc5LKXvZ olF8yh5mIyZ+pfVPaVFwkLu1YceLb5M84iloVZ8A74Ei+nCnAuZVhRES4a3kaaugXImdmFzGl6wuf3Ex3J2Aby15jWysNfKqvM/JJ6YJboebMrRvGN9Pzp0I9WtP+xm3TqT1CWjR4wyFtp5ux64gReiqXDxzU7rAeTGOJm+nhAygi61AlXo0UBSaeSc/5svvsy44hAzqV8Mf7hWOWZ2xr/CNnra6qfC4mLFVzgQugvDVDVTq4BpizJelAyktm7vPC3HtRzzlOxjdJAPQbYOw5Fc/45yGetmi4M4jcSgSwKfbX92h4qpG2wpnRsRl+b0gkrltmM5N+KtkKPlEXhNhCg0HAdutcLR42NqgZbErziY89LzHYqmc7Z6mhpYTqbyh46zwLJkLoUk5CIX6GHirvhUvl0TXp3rDOVP67qsnZeE/PEVhAuN7u3Ru9wm9U7aA8Ud2sx0nn0z6Pdc3ocvs1PNVNY796SdKp7yFV8Q3uesgejV+HGSXYYy4G6J3zeLwx6i0VHaeZn6r8mq3ZoHKOLJWRyNpa0Z8Is0SVkCtLsfR/lBIqxsEBqX3p+EXV+6sk3ADGSMXY07nj0D8= 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: This patch is urgent for the Android world which uses v6.6 now. Is there any comments on this? Thanks! On Tue, Jun 4, 2024 at 10:23=E2=80=AFAM 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 bl= ocks") > > For detailed reason of broken list, please refer to below URL > https://lore.kernel.org/all/20240531024820.5507-1-hailong.liu@oppo.com/ > > 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 > --- > --- > 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 purp= oses */ > @@ -2585,8 +2586,15 @@ static void *new_vmap_block(unsigned int order, gf= p_t gfp_mask) > free_vmap_area(va); > return ERR_PTR(err); > } > - > - vbq =3D 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 =3D raw_smp_processor_id(); > + vbq =3D 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_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 +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, 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 >