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 3CA05C25B75 for ; Fri, 31 May 2024 08:05:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C3366B0083; Fri, 31 May 2024 04:05:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7738A6B0085; Fri, 31 May 2024 04:05:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63B4A6B0088; Fri, 31 May 2024 04:05:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4607F6B0083 for ; Fri, 31 May 2024 04:05:05 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 77F48C1288 for ; Fri, 31 May 2024 08:05:04 +0000 (UTC) X-FDA: 82177955328.21.2ADD057 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf12.hostedemail.com (Postfix) with ESMTP id 7462F40029 for ; Fri, 31 May 2024 08:05:02 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=C4IBebMa; spf=pass (imf12.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717142702; a=rsa-sha256; cv=none; b=sQ15eisJvBicnF7JADmcWjBJt3Kh9/XHbc9Mze+0iFbsArZefRR4JhPmKbitSJXdV0Igsp 4DDw+YPaTp56EJa0nAzeHMFJIBhffW5RS6d3GQamv47FH5+ZzuxMHTv6/LgEp7LtzEH92s B7EuIzdnIHQBj/Jq95urM3Q60Qx0E6k= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=C4IBebMa; spf=pass (imf12.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=urezki@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=1717142702; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=H/lyt572tck3lje3O0S/YoFgYMtGpbPoXZ2zrD3MWgE=; b=bKh3ja7TRDJg4Bttk+1FQy0IBnhx776tgA1VgFYem2MD8kBZ5bZJDU9iFbbr13AYb1LC0u msTrfKOkZRTAkfYK/62ofsHx2dfDEIHZ3ajB3lxFxiWRgONJqMTy1WWsiSmR1svAz+n5g0 3inKD2BnorIC9eiTQwtvDrQrMFd8vFU= Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-52965199234so1779085e87.2 for ; Fri, 31 May 2024 01:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717142700; x=1717747500; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=H/lyt572tck3lje3O0S/YoFgYMtGpbPoXZ2zrD3MWgE=; b=C4IBebMaRbzLaheBw2EW0gd1o3tYYubUu0Rcz9lcBLKITpguVYU79je4r1gIZXxaVW Uc/vDJkdKXzxcgVwyyrNkZ6SiXzitIfDo/DFCcDEjsWfMohb1PlkQP80K5j1eU3iMn/X HcW5d+MPX1f5Mi3lou3+ofFZ30LE/GpYz+xDFQODk3/8zz4JE33e1Vsap0vRN9cSCy/O 8VQg2zk/xrJ3D5iqp5nmfZC4e9SuG2PJjUt5vftpWWjGSAMCn+F6X4i36ElErs5u0qU6 O2qAh4NSrzyronama7Eq1qmLYHEvzsAvPmQ35qPoksupMPxAcbRaVlGOKYLTW7Lc3n8e SIMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717142700; x=1717747500; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=H/lyt572tck3lje3O0S/YoFgYMtGpbPoXZ2zrD3MWgE=; b=bxoYdHSqU1MiKg4Uo07Nwhn9FNSSBo4MUKFJTZPbgS/6uFrLIwhrdHbFUs1ppQQb53 mThhHnxcoCyWUDobZNpisk4c/KvmAv/bmjX8zLI58BkYb0pdddTdcUAzDFJ7tkkLqoM6 EHsLXnl/dxT4YNcwgRd3mmD62jGEBq5Lemu2aSlr51WEZVLMJe4IgzTejQCbiReVECzr ZCU8Uw/tFhG+CV7szZQkIzZ9+5d5Ln1FheDnItFM8IV5UFIO+BIHqiTAjmKTi6wQFbHW xkQxbMxDipT0W+UWXskPeo6I8K8G++S1hnbRJollUZUINyx75g/Mm6oHaSRvxGHoRgG0 V64Q== X-Forwarded-Encrypted: i=1; AJvYcCVJJ4JZ1hz7fZxHZYkzUYXr76nptKT46osjB25d+8Cj/IX5u5D/0gsepBv2uBCoj59VhAFB3z/2Y+vSAT6GF6mlQq0= X-Gm-Message-State: AOJu0YxACnCOm4jmeF4D1UohiQVAt5CkV6rpokOGTRkYaUQLQSxFWPSg /8gs5TI8tT9GjChrJPV0+EQxbz+sLs5JyXCyESF9lIrSUJ5xGn5C X-Google-Smtp-Source: AGHT+IGpCuXGTZ8Xt7porjTHxJrfZgkQE6ybn4Sd9kHjWzof4gBAcCJaFTeI4onNWK1I0VZLt0R6uA== X-Received: by 2002:a05:6512:34cd:b0:52b:242b:5d1f with SMTP id 2adb3069b0e04-52b89573216mr651102e87.15.1717142700052; Fri, 31 May 2024 01:05:00 -0700 (PDT) Received: from pc636 (host-95-193-70-101.mobileonline.telia.com. [95.193.70.101]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-52b84d3f428sm250769e87.92.2024.05.31.01.04.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 May 2024 01:04:59 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 31 May 2024 10:04:55 +0200 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, Zhaoyang Huang , steve.kang@unisoc.com Subject: Re: [PATCHv3] mm: fix incorrect vbq reference in purge_fragmented_block Message-ID: References: <20240531030520.1615833-1-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240531030520.1615833-1-zhaoyang.huang@unisoc.com> X-Rspamd-Queue-Id: 7462F40029 X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: wxypd7a6foiwprd5pcrfmg154abn6y48 X-HE-Tag: 1717142702-993270 X-HE-Meta: U2FsdGVkX19J1wbnu5YrIs/47M2jJo0uxrPAwqGOREUOzrybc7tqobW3cdj97L1UsXaoC56v9LW+DH1S/EyPTZkLwvQAEBpsA1eyKdobHwHIPo8hI4/hg68ugJT1BnDeZ6RO0mu4W2Kkw+XWdzDUpBiw3CtH8ipgemYh1gb8Dc9b1FxPPX62+j1satLUVR0oNRWxR7EhCkVIelpZyYJh65T8lnlk9xH14rDd4759NrMTb3VlNy8fIiNFxO00aZn3LzBPcJUViTq3CpZWT7P8tXmZtqPGLCAu4WF5M+Bf8pY0QuassCjSE9buplBUIQZGvfZzC3+W/865BraT16An8RySHGi6tF7G1xS1XKWgZq/XcxAdTr8VYnTM+HXypX47u43/Zvz8WRbNxcL8L7MZS7xxzetH9LissbIcf7jyWH/07Fdm2h4Bn96q9sBWneo9qhJ5bdXGTIvnyfWZ5CSRwd7PcRKhdmEvh+dMAD3xChQH1skvAGOXVCEF9jFt6kZDhJXOl4HvaE/52BZ4SF9iT/fRVnO+8trJHPxqaLBzWp9xzYQt3gxPbxPGj8A+3wW8lbaN2yZqx6TaGWeV7shXr6X0hatCaam4U/d1IQmlXZ0MhuwJMjWju+elYmMWcqpeOIUlZtygJtKR0ty7vkB4jZYvaeSG4PaswsCZAXNOv8mn0+DSd5P0oo9PX9NHLhRZunBaLHL012dvz900Ft8FVm4hru5BtMKOwaH78j0B4drLvu9ucmET12+e69Uxooys4EElnMSyxIANEPFsRr74YzQjC4jRL5Cg95hDgvfSPxcbxncJQ1DQx8YD4J8CKC4MCC1s8myvCaEWl/Tm1dnF5JfQWuxB0UqdSe/kdIZkbmBban2LyjaiBbW04Y8stFjqoUadd2eKwa+JnpDxVnZwcwblfbwajRW6J5gQG+lrzxdQXsKOE8pHIMXooJNEJmoHTkZism4QTdnj3Vf3rFz WmkVyJ9D b+PMMilcXiCfLAqaywg5duVpLdYLyMn8RObU21ELn4x8d0x39/anGkAyfAE5NejY3w0KfeYbytzO1MgECEH6VOT/uDKKcehfmEL5I5v5GZRA4J/ZsBUDQIePlhwLhUYjwaUEttYXQ8BkfiFiK8U20mJdMqGWPZvxsPyPVBZkDXj6eDc5r4JUMbCaerJpsCDcLeb+lSqad99m/sY2O6yXPwdtQnz3UK8A3Ew6DX2IWV7PZWjE0rq40V8CgSCHbAb8R9saJCK+WQweMQjs5eH2QbekjrFLkHBpE0L8Gu2LwN4hG/JzDBYaB6WBLPqO36uCxv9uhgU6hcSKA48VMdxXjJ+XYWgRTUjuPgS0gahM7fxsygRtRx6scYVNQYNO7xF9eoc+jDryYkl8z43LmXaRdZn12AhYlPmkmv/iGz62W6THUMdcHmug8qUg4YXhlJpkuKf/VxvZILs6e3Sj/OKqvliH6IybCHo1ztSwAFVnMscMiTwgebWq7cSWMgwp+rUNtfYRG8Iq2COo38K71486FRJTseAsK22wZsFSNzXRciX9OXXeTXzrCB/bI8T7vNN5nL7EPHV1ixaMZ+EitS1HspgJJ8D5FBnr95CQM 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 11:05:20AM +0800, 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") > > Suggested-by: Hailong.Liu > Signed-off-by: Zhaoyang Huang > Is a problem related to run out of vmalloc space _only_ or it is a problem with broken list? From the commit message it is hard to follow the reason. Could you please post a full trace or panic? > --- > v2: introduce cpu in vmap_block to record the right CPU number > v3: use get_cpu/put_cpu to prevent schedule between core > --- > --- > mm/vmalloc.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 22aa63f4ef63..ecdb75d10949 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 */ > @@ -2586,10 +2587,12 @@ static void *new_vmap_block(unsigned int order, gfp_t gfp_mask) > return ERR_PTR(err); > } > > + vb->cpu = get_cpu(); > vbq = raw_cpu_ptr(&vmap_block_queue); > spin_lock(&vbq->lock); > list_add_tail_rcu(&vb->free_list, &vbq->free); > spin_unlock(&vbq->lock); > + put_cpu(); > Why do you need get_cpu() here? Can you go with raw_smp_processor_id() and then access the per-cpu "vmap_block_queue"? get_cpu() disables preemption and then a spin-lock is take within this critical section. >From the first glance PREEMPT_RT is broken in this case. I am on a vacation, responds can be with delays. -- Uladzislau Rezki