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 090D1C27C4F for ; Fri, 14 Jun 2024 01:32:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AEB556B0085; Thu, 13 Jun 2024 21:32:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A9B746B0093; Thu, 13 Jun 2024 21:32:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93B296B00B0; Thu, 13 Jun 2024 21:32:55 -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 778236B0085 for ; Thu, 13 Jun 2024 21:32:55 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E59F51603EB for ; Fri, 14 Jun 2024 01:32:54 +0000 (UTC) X-FDA: 82227770268.08.C265EE0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf05.hostedemail.com (Postfix) with ESMTP id 253F710000C for ; Fri, 14 Jun 2024 01:32:52 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WkM+nJRZ; spf=pass (imf05.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.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=1718328771; 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=MomHJJ0WTXAcFGOMzH8XSlE6O618dhh1qz/zUs8NtfM=; b=OlY82U+KSF4hnIuDXMe3nbKVE/eLfHy9bqEZfSWX1dn3seYMdRITBCYNOsz3PQEmaxFFxD VQ5W7Z1zx6+7sR3mfYj/grRgY+fkaTox56gAw2v0cclBF5+sH5UGIzdt/C3piBwSTrF/XN a+Xbtb4t1cL/SHu6PZDfQUK+YzilYJ8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718328771; a=rsa-sha256; cv=none; b=WBo4iLubPkxbTW+k4FYcc4du5btdyIKovnqODJFip7zpZ6gPxcJ9xyE+4ewY9/4FthrKgQ Zlr8u9nhXuld+PUG6M2M5RvwBSP0FkYaDu3gs/5gSyAEb4bTKqgOGbYj5L99THe41wpMQm +9zReaWNfL4s58SX3xvWqnHdu3ZH4aQ= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WkM+nJRZ; spf=pass (imf05.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.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=1718328772; 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=MomHJJ0WTXAcFGOMzH8XSlE6O618dhh1qz/zUs8NtfM=; b=WkM+nJRZ9KSoAqaxZ7hKqUSNnRZ8qjYR4zRsDWC7H8BbLv6RQ8oI55rFxhMeGIp+1s73nz 2u86JR5skkE6SLwYs1MBf6sBwU55jWre2gwQZpGOeFC4rFccH6XSchRr8QF3KIy7pA1bKP uVIdIpkJTi5B2Nxffx+bmMSAODvM2W4= 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-355-bUZTF0aLM8u8t2Wkb7qMSw-1; Thu, 13 Jun 2024 21:32:50 -0400 X-MC-Unique: bUZTF0aLM8u8t2Wkb7qMSw-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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 3A320195608C; Fri, 14 Jun 2024 01:32:48 +0000 (UTC) Received: from localhost (unknown [10.72.112.37]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2E6FC3000219; Fri, 14 Jun 2024 01:32:45 +0000 (UTC) Date: Fri, 14 Jun 2024 09:32:41 +0800 From: Baoquan He To: Uladzislau Rezki Cc: Zhaoyang Huang , "zhaoyang.huang" , Andrew Morton , Christoph Hellwig , Lorenzo Stoakes , Thomas Gleixner , hailong liu , 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> 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.4.1 on 10.30.177.4 X-Stat-Signature: 8816beq6dk6xukk8a7o7nw1hju3mfox9 X-Rspamd-Queue-Id: 253F710000C X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1718328772-829074 X-HE-Meta: U2FsdGVkX1/dLPNz7k5Q4QkpNJ4+oHVV9JdxKUIkur2zSFnO2iJKFLWA51nUPazwbj+JU3budhuqsSnlk4Gy3592niZDpqiSqgUX2wlMY7rE87TO9NTP1f5vzvteRJIyl0N8eypzFTj0xJZ3odniGPH4r74LYO2s1ogifTkF0nwIPLWmCRP+d5eO2ytyel2/311y1BM9g2OBdRtsTlB4bIDrBMD9o4V/mR4uKZiSyiPvuHwncDPyRCgLxsJcpPWALQC4YD8myK0LWt0/5hhxLeNdrTMcU8FxCeaThQoUzxCKbpOblCG8NEZlP3FiwipJQKJnxI0kDQSMljkPdXpJlUpBRPl/qKcwt2LTCZkFbx8WTOyMZIPUH9Z0r2f6LuhRZdWTH6U/kPyW7Otu+KhHOmFz/lO4W4xcwtg6D7Yd2N5lpDli1L0wjNPBEY2PgB+lNgvoi+Q45e4YexkZMr+KFJ6CcaNac2eQQdRagOi3GLEa0QoXxHOqGtF/x+Ploasljme5kzB5BRjGTP6C48qE9HjoWFTtACWMiUTzrjZBYsNCDyqQJ54irZu0dH1BAptPavHqG0j2I3XUOXAV1liEJ0Rs1XF61rJPmtWg9oBtP26k2QTzFD9BWxO6B/WA1QgAaqwe1+qx0m3/u9W1hWzApVd3XjJQRtbfky9FisdcSw0rp5JiTv6t14zL1/R5JvfgBeHLFakReWc6fyq/SbFn1VPQc+63mJhOUFqi3p1BzXYl5KCgrLKXFDa57Qp7LFEVIFhF21lAg6Rcd0NugvvluzxPS0YIrUfySLyZtHR2F/W5l0i2qq+jUfE4Ezt+c6cJRFaM47o8sg21RAexpO9rgmJZdPc70Cyo8TOYwgfogs1oso985/amOLIDShUCFYRzL/Ixzgxgb+5vUt6MZ91QZlSok1CPMHX4RMiEIMknPvA6sVtya0nDYhlLYBWaamc3nsyMbFCxmQC0HnysOSv 2HtnNbUT mWKOHD9Vh0JZn2U5y01XFMyNbhenvpmeHDA4K5n2RWINaGne4RnZr0IbxendI1t57lp3MygD1buR0eAcV4LVKd5xU49PAVwraGCBLJswmobA/Snx4Jr+R/QGaLY+sKN0bY1uicuhgiosUnSOrUc58jlmOnu6VEkFiDWQc4n+vW8s9YHHJTe1+TckFYnb8ZXcPUEIZbFwk1NDCKpskyGo/YTB3v55XFriZjJwSob5mYjtvkFkw11vGrBY4obN8xFJzKvDWZ6psEiWY9q2b2HuFW/P6eMWPXAgMIwoyg/2tL91rg3bh2wySyBRveBs59rf5tcdCGqLRiM5R/bDqab7inMlI4EaLNF585bbjxFzn3SOmHGcYFF58MZPkWSnmIciuPDJ4BBUiVxd1aa+CDE+Bw6O9CgsXH9nLvBeB7QKqhN1gfjHqnLxI3DzFMDZx6Z2Jky2wofGVQ3CIhEA= 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 06/13/24 at 01:28pm, Uladzislau Rezki wrote: > On Thu, Jun 13, 2024 at 04:41:34PM +0800, 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. > > > Like explained below in this email-thread: > > vb_alloc() inserts a new block _not_ on this CPU. This CPU tries to > allocate one more time and its free_list is empty(because on a prev. > step a block has been inserted into another CPU-block-queue), thus > it allocates a new block one more time and which is inserted most > likely on a next zone/CPU. And so on. Thanks for detailed explanation, got it now. It's a pity we can't unify the xa and the list into one vbq structure based on one principal. > > See: > > > ... > rcu_read_lock(); > vbq = raw_cpu_ptr(&vmap_block_queue); <- Here it is correctly accessing this CPU > list_for_each_entry_rcu(vb, &vbq->free, free_list) { > unsigned long pages_off; > ... > > > > ... > vbq = addr_to_vbq(va->va_start); <- Here we insert based on hashing, i.e. not to this CPU-block-queue > spin_lock(&vbq->lock); > list_add_tail_rcu(&vb->free_list, &vbq->free); > spin_unlock(&vbq->lock); > ... > > > Thanks! > > -- > Uladzislau Rezki >