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 3FF93C25B75 for ; Thu, 6 Jun 2024 03:10:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CAAF26B009F; Wed, 5 Jun 2024 23:10:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C59E06B00A0; Wed, 5 Jun 2024 23:10:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B21946B00A1; Wed, 5 Jun 2024 23:10:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 93BAC6B009F for ; Wed, 5 Jun 2024 23:10:16 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 096B8806F7 for ; Thu, 6 Jun 2024 03:10:16 +0000 (UTC) X-FDA: 82198985232.28.72F9C3A Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf16.hostedemail.com (Postfix) with ESMTP id 34AC618000C for ; Thu, 6 Jun 2024 03:10:13 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Xp9O/cpj"; spf=pass (imf16.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=1717643414; a=rsa-sha256; cv=none; b=Es7lx7mFMtS38kzQpB1v6ksLTBIdH9OvoT4xGoYmk4i+4XBSdQCbZkFQR0sZbEeV+/pf0L ztAfOgsGD1Ld2wK5QbRzMMCRaXU/ajJnXste+ix4Q+Ub1NQOD21WnD6zpATi7RFFZhPwMB CwSJmpsu51LDTS7GpZjH74RhvL+i/gs= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Xp9O/cpj"; spf=pass (imf16.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=1717643414; 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=XfY1Fcfk5dDBAApcQFnkeusEIm9Y4xpt1EazgOKzvgg=; b=52H03HaS8C5Rhxz2NNLBiMaUGBojk9hocXcVlLQ1EFaFeG3WBzu3/hwoAdIAtENEqvE9wW ugPkoPsg/BXLskQcjGu7a+SUzD9I+omo3T+BLdvJzIhyBrlABcGr6tfgyGninYK2eyqTPr MSUSGfKgaAslTsQCWlntr4FS3BsLapc= Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2e95a75a90eso4770091fa.2 for ; Wed, 05 Jun 2024 20:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717643412; x=1718248212; 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=XfY1Fcfk5dDBAApcQFnkeusEIm9Y4xpt1EazgOKzvgg=; b=Xp9O/cpj5j1eiYuQA0PsMgUDvZa4kZkkCfcxgB0/jdBfeh4QvhybrrVky8HucftdF6 kgUNTdzFS0LmugBZtPiYA7ZOU1J8ZwQsKb5KPCLWcsKdblzXZi/Uu8sl7A2J8Wa6xV1X 3AzM8nIo8Td/yQE5qKR7AQIZSd1XKGQJfZ+A5UBdG6o0YhJhjaCizz6bUouw138GWTPl Tdc9cp7V3IvCFQZftI06N+KD9x/32n0MXqeG/m88Jdqe8xVAD5BR/i12fuK0CQqGMWTy bfb4BHOvDV6mEoI/hMH8X6Mv3lF+6qCWVCeMvXlqIW2491OoCU/WmgPDUJFgbb2HK+VQ AWnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717643412; x=1718248212; 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=XfY1Fcfk5dDBAApcQFnkeusEIm9Y4xpt1EazgOKzvgg=; b=C0avy38ZhVIYWczt9D7wW81bFncWus/2NDmUISrSUojK3Y1fw26SzOZbR/vi1Wna0I f2noXhmgHNcgk4p7+4ipT2Dw7OmA62c1U9DC7EyOpNMf8583xtrXcBZ55Poi7cz5gB0J UIoQFw2hnuzqPTScRsGPhJ2QekhPl+opyGiIatXMgAgxzNhW5ZQ9cDWuROkrvkrzaK0R 4tNxHdrWLHzg6cDdoPQwtSTyWjUOPJbFTESjoXGiE6g8j92R0tSBxXTFeOZQztoakjwA XXD5CIoCwlhcz5KiMddJz5Z4FhlS4+m35uWW1+Y9ZIAiOAerNDewxtsFXV+Gai8maaOR plAA== X-Forwarded-Encrypted: i=1; AJvYcCV89G2mE3xBNVqdgry+1DQxrohYw4e2uJz1mH0v/a09jPApnxgMQNUxOrXHTM/pFqqWubD2/wrTe3a49N2ElKWuN+U= X-Gm-Message-State: AOJu0YxrkL9LFjRHLNIvC2zrsOLOhmNxAbu1eF7cOSXJ7GKw6lfONANt WEQ6SZrHAphn076HD8V02VF2UnvZ2Vs8MgyXMlAcsXiyHZDuBk0jG7JNNF352a7vtEvnG3bbcd2 AALJPor5/5ccUvE1DapyBPFfxA7Y= X-Google-Smtp-Source: AGHT+IHP8bY9IHXPIKOEaVEYVbX+eiQBJNrfDc1riznfaIWj31JWfhAGcFb3/wFXC4SJITLcjJOMmkLdPs7T6iQJ9H4= X-Received: by 2002:a2e:9188:0:b0:2ea:8abe:2319 with SMTP id 38308e7fff4ca-2eac7783081mr22581081fa.0.1717643412278; Wed, 05 Jun 2024 20:10:12 -0700 (PDT) MIME-Version: 1.0 References: <20240604022232.1669983-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Thu, 6 Jun 2024 11:10:01 +0800 Message-ID: Subject: Re: [PATCHv4 1/1] mm: fix incorrect vbq reference in purge_fragmented_block To: Baoquan He Cc: "zhaoyang.huang" , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , 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-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 34AC618000C X-Stat-Signature: ikexotjxkfngkouuf8i6ncigf7sd8x8h X-HE-Tag: 1717643413-960743 X-HE-Meta: U2FsdGVkX1+XMUwPxNd1Ua4LdTGFIB19vOrkzJOHcI8PMmUI5CcP+64GKd9kjCWzaPFeINNCOo3/iWDy4M//euz/EaAiRj/mZLZsjMj86RriV+7DAhJwsQHd4oLswxl6pvVNepRAucbQdIK7W+U4fP0PUmv/uqACzDNlc4EBw2WoBjwgItieAYmCrR03FRK8yezeIh4EUcPbto736ItTSpeiO4a1HLoK+Prg3fdmVVla2/026zBknewoCL3A/25pspSLjS4SnkpnlYjyR4gpQIoJY73xrT6zaFnp4rU5SGjfQwJW6N96Xs1zkjGxS58txUj9Qpl5YpdonqI00Ml0hzlO0bRNmphFf+5kGAtVJJT/f0ohsJyoNy44eE0HLIKaopT0+xzpCI0m+okcVaeatkXsxm4MicFpkq6WiOjdOEtyT7EW8dqjISXfoAX5xjUNPGSYIN7ltcH3HJlqGQ/Rz60Ih23XhB+BsvEV/wAeX9UstBXDJO+7za29Hmpvg0H51v8nCm96YtuFa+XijUIN4Kgx8U7q6xO1R9haJdSxbMzBDG3QQF1kZMS1Pz6aox5dBy5RWws8npdU7q9kt3CFXzJES6KxqujeMafi8xPzStIz3JKdFzP89NIt9AFiiDEgykafSjMJInBdo4eKGgrTimG57fDYaQFyfceKChUjpX/mgnIvBbb6nh3p92tGL0v21n/Lbo9VDg7ymXVvgGB/63vZgjqs0ndoR9MuZ/uofoKTZ+YPixS2Fyp0KW3+MyRYpdCpcxVL2B/lghnULF6jlAqI+h24aM7zYSUg8B0XvA5Czi8wM6MYK/WYz2SAx53BmR3NO4j5VUgrCBPrTcrxN91GtyvyHyEUnfCXYwovQnvmtbaU31Q3XqhE3WBF6okn654FkCtJqgq2ngzhKA8E8HGsyfh9fu2BumC3KSZVLaWbWfhVwI8rzycipYxRoqct2edN3Ca4nFml72mrGi4 /Qrn7f12 GX0OZoFj2f0CFCkhrTD+yrmPyKl2Oud3DS0TBX0q3F6ey+x4vYlWnsbtt7FKiZ2kneGKuxL17PnEhtUWjgud6eKCfdQ7jn/ZII2Z+EuWpZkG1VwQ43kB+NesYSOQpDtYD549SbR1e70h74q3WFGiCBh05pY8oqKJlAZA8WmTKwqEXFnlJ6rAMY7GqEQoHAlcpsYOs8iA66Y+TSrZASMZqd2pP6DWRZFoID3XN+a6ounjSPyMD6zpIG7P7JpD/9c5CUlgJshMeSJ2fvWJYThZJCmLdJB9OM4h6kGi7oJQWs3VeRd5As8tgTudD3Y9lUXFrYazICAQ3QnYTnSZFXq4Fwf9K2Duu9ffEK0vuMH3KJfDgz0kRHOuSUCiswBYOlSAEgSNbseo+OwM1uhDf37PrI24p2uRX2gmK7/hNygeQTR3ZGxkE+qW46O5RlcXM2o4alKzsR7xNj7GGSUffSXxk7mX+t6pLay0VL7pVQkdcSZFQ5kd93eBfhZpIl/0rM3OO5waUfyj6Euke/AyNXXhsEPYuV3FLkkuK4rGj/vavAJhmrempz2OBbeIcGHDk1uPYJ6IbOmWfxwDN/PDuwDrIVzL7COYtmOootXyh 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 Thu, Jun 6, 2024 at 10:42=E2=80=AFAM Baoquan He wrote: > > On 06/06/24 at 10:28am, Zhaoyang Huang wrote: > > This patch is urgent for the Android world which uses v6.6 now. Is > > there any comments on this? Thanks! > > You should take the way Willf and I suggested, to adjust the vba->free > to only contain the vb belonging to it. Have you tested the draft patch? The vbq access will be totally mixed by your suggestion which means vb_alloc on CPUx could get the vb on every CPU which has per_cpu declaration making no sense. > > > > > 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 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") > > > > > > For detailed reason of broken list, please refer to below URL > > > https://lore.kernel.org/all/20240531024820.5507-1-hailong.liu@oppo.co= m/ > > > > > > 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 preempt= ion > > > --- > > > --- > > > 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 =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= _list, > > > - bool force_purge) > > > + struct list_head *purge_list, bool force_purge) > > > { > > > + struct vmap_block_queue *vbq =3D &per_cpu(vmap_block_queue, v= b->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 sta= rt, unsigned long end, int flush) > > > * not purgeable, check whether there is dirt= y > > > * space to be flushed. > > > */ > > > - if (!purge_fragmented_block(vb, vbq, &purge_l= ist, false) && > > > + if (!purge_fragmented_block(vb, &purge_list, = false) && > > > vb->dirty_max && vb->dirty !=3D VMAP_BBMA= P_BITS) { > > > unsigned long va_start =3D vb->va->va= _start; > > > unsigned long s, e; > > > -- > > > 2.25.1 > > > > > >