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 0D3DFC27C4F for ; Fri, 14 Jun 2024 01:46:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D1E16B00A7; Thu, 13 Jun 2024 21:44:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 681866B00A8; Thu, 13 Jun 2024 21:44:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 548976B00AD; Thu, 13 Jun 2024 21:44:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 37F786B00A7 for ; Thu, 13 Jun 2024 21:44:28 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D300C1C062B for ; Fri, 14 Jun 2024 01:44:27 +0000 (UTC) X-FDA: 82227799374.17.0458E8E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 867F2C000D for ; Fri, 14 Jun 2024 01:44:24 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bM3IP+rI; spf=pass (imf22.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718329464; 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=F9lKE8hYmf6g8IWvc3VrycK3qfVps8kbUy/YMAHDU0c=; b=zBZm8+hJyRXPmEuNkdz6oRB9AiKAJAOiZMgLCkCJ/HdoIUZrKUte4+/Ptf+cvJ1Ztlmjl7 2XxgTlLxnplLxkha2gOoRsVd/7yVyMOWIgSW4xTcILniD0PZojkyox4omg7ISy3850P71S I+BeAqLPz4d/ioizWVHesG3a/19w4o8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718329464; a=rsa-sha256; cv=none; b=Bs1VTFr5Xe1EzRfLk8cW0JDhEqn4LAPYIhvzO3CghpQLgm/r8vkc30OxdN0u1NdBsX+/LB z9B21Spk22B0YP4zXOQKCMntpLgXGidSRoKUHy9xhOW+EZRC8yEl/ILZN4O68dUyi+4vvP NhtiWzh4zi9LSnuFF7Cr0ZIrfM8zr7c= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bM3IP+rI; spf=pass (imf22.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718329463; h=from:from: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; bh=F9lKE8hYmf6g8IWvc3VrycK3qfVps8kbUy/YMAHDU0c=; b=bM3IP+rIjTGbUKIKUez0AzngsEz6A+ruO3GU48YHaglpE+itI2ckIgYWp5YrfZc1IPhjQL R6JQih/tfyEjOSPshlx4RBK3qeu1An6HdMH1+QZG8d212oj/mDHmRCqH/z7gKPbywbmat4 Zem3WUR3RDPBBs378kGmPHh4Iq6/TW0= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-562-aN38hECoPl2QwgrDPMIVkw-1; Thu, 13 Jun 2024 21:44:16 -0400 X-MC-Unique: aN38hECoPl2QwgrDPMIVkw-1 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 011231956089; Fri, 14 Jun 2024 01:44:14 +0000 (UTC) Received: from localhost (unknown [10.72.112.37]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E8F5B19560AA; Fri, 14 Jun 2024 01:44:10 +0000 (UTC) Date: Fri, 14 Jun 2024 09:44:06 +0800 From: Baoquan He To: hailong liu , Zhaoyang Huang Cc: Uladzislau Rezki , "zhaoyang.huang" , Andrew Morton , Christoph Hellwig , Lorenzo Stoakes , Thomas Gleixner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, steve.kang@unisoc.com Subject: Re: [Resend PATCHv4 1/1] mm: fix incorrect vbq reference in purge_fragmented_block Message-ID: References: <20240607023116.1720640-1-zhaoyang.huang@unisoc.com> <20240613091106.sfgtmoto6u4tslq6@oppo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Rspamd-Queue-Id: 867F2C000D X-Stat-Signature: 51zracnt4zi94mia7zko1oxr9xenbuph X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1718329464-744971 X-HE-Meta: U2FsdGVkX1+H4fUHhO4cxM4NA/DbagrQFbIOfX5HjwaieX26ryCk1qAcEqvreOnqTbDPZMaYSTq6Y8DY2ScgEWmfwpiZ76V5W7TaZB4QNwTsl0zz4prjAGNP825mFfezeDBpKrlrUjw8C01OpwK1yothRctlVEQM8syU7HoCCY2phe2p6mZ/7Kz7PsDvgxtQmEF72YGGqzeo8YRnWyE8pdFe+oTvht8imb66FrMu90hQZDyLbfx3BrSSrS0xGAy7n4/QiZ0rnLqDc8zZCj9ttdGnSCtbJ8fAcNsGmyPAzpNPN6Wb0yR4OJHOfx5WNwGYzCyvlB8I2uLvxjnX+H/Zp1cELLSNXc13mCQ4ac4uekH8KjWQ06yQZnki9VmXxjnqNK2xdhpx14fdSlqNGzBbsrANWFU9q4XSUmvE7kbfBUfT2Vx1W7DImAr90ZMJDCQJnvUo2Gnfh+nrdr4j7KPq8Dh/UB6yfrT64K9m/8cMJbBuvv3SP/HqHl42jMQHZbjVaKMX1vrDSGQrXgY6VYTsd2CXy/nibnamPKkT8GmHiItXOHAUGgPVFJB82Ic/5eJzl9vdUi64HfDTkDRo0SkVvY6JhPQL2NFDUUZoCj74po+TZezakRLerXWh1Fsn3KVmZ3AwnAoGuPKMnbDFuxDjan9gHXsmjEBSJLEyOqWIa0vaiqmuT5ehLZv7Wo7KjuZfND9eX0Hk1ZakMqU3IDidJXBwWZeFbqNWpAE99/XXplA8iMf3dTAZ+eLsqkI0SrIzSUMHL0L3yyG45sWUlpyGvTgODD0CD4FHe4ES6i6wJXhZDotAy/82sJjky8FBOCP88GriUmr7tfrk/wTlTNQJiwgn2el9HXukK0YM9gPPFpjmDP44SVpjWC2C8EuXFMFpcU9rSfSKmtbAlGABKRtI2RlkSOv66LxnGj6t6zjd92FpMEB47/s291u5EQcKYrdtnBp9CYVwPyKxPmmn4Pq b2AYTjdl +a6jsHdNVEai8D6rq2zfECJleda60mq5gtqYrM98NY/yQxXr868J+eDM8oT6VcSiV0vq/Jb+//iKUFxU6IaaWDYRcsDrZJXvz86elIbWCwjB7ftjPUM5lHJqwc5F4VhHgBvZkJWAJTdU7txIVSs0/zP68U31Xo+AB2FJPxolru8gkhTSjjbHRVJ4TO9whCW06rAS9zafNXV/HM3gUmNRlZXxNZoQsJ+npnzozzgF6ouHicpM6O3OEkPchWCxOPlvOe3rXxBk51rNDOieqBUHiuL9D3sdMOaWrm8bTncwFFsPzqwmLo0zwQ9Lf5l3Nr8tMbQZ7utvpLi/o+XPasbHs91VxCkDyARZHAeWaVSGA7OrED79vS9efYhMGIE2rFW3966beTZxOk/LORdR+HT+MQGS9Qsoj5eaPIWsGvOCXuPdBvgLff0O70x0s+X5Mozpklh1GbuWWvEvJPG2ifC3xVvZRah5E1LeM2WkmsBHoGxetFaA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000037, 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 06/13/24 at 05:23pm, Zhaoyang Huang wrote: > On Thu, Jun 13, 2024 at 5:11 PM hailong liu wrote: > > > > On Thu, 13. Jun 16:41, Baoquan He wrote: > > > On 06/12/24 at 01:27pm, Uladzislau Rezki wrote: > > > > On Wed, Jun 12, 2024 at 10:00:14AM +0800, Zhaoyang Huang wrote: > > > > > On Wed, Jun 12, 2024 at 2:16 AM Uladzislau Rezki wrote: > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > I have just returned from vacation. Give me some time to review your > > > > > > patch. Meanwhile, do you have a reproducer? So i would like to see how > > > > > > i can trigger an issue that is in question. > > > > > This bug arises from an system wide android test which has been > > > > > reported by many vendors. Keep mount/unmount an erofs partition is > > > > > supposed to be a simple reproducer. IMO, the logic defect is obvious > > > > > enough to be found by code review. > > > > > > > > > Baoquan, any objection about this v4? > > > > > > > > Your proposal about inserting a new vmap-block based on it belongs > > > > to, i.e. not per-this-cpu, should fix an issue. The problem is that > > > > such way does __not__ pre-load a current CPU what is not good. > > > > > > With my understand, when we start handling to insert vb to vbq->xa and > > > vbq->free, the vmap_area allocation has been done, it doesn't impact the > > > CPU preloading when adding it into which CPU's vbq->free, does it? > > > > > > Not sure if I miss anything about the CPU preloading. > > > > > > > > > > IIUC, if vb put by hashing funcation. and the following scenario may occur: Thanks for the details, it's truly a problem as you said. > > > > A kthread limit on CPU_x and continuously calls vm_map_ram() > > The 1 call vm_map_ram(): no vb in cpu_x->free, so > > CPU_0->vb > > CPU_1 > > ... > > CPU_x > > > > The 2 call vm_map_ram(): no vb in cpu_x->free, so > > CPU_0->vb > > CPU_1->vb > > ... > > CPU_x > Yes, this could make the per_cpu vbq meaningless and the VMALLOC area > be abnormally consumed(like 8KB in 4MB for each allocation) > > > > -- > > help you, help me, > > Hailong. >