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 97746C25B74 for ; Thu, 30 May 2024 09:25:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23C9C6B0093; Thu, 30 May 2024 05:25:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C6F46B0095; Thu, 30 May 2024 05:25:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0413D6B0096; Thu, 30 May 2024 05:25:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D8BE16B0093 for ; Thu, 30 May 2024 05:25:45 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 553801C0088 for ; Thu, 30 May 2024 09:25:45 +0000 (UTC) X-FDA: 82174529850.16.2E01C33 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by imf07.hostedemail.com (Postfix) with ESMTP id 69D2C4000E for ; Thu, 30 May 2024 09:25:43 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YBltvlWw; spf=pass (imf07.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.181 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=1717061143; a=rsa-sha256; cv=none; b=l9AQhmCLWgfgBr7cIfe6W7H+6l8Bi5feuwjx3BPsBOm5EOhu6E9wFt8JTps4/85HynAK8n K1r5UNdig+Pc15r5GJQos5iRwK+RPwon3sS9jkggVfCD9slpAc/p6cFhGEYfJTE8oQ5fhx uWRSUD4ymoQBYbm7W3P5rt3sN8PuZVI= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YBltvlWw; spf=pass (imf07.hostedemail.com: domain of huangzhaoyang@gmail.com designates 209.85.208.181 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=1717061143; 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=9qEQtI0w/h5uhl2GdND/gyfYte2np2VCW52giOM0EVI=; b=3jZ9XX0wDI3xa7KqSzro+tNYe8uk/TgSJg9mAnN5b2s8Cvi/LfqPMc8ZSlgL8jRGbTHho3 udiEK5DnMXsuU4KTycKopt9Dv5dziWfg/StVB58O8sOqQLy1TYlI/CzynRNFOnCtNLmn9v I/qn47SZhSmUL9f8o3yccDG9y8Rq7cI= Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2e96f29884dso7305301fa.0 for ; Thu, 30 May 2024 02:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717061142; x=1717665942; 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=9qEQtI0w/h5uhl2GdND/gyfYte2np2VCW52giOM0EVI=; b=YBltvlWwQOU4XRDt7NEiZPPaAa5SNJZhONILyf7XIe+REMaandTBlohYR4S3PT/sOc sgHdITkrWbxCdadjtywBMdFgw3O5x1hjcgKADlulpxKvP13dpj21qMxPxtuWoLBI4yYe DCZDvOfqCp+wnDTXKf2sw2apyC45nNF468MoMw1rwBcdwT90gsozivtYMJ6jAwjbx7J/ rxFwdt6JPSc0SvY937UxHQGB9c8hRcDVa7ggXBN+33ZNQQNtTs7RvCtwi9Ll53hcz25E SV9u+CDp9iMH9JvQtE2ZVktbVpwj/gPDD/t4Os+s3MfM9NrfgterSy9DAtP/AGF9kSY5 b3rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717061142; x=1717665942; 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=9qEQtI0w/h5uhl2GdND/gyfYte2np2VCW52giOM0EVI=; b=NQHqjM/gDfWlbeYxoE4I/1nCxNxAks1er/n2fltrFgyuffPBCWywvCHER0Rmdlb6be xm45HWLLSiRLY6cFH+26f+DqYdjblN5FHJE++tWo1SMhOU7hVYep4QolOg4C+M2O7RpF +vA414v+T+jPil7kB/jOeEwkAN+iHM5oWlzEGyMkwUTFKwpuy3Oc2d24Rhxr2H5v4uaw zAn9wKlmWZ9paogF8WmDnCLNyEueTsjSs0km4tVnt6uEBJVSLiS3sY7y4kpApvLvXRn+ niQKqCqXOxI3azcIQ3LMl8tiQmdMRSQ2IEHl5lpeGsVl9VOmPFn8mcLjTaxN7b8Vw0j/ XgZg== X-Forwarded-Encrypted: i=1; AJvYcCWbFat63r1+8Ng8HJORQMiUqcqC+tOarSrpheBpBl54IFjviMe15NLyTOU3ddocwhK3OYndi5My3vTjGYFUU9O8l9A= X-Gm-Message-State: AOJu0YxNfcW+hyDcxxvNYGYxNKUm8bTjeBdQIc9GJ5IawJR3o/U/zKTo TRivtIURR+CFLASYha4LEp3WD4M496RsopBF156lIe4N6R6MSmz6KIv7xx4xn99sj+USEZadnLn 2F0QvsfK+Z329n4UHjwPES/SP2PM= X-Google-Smtp-Source: AGHT+IFkDVKnM9FMlK+mk303DRx15yfjrrlVBsQEQpVmKYHUMA7zyUldVw343zu9ctJujyJMU7LZ43kbf2xohD7qPzY= X-Received: by 2002:a2e:2c0f:0:b0:2e1:a15b:b504 with SMTP id 38308e7fff4ca-2ea8485bcc1mr7658761fa.37.1717061141494; Thu, 30 May 2024 02:25:41 -0700 (PDT) MIME-Version: 1.0 References: <20240530025144.1570865-1-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Thu, 30 May 2024 17:25:30 +0800 Message-ID: Subject: Re: [PATCH] mm: fix incorrect vbq reference in purge_fragmented_block To: Chuanhua Han Cc: "zhaoyang.huang" , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Baoquan He , 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: 69D2C4000E X-Stat-Signature: uau8f56h3sxeghqus1hmwxzwwpsik69e X-HE-Tag: 1717061143-329701 X-HE-Meta: U2FsdGVkX1+mqbgsRlJRieCpiwZ2OukL5gv5kj/mp58M3cakRSV8EjOxgGBu1bqVXovD3HJbj8yDbbv/KoBPRjGPrPXNX3gTAJyarbKI8bE14QzgVizUpdj+KiTq1WZ14KXSmmyo9kS2+KkkGro/sAm8CvCMKilAlNXldLjqUj3Snc5CLDQnq2ggU+ie/2CzpxMsZeHDNWQrqzh/tE7/wPb4FwmTJ9nf6WtPi/+pHjcSsI3AINu9vRAY6FrpkmyNiRPhCWr1bOTeZl5yvcW16gc+UZR0wgwszJTw0HZzMWXSu52vnHhbSg6OiWwBq7fK717ZUo5wHXZa0RONhcOHePgVPocrm3vVterslAHnYtROVqULrBSoU4XCpaayOwJVokoJFF/jbszygBxd+GAlfTG/nucl32BdNgRlg29FNV0/7/6eWFovg0UaY47hcfgajXHnvN4IUipd1aWukRabm04XIJnBZ/De0oWR0DzTKRRS9FMmS/svSK/AMjAebxa5y4BveKbV3fZzQwWIJ1LOCEB5nQxBm471C9S99bQ6wuPXxqKSyrpSG1+PNk2frHAW3/DDvRO4hYlpdyzx1CkLCbOFZxlXXc1NVLHphc0jrsJEwh2BVCv9MeU7X4XQc2jOWNAW0tH4U56B6jnrLjc85+Ca+gUtNie66IXffxKAhb8hDhq4wSTFx3OIWwH7ludbhtwebp/ekyMADTbpNGbgPwXAPZfygZI5VtrXVo+3nDfE4UGJWR5jMd1E3K3Uo0vFtKs6RUrXzLSPSVz+QDgADaJPOctpHfhjtgCugFsaC6o7Q4vH90fLI52NliG/2RgBas+52gh8+OJPOtPWTWdhkUmMpaIrPNqjYW+Ld5FK8aQvS52v6lq1qVeRdw4o19y98Mo3GMBsWY6Tpam/lqQWwHUi3sG5Zg5uZy3gim4wfvftPA9XqKfuIFH6cHy/ZP6ntIGphvwbw8qMRay1gAx faTWDHKo dBz8lbMyXmTTt3S5mnGcMmr/xOUb7vXAfERNjCKKA4IO/9PBxC/G0/dEVBiKZxu7LeGClqHSZD5L5NNfg1BmD2wc8HyiD585QoHX8FBxfWwxn1ScITFjHcmie5qO2LK0/5Vzm/f1DUz09uyJcljZ1/2ACHVS8GEg1ToeK1rzJB3WVdLMEqtZdKOqXaPQvN3hvq/hmDegABinXt9EuBV2at7sgRSYhnBvnH9Fkqcw+pXdzGFHPR36YxXuecklUsrEUGnCSdYhVbH4u5LDArM8Bbr/Ae39djmHWbZUHACy5B/tw4/ptltNo0VwEgMLPEWGGH4w9PnL7XWSufeitKmu061s/Yp9w1L+IuF1GYFzHmg5djJdc4OS9lRylMzRUhC+da0FLNk8ekbTAfptnCri/27Iqa2j4j1nWjy+U7pv+QDaWB+XM3PS3Ih/vg6AW7LieSi97eJL/LsgRXjjjtTP1wZ27LUAUN1Mq+eW8 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, May 30, 2024 at 5:16=E2=80=AFPM Chuanhua Han wrote: > > zhaoyang.huang =E4=BA=8E2024=E5=B9=B45=E6=9C= =8830=E6=97=A5=E5=91=A8=E5=9B=9B 10:52=E5=86=99=E9=81=93=EF=BC=9A > > > > From: Zhaoyang Huang > > > > Broken vbq->free reported on a v6.6 based system which is caused > > by invalid vbq->lock protect over vbq->free in purge_fragmented_block. > > This should be introduced by the Fixes below which ignored vbq->lock > > matter. > > > > Fixes: fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilized = blocks") > > > > Signed-off-by: Zhaoyang Huang > > --- > > mm/vmalloc.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 22aa63f4ef63..112b50431725 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -2614,9 +2614,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; > > + > > if (vb->free + vb->dirty !=3D VMAP_BBMAP_BITS || > > vb->dirty =3D=3D VMAP_BBMAP_BITS) > > return false; > > @@ -2625,6 +2626,8 @@ static bool purge_fragmented_block(struct vmap_bl= ock *vb, > > if (!(force_purge || vb->free < VMAP_PURGE_THRESHOLD)) > > return false; > > > > + vbq =3D container_of(addr_to_vb_xa(vb->va->va_start), > > + struct vmap_block_queue, vmap_blocks); > This seems to be the same as before fix :), the vbq found by > addr_to_vb_xa is still added to the xarray vbq, not necessarily to the > free_list vbq, Yes, my fault. Should we expand the vmap_block_queue by introducing a cpu_id which I actually do in my local regression. > These two vbqs may not be the same, we need to find the vbq when added > to free_list. > > For example: > We add vb to vbq1's xarray and vbq2's free_list, and we need to find > vbq2 instead of vbq1. > So I feel like this place isn't really fixed=EF=BC=9F > > /* prevent further allocs after releasing lock */ > > WRITE_ONCE(vb->free, 0); > > /* prevent purging it again */ > > @@ -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_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 > > > > > > > -- > Thanks, > Chuanhua