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 D2BADC27C4F for ; Tue, 11 Jun 2024 01:08:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 603CA6B00A4; Mon, 10 Jun 2024 21:08:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B38C6B00A5; Mon, 10 Jun 2024 21:08:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 453E56B00A6; Mon, 10 Jun 2024 21:08:17 -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 2725A6B00A4 for ; Mon, 10 Jun 2024 21:08:17 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AC1E4161160 for ; Tue, 11 Jun 2024 01:08:16 +0000 (UTC) X-FDA: 82216821792.07.06BC41F Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by imf01.hostedemail.com (Postfix) with ESMTP id BEEF04000A for ; Tue, 11 Jun 2024 01:08:14 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aclz9aDB; spf=pass (imf01.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.50 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=1718068094; 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=M+ZWn0gn7fJB3UcfcfpvLfhaBIj+uVErC4f5zELzVp0=; b=y+xod6A6RKYyOWUplc8Crj13+XSqH1E8BSWTGv3Eb9kJIrUpgEUqaJ3UtlcQtxPdqvx06P xdogc9aox6Xngw2n7fH16dsiO20ZjCADQMTOYRS7lPAclEgInfqnyXcaS3ESKaIttDJblA vdcz2a9cF6wCRBwBqgif4UcQ8FuROA8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718068094; a=rsa-sha256; cv=none; b=pTfAq2I3Yxz2Dzn6QQC3ITMYpAkx+Xg+B4K5McabCQfhMVoOlRB9EKCgYRDCn2ij52AZGY f35pHzKki1Mb3KwdoryKaUs29oCi9Kh7fsfGr4OYAcQ/3LM8E/HDDYJ6EEgMqAO1CVhSTr 5YmHAjmkVqNlg+UIbFSe1OmKvizfR/A= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aclz9aDB; spf=pass (imf01.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.167.50 as permitted sender) smtp.mailfrom=huangzhaoyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-52c7f7fdd24so632029e87.1 for ; Mon, 10 Jun 2024 18:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718068093; x=1718672893; 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=M+ZWn0gn7fJB3UcfcfpvLfhaBIj+uVErC4f5zELzVp0=; b=aclz9aDBRbsuLUHQlf5X2G/ZsOTDipeRu9tX3iTcBR5D7xYpQX2av8B0FwkttapvJ4 cXLU9yMfeBOVwjiz49CFyqAeB8iGM9xCrOiSRUUWgh6Fb/mw4hr3I9AY0tZfMMGMX0h5 fl6Q2ErlGVtrfkZmcwAJweLCtxXYQttaZ//VQXmGPLPDz6NBJNEB+Dr5sV4bXoFb4VuK puiUbL36L208sbSCOXHQDlc8gsFUtelbKDIB/oUGsJv0Ldfdaz2W/Txa/HvBXXVC+c69 TkJoE7wCinm1L+RIC1F7qRSwE9SpuLIjZludQoqN25yVlPBoedhPJ/n791qFimVfZOTP sGTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718068093; x=1718672893; 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=M+ZWn0gn7fJB3UcfcfpvLfhaBIj+uVErC4f5zELzVp0=; b=pkMJNROK/M1yp8Uk1lRw1C3zK4/Z+l+m4cLgSarMZ4+UotjosZLqPigcnqp68OdvAu 4o9fRSHtn8ljiswbkhpo4PHneM0jSvdCOSTTTtS2ho9hETdtj8JyKI2vWp+QhDuftF7i t3B87OFd1qwJmYlYLS1Vb6Khk1ZaBEWneJOt/130DU1o51F4WMOibQ43gNqq/OwnFTPP 4wmnsmKxuY/+++XNRQPr04GYOK6Q/W/CEU/RJdXzWKs6zUIDH/YMse97AqyxQmVqXqDW VvH0FZ84+7AIS1EcOqZVfPRwdZ0SdPSbR2CJn+F6dEHJ16S11svxTQhk1mursWV2rl6F PuYA== X-Forwarded-Encrypted: i=1; AJvYcCXymvS32vurbprcp8VLxKjyz6a7VCLocnlOLgPKODf36uJPwlbNIA9fxQFR+1shpCBWNudk54pri1TAm0wc+yPUy0E= X-Gm-Message-State: AOJu0Yx4Cacrctl1ZuOBK4vM6Z1YRUGChvuLwivHhKnGOa7qdlxtpIyd 7rabuxNoyqjerFvSOpjKOsV+MFEFoV8/H1gShCL7X/JpfCN2nCCpsEISQVXD8V2uLCZYN0Qb3xX pqPDk5sDteDZvpTIPJGWDJeNHXVw= X-Google-Smtp-Source: AGHT+IFSdaKppOajPUvijdsxgqezBJxzNWurRI85dJT3RFbYwJ/g3YYKeIYsUOajnfgxQb6JE4/eTnmUgK5kJS7jo+M= X-Received: by 2002:a19:5e44:0:b0:52b:796e:66a5 with SMTP id 2adb3069b0e04-52bb9fd281cmr5789338e87.66.1718068092645; Mon, 10 Jun 2024 18:08:12 -0700 (PDT) MIME-Version: 1.0 References: <20240607023116.1720640-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Tue, 11 Jun 2024 09:08:01 +0800 Message-ID: Subject: Re: [Resend 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, stable@vger.kernel.org, steve.kang@unisoc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: jwks6pej6fijixhjg7zk1qbb6fguxep4 X-Rspamd-Queue-Id: BEEF04000A X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1718068094-956292 X-HE-Meta: U2FsdGVkX19E/mSz6UPcA2AJYXRg3JEkMsV2Kef9g9r//9VSc9ZAMTVuJwAZeByZ0ecvhTI9ZXP3LRVrIYxzOLC0JnTh1aQi17LanPkVgFINuV3twcJq7vj2iu7FPagjByF5bOU2CshN7w0SJJCTuMtFQKhwqixo3Hilud0hkVznaZ2l15SP2Pc31E8NVugzjoN1QtcWJ1gVf6elclJ9CAvwhnYcHdqvxvcgqEmHl4ghFC6hpnB6ExTCXlXDTYge1j1Luuv1MbbiJirAIs7LaC0J8km9/pgT1RJ2u9oJYaBhUDCxHvNwDcCvjWaiVD/SaF1HxNAuosbLLnefeKhfLtm9Cg6wDazawW3UXfWF3QBlqZYXwjiuOPMo9nGNT0HEJEjlHuLvPpvEdGYNzjniFoCoY8zWj83ifehkM0gwcbrJdQvV4t423joqxCC1idzi8c5wqoy7ge7NscBG1VNg+HDLDf5rJxQ8PoL+gwW6PcnUlJ1PrCX+jzFhdFsiV6vpNao3WP1Ehl2Z+yv1yFHOspijyLHZwabEIo8smpytb0Ynen/9rQoeui/Kwn+38s2KOJ57FvT3tj0/DXNWRg2/0ZzgHUi6yC2ola9ANAilOIV30iv6wOWJ2UOZVUOMzpkZ00IPxX+B4DVAL80yAYFfPfkILEp/nWtUS1eHauqvz0B3FL7L2C8KUov+zed9i408kq/2ti1TtuUBPOLOMORgVYOHJI523KWkDuwir4QKcQjwL4pKg/EF0olMYO5VvoG3kWpBvQpB5ScG2OhCsbSgzGOL9Y6WOXz2Jg///2IVbF7yAqp2fhrWkm5kObDr1TxBbPgQYNo7oWwhhI9p4BZSlYEbyTAuKUk+o2sT9ipXN1bVVPDgqSa6pxJdMvNXfxAZ94TNAVD6+rQNMDSMAR+drMoD5Jf9wtunoeuyNUHkPA+culdT8p5hrPBcBgKMnzn3Au5SACY7YR2ckjrjk8i HaDtIziS nZf82krZQf5YUDJESkQB9Xdd4ToKCSAfCLn73WwP7o063M2Pzjzg6v4Pdb6qaqc3bOBHo9EoKSz8spS3sGFrZru6OCiZC9FKZ1a2SRFA3lD1lN/Acf+llgtJJk4wO5WKChxQs1k27PZfvqj1+O6HFj+8E6fKnbIDp86KXuZGqOplw0p477+3/I3XaUUs71/1P+Arcm7W/Cy+Wg/5PzT92NzItYvL8JeIvQ1FlkhW8pPPLw0uT2bE/BKA9sLrYYlMGmjrEtPMkMBBMKvIEH6HN17sJGc/3m9omOhRQx0zpCzvyKj9EAvY5B+HsVRlKJWfgh5U66SQ2M8VrpNZZgLuG7xd4bXqOwlUaKNMD0xRJN0jy+HOfbtOnK1d4+D4suYfX5X6f1boZ04dh/vPsAmkFWMH0gwlNEBeHrceWGr+LtDLo9M7OE+tQ62zTbSEB/GZwfcTLNTYVcBDYPV49X/DBUxQinakrQRWmU6X7mFRpIZkCMmS9jdemZJpaLsOGpm/1GYJP 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: Sorry to bother you again. Are there any other comments or new patch on this which block some test cases of ANDROID that only accept ACKed one on its tree. On Fri, Jun 7, 2024 at 4:30=E2=80=AFPM Zhaoyang Huang wrote: > > Patchv4 was updated based on Hailong and Uladzislau's comments, where > vbq is obtained from vb->cpu, thus avoiding disabling preemption. > Furthermore, Baoquan's suggestion was not adopted because it made vbq > accesses completely interleaved across all CPUs, which defeats the > goal of per_cpu. > > On Fri, Jun 7, 2024 at 10:31=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 = blocks") > > > > 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 preemptio= n > > --- > > --- > > 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 pu= rposes */ > > @@ -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 =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 *v= b) > > } > > > > static bool purge_fragmented_block(struct vmap_block *vb, > > - struct vmap_block_queue *vbq, struct list_head *purge_l= ist, > > - bool force_purge) > > + struct list_head *purge_list, bool force_purge) > > { > > + struct vmap_block_queue *vbq =3D &per_cpu(vmap_block_queue, vb-= >cpu); > > + > > 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_lis= t, false) && > > + if (!purge_fragmented_block(vb, &purge_list, fa= lse) && > > vb->dirty_max && vb->dirty !=3D VMAP_BBMAP_= BITS) { > > unsigned long va_start =3D vb->va->va_s= tart; > > unsigned long s, e; > > -- > > 2.25.1 > >