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 AAD16D0BB58 for ; Thu, 24 Oct 2024 03:29:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 448BF6B007B; Wed, 23 Oct 2024 23:29:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F90D6B0082; Wed, 23 Oct 2024 23:29:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E8226B0083; Wed, 23 Oct 2024 23:29:28 -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 1084C6B007B for ; Wed, 23 Oct 2024 23:29:28 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BA1574106B for ; Thu, 24 Oct 2024 03:29:17 +0000 (UTC) X-FDA: 82707065028.23.92837F8 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) by imf05.hostedemail.com (Postfix) with ESMTP id B57A4100023 for ; Thu, 24 Oct 2024 03:28:50 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AMtEWbyL; spf=pass (imf05.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.19 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729740362; 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: references:dkim-signature; bh=83ORe4qDNMLEXhhE1FQhgcpTromjbLiSZGnUHXvxfn4=; b=KocFRFc3hsvrmeZna879O0amb8o92CLSnKO38ksygjj5sW8u7AuhnSHOBroNa5mJRGOZgP 4DzNX5UKSXHR4yriXzmBvQv/iruYQQIL65xoxRxRzUwXyRewSdYPJCA9fRT+2ELmyTTB/8 z82ifbcunQ9QpVw6s3/YRzhCCSXGhKM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=AMtEWbyL; spf=pass (imf05.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.19 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729740362; a=rsa-sha256; cv=none; b=Mp0SbJFcm2n1AfmHlZyG0hgUeD8F+5SW9SJRImCk8pM17b8NYU6kpHl9t2OoM7cTNtqLNy FvttNRj/MrFZ2gQ/DQyB8R+B/Wbm3p2m+PLUh6Dq7mw4kBTyU5PQpapusYey2jcWGmRLUV 7Mb5qRdye6xwbMm+8nSdsHau039lXak= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729740565; x=1761276565; h=from:to:cc:subject:date:message-id:mime-version; bh=QU4btWGp+ybFpDP2V1GDqqieqNvTSNq3QDsNnQYvGXQ=; b=AMtEWbyLaWOmSEwFmC6w31VrkduO2+Nfo18vyBbk9xQb2i9CuJVkVOUe 5TGSK24/nx05/x2iX+nwoQ2d1Iz/0yT2dcI2HsCLnN1APr3QS9ECnK2ps Kf8eIDGNk1Ce4mCPrDG5rm21WmO+V4DHKRDtixylNJuAPZSFsMn5iizCp gzMgBEE4z9yVptsUKvVV6B9zhTvqTQiPCzjX8TsHyOmuF09f2xdhpLm/v ygWoU+81O/DXHIGCOPMakbHIbpENvZcEb8Ez1QCUve4I8xRk9v/98z1wq syu/0cfkrmXjnoJ4fdzkPSpIJBwsNuAqzeFI117OGWFau1BiP37YFdmGO g==; X-CSE-ConnectionGUID: xUtYSzsvQ+i5X/ih9ZImoQ== X-CSE-MsgGUID: JfaUCJFpQQmhXqMnjmZ4wg== X-IronPort-AV: E=McAfee;i="6700,10204,11234"; a="28816635" X-IronPort-AV: E=Sophos;i="6.11,228,1725346800"; d="scan'208";a="28816635" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Oct 2024 20:29:24 -0700 X-CSE-ConnectionGUID: P+4uxURGQ4qurNcALx6uxA== X-CSE-MsgGUID: bD9VTUuHSgW3s9dzpUbPzw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,228,1725346800"; d="scan'208";a="85067472" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Oct 2024 20:29:22 -0700 From: "Huang, Ying" To: Kairui Song Cc: linux-mm Subject: cluster_alloc_swap_entry() may change per-cpu cluster of another CPU randomly Date: Thu, 24 Oct 2024 11:25:50 +0800 Message-ID: <871q0641xd.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B57A4100023 X-Stat-Signature: dzi7a6xrcydkwak84a374igq6zj9594x X-Rspam-User: X-HE-Tag: 1729740530-377570 X-HE-Meta: U2FsdGVkX1/VsUlWVvKBsTwvTtT82LyyLpQwsaBIDDNfTBcYif5YZ9Zw7IJjMKoL1KdUMRrv2vnOHWhJX9K41ykr23tRGleuwE8ZiQjBXeJ1Aktbx9ejfAInzCcbVSkuZ7wsH8DK2TxOTFSQtun2k9jNjQcFYW97v89dztEX9HXek16JPYThGXvn3xSO6UMQ3WveuqcUGoDNUvuo9mpzCdYkqnubOhqY7FSQoa1d6VCwY7RExRGLFrr2vm+xk+xHMS2xVGFrBkaur+zlAsAI0nzYT6l3lPJOYZk47jr845FinoCZBi9eX/LJAriwRjTs8TEjLMkCBR0cqQeg3PGRDtA6lU4RHzr9k94Ej5e31/NZ8hDNrKP4LH7i2hBijAoB/u6tPHBoiO1MsxGWTupUCefeoxU33fJghZafP7EJfipYidXeGydnCVwpVaLd41YNrOE1GxdGbW/cLp2VIUtCmx+5hCnp0ajCL7l9UillsSDOyxjH6z/H64ihFNwOPp0E/dDdYiFG+8SJ4AAFZgsZHOA5JpWZQ+soX0PlyIY0z398/4U4LJKviltoNmSPympYmmaZ1Seb3nLaQomy7R9Tm2zyXfaVLgWhktzs64MWiYqNfylwtnEBDHmX8ZDa6tNtxVdgN6iTbZx+VALIL1Y8TNYUzWz1A0tQ6N8SLF08Xu9vZbQjG95/hU820aY5k5igbvQHRT4vmilKIhaDG8zibpANeiP4TkxsuWmPWbOeAFIdxiMz2fKjV4FJ182aiZVA3uM+Nt6pzc0ZO8zfCDW4bEhm87EYxE1ot+4TWzYYTYMmb2PRBTqly2xq8VKEtZQaxDsenm0waz9VplPqytNfp2R/+wf77/2F5s4yLXTvkU6+4XwSOKjahi3iTcN5P/KCaF1EcXp7U9JHxcjUXF/7Mnx7gxJf6+V2Onp0poZHL0naO4GRdySAqkZmVsGgASWyJ4PMf+1zSHO1B8d2SZD xyBT+1nW FFhmWXGsftfIg3WObecvr0nZY/f/a45byqhRB4gxz1RtwY+W19Fhvd7iKMPgi1jZ7JkwgHGt9FsUsRAUdel7Qf1at6RIEmq5XbZZpBzp78rRGfBAO/N6oceYR0z+a7hfc2Cr+VFlyn9rTLCbeazjuQRfe92l1MmR6lT677ARcFPD/UxkgW6MMR542ru48Xs7gxfYDw39X6kpANfUn3DFoH6+26Mp8bHp0gzH3l/InDcxPCMc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.008453, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, Kairui, When reading new swap cluster allocation code. Sorry, I didn't find time to review your patch at the first place. I found that in cluster_alloc_swap_entry(), the following code path is possible, cluster = this_cpu_ptr(si->percpu_cluster); offset = alloc_swap_scan_cluster(); ... spin_unlock(&ci->lock); spin_unlock(&si->lock); /* migrate to another cpu */ spin_lock(&ci->lock); spin_lock(&si->lock); cluster->next[order] = offset; That is, the per cpu cluster of a CPU may be changed on another CPU. I guess that this will not cause some functionality issue. However, this makes code harder to be reasoned. Is it possible to avoid unlock before changing per cpu cluster? Or, give up updating per cpu cluster if we need to unlock. -- Best Regards, Huang, Ying