From patchwork Tue Jul 16 07:39:29 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Zhijian Li (Fujitsu)" X-Patchwork-Id: 13734074 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 2C9FDC3DA49 for ; Tue, 16 Jul 2024 07:39:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9A1F6B0093; Tue, 16 Jul 2024 03:39:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B23516B0095; Tue, 16 Jul 2024 03:39:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C3F16B0096; Tue, 16 Jul 2024 03:39:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7D8906B0093 for ; Tue, 16 Jul 2024 03:39:55 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F29DC140422 for ; Tue, 16 Jul 2024 07:39:54 +0000 (UTC) X-FDA: 82344816708.22.2201F72 Received: from esa9.hc1455-7.c3s2.iphmx.com (esa9.hc1455-7.c3s2.iphmx.com [139.138.36.223]) by imf20.hostedemail.com (Postfix) with ESMTP id 8E4E21C002E for ; Tue, 16 Jul 2024 07:39:52 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=fujitsu.com header.s=fj2 header.b=OhLdT0IN; dmarc=pass (policy=reject) header.from=fujitsu.com; spf=pass (imf20.hostedemail.com: domain of lizhijian@fujitsu.com designates 139.138.36.223 as permitted sender) smtp.mailfrom=lizhijian@fujitsu.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721115564; a=rsa-sha256; cv=none; b=hhqB37Z5z2C/M3xO9y44d6+k87LXw8Gfp9bLrXCXqFn/UruYRHUFZVDu2YPhZJJmFV2YEj kPyWQHbAvE59RCN3Q2RBOluTf2C51zP0rdkoHJOEZywD0i00q0HXDkqdw71puvwrWUY6xO NQeThFre1NAeBzSNCSi89EBlsmC06qw= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=fujitsu.com header.s=fj2 header.b=OhLdT0IN; dmarc=pass (policy=reject) header.from=fujitsu.com; spf=pass (imf20.hostedemail.com: domain of lizhijian@fujitsu.com designates 139.138.36.223 as permitted sender) smtp.mailfrom=lizhijian@fujitsu.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721115564; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=oShLlvQLyHtbaw9SXeEYC/8krQnAs8ZSbhsn3wok9TQ=; b=FeKExymUM4HTYz1JNHnsA0LDE51+dlHRi2Xi+SuUPD7xrJxh+vAkStwFesmUDPPQxhdOuH J631HEhWcsrMAZUorSid6m7q17su1RLpZ3kcTxavVq5RVUz687MGTENsVthvHzpxcjJAWs 3nOsR4HpKHw2QIc0e67y23pKiE0Zyu0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fujitsu.com; i=@fujitsu.com; q=dns/txt; s=fj2; t=1721115592; x=1752651592; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=s+9Rl57a7W4/9RlX3hiG87VGeDH/NTrRc8NssiUoEwg=; b=OhLdT0INykwMV4fUjPOYXTVfmVXNPhG1D+vd3eCtS5yBEWt5BZD81TXg hrqcGqJW2+xBEQEV0TQwcHWIWXVd/8g40b74W5/cHnZlMUTbZp0ekOQHW MjXCkSpaLDZlI/FrqGOkkHdtMawU9JflU0Q7RRKe55f1h0sBrVQvMuDEd Bh6zDszBhk2/iLIflmo18PPQJGqMSimlX0VDojYVJly7LUOapyIGaEIlI zweR9rVjLL+4wBwhwiVsyeZ+y/8SpkTC2af1bALA6TY7R76LB7XAW6Y4N pNsrr4RDr9PjLUZG3diCYbIYIViQH5p+OurcaGsPPQnem06vkEVx1LsPE g==; X-IronPort-AV: E=McAfee;i="6700,10204,11134"; a="155647706" X-IronPort-AV: E=Sophos;i="6.09,211,1716217200"; d="scan'208";a="155647706" Received: from unknown (HELO yto-r4.gw.nic.fujitsu.com) ([218.44.52.220]) by esa9.hc1455-7.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jul 2024 16:39:50 +0900 Received: from yto-m4.gw.nic.fujitsu.com (yto-nat-yto-m4.gw.nic.fujitsu.com [192.168.83.67]) by yto-r4.gw.nic.fujitsu.com (Postfix) with ESMTP id 1DFAA16B90C for ; Tue, 16 Jul 2024 16:39:48 +0900 (JST) Received: from kws-ab4.gw.nic.fujitsu.com (kws-ab4.gw.nic.fujitsu.com [192.51.206.22]) by yto-m4.gw.nic.fujitsu.com (Postfix) with ESMTP id 59D93D5078 for ; Tue, 16 Jul 2024 16:39:47 +0900 (JST) Received: from edo.cn.fujitsu.com (edo.cn.fujitsu.com [10.167.33.5]) by kws-ab4.gw.nic.fujitsu.com (Postfix) with ESMTP id C0B31E559B for ; Tue, 16 Jul 2024 16:39:46 +0900 (JST) Received: from localhost.localdomain (unknown [10.167.226.45]) by edo.cn.fujitsu.com (Postfix) with ESMTP id 1AD4C1A000A; Tue, 16 Jul 2024 15:39:46 +0800 (CST) From: Li Zhijian To: linux-mm@kvack.org Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Yasunori Gotou , Li Zhijian , David Hildenbrand , Yao Xingtao Subject: [PATCH RFC] mm/page_alloc: Fix pcp->count race between drain_pages_zone() vs __rmqueue_pcplist() Date: Tue, 16 Jul 2024 15:39:29 +0800 Message-Id: <20240716073929.843277-1-lizhijian@fujitsu.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSS-9.1.0.1417-9.0.0.1002-28532.005 X-TM-AS-User-Approved-Sender: Yes X-TMASE-Version: IMSS-9.1.0.1417-9.0.1002-28532.005 X-TMASE-Result: 10--4.198100-10.000000 X-TMASE-MatchedRID: B4VcMIpPJ83oSitJVour/QuB7zdAMUjAl9q75JzWJRMarX6LchMkVuBw lzWEEXt2fatVQLA534yNMkq6FfSn6lnGEjlsas2yFDuTLTe6zcNMkOX0UoduuV7V7de6UnlgmKb hu5KaCkf9F5gpB/8TUo2MogdbmQhJWSEm/dnndoSdVNZaI2n6//SzAdIVxUnokMdDYxplfPi/BR 68O365bhgeO7R/+wS3W8g/f7Yw4FCHx1sV2zgpgc36paW7ZnForzl8sNiWClKbKItl61J/yZ+in TK0bC9eKrauXd3MZDX9avo0zESw3V6aooxRi5dzqF0CXPWkCBugC5BwAq72xrV3O7TAoGSkLz9R mHSjoMlpgPDAjKIRuK/vz2MGbG5zjnaxM7NpKpE1f8nIp20B8BXFEH92Kf64nTtPxlIuIBW9Hzj 86YHXBCnifx5AGfCL X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-Rspamd-Queue-Id: 8E4E21C002E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 9b1eisrtqojoyh8tqch3qkunrm7w8f4p X-HE-Tag: 1721115592-335637 X-HE-Meta: U2FsdGVkX18MtYghsW0tzUuKJC+qoLIQU/LkR3SFJpeNx1i8kAB/iGjDSjL96irAMTySZyBDpBI0UgTWpDzB+ffw7za8bhIyCkOIfrzhW23hXDMRljomONo7oxz60urFXAik08LwVzvJckquRWy4pi0gDKzXgW6ccVkL3BJTJNjTiQlB4lc6zsoeDS2OmGODYvIDoB4PRTGoBakeYCbnuECPSpLE0WiqKZKXZF9wjLwF12jG1SkkiVAKVxixGtB8antfIY6J9d8kxI1wVq4yRYcw8Y33PsW3YTeiuFArm80AYNXLWuQJN7ElboYXZrbmxe3aihf8E3N3ZGrsG3IyVZOir8Bgp1urSAzPOCQk4jRY/pt2Yz1DAEqoNNTSUYEKyFYvfYEeJwcDKOyfeZtkB9kcVDARUPe6M2qsmxljLxGGtvm22yM/hQFIepp7O7DroeYDaJPODLtoF/yTrzTz3eVOwWvQAagURYSdqfuxwKi/sQJqng47yBAo2z3wPrl/92mb0QqDRbS52I7uVGORxvRrlRoL2b+W54cRkmf2n6AjPcqwoEnt7b8M9uDLscdy4HR/YcxdMTuoBo02DYdBvBz6vWl//5UJEsGdCZyfNPkr40dPITeio+3GsX1yN3MiMwJqDFwaSdiAkiozsLslde3q3CMjae/xqvgHo88YLqvN1SnsSXs6ctncGY0cxDEy98qqY/d25coerdcDotqFNSYIIRrntxc7muZbIVLsMmDAt6bU0ApFrmyiS2FMij51qEeZF9H2cYCqhV3HuDQh/p0l+xYrVvGMWwsSd11vAHOV1K2z7t4MyQzxemjkQEP/HDZcKUL61USWbqb9F9Pf+ZHCol9u8OugHMkEGCcEvfSOcGaoovGpXQQVgfHaTlt40HYrf38LW2M/LjMwjhEYi9MuNnalBVfqhW2MpSOb8bFfsf6blU2otFnOvHLGcksF1t204NuWpdMotjyQOqq XE0GyLjD ivMrWVPvXORBZc+huNWeS29I3oQJNWYPWjuz+Wt8bGPgT6oLGtqdEWdg/1SjSU7USrmJgY1Wr2N2aVbg4Aad5qY82CRLxDQLC27oTseKnko0wHbfsF6AUzO4oqIEqkPZP9pOZ3HyCKgahp/n2fG3ovUFh6ftM8en0c/p3TzgEraypO2/VjR2+jBO15ECgKL4hpXuvTAE+wr9vz7QHqJLQGh7tPLW+Os55nI0a9mCwFbBf2xCLKcETfFS8jWawaI2xJNLNbnD8hM3+ZNOQfUk/XbarD0cvkqt9Wuq3FYyeNdyceQHOPiIho/5olPRWpYV9tXYvlNYhCQsK00GT0lwI7FzfhvKYpbdd394DBhhO6vLP6t70jk8v//sYUg== 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: It's expected that no page should be left in pcp_list after calling zone_pcp_disable() in offline_pages(). Previously, it's observed that offline_pages() gets stuck [1] due to some pages remaining in pcp_list. Cause: There is a race condition between drain_pages_zone() and __rmqueue_pcplist() involving the pcp->count variable. See below scenario: CPU0 CPU1 ---------------- --------------- spin_lock(&pcp->lock); __rmqueue_pcplist() { zone_pcp_disable() { /* list is empty */ if (list_empty(list)) { /* add pages to pcp_list */ alloced = rmqueue_bulk() mutex_lock(&pcp_batch_high_lock) ... __drain_all_pages() { drain_pages_zone() { /* read pcp->count, it's 0 here */ count = READ_ONCE(pcp->count) /* 0 means nothing to drain */ /* update pcp->count */ pcp->count += alloced << order; ... ... spin_unlock(&pcp->lock); In this case, after calling zone_pcp_disable() though, there are still some pages in pcp_list. And these pages in pcp_list are neither movable nor isolated, offline_pages() gets stuck as a result. Solution: Expand the scope of the pcp->lock to also protect pcp->count in drain_pages_zone(), ensuring no pages are left in the pcp list. [1] https://lore.kernel.org/linux-mm/6a07125f-e720-404c-b2f9-e55f3f166e85@fujitsu.com/ Cc: David Hildenbrand Reported-by: Yao Xingtao Signed-off-by: Li Zhijian --- mm/page_alloc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 9ecf99190ea2..1780df31d5f5 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2323,16 +2323,17 @@ void drain_zone_pages(struct zone *zone, struct per_cpu_pages *pcp) static void drain_pages_zone(unsigned int cpu, struct zone *zone) { struct per_cpu_pages *pcp = per_cpu_ptr(zone->per_cpu_pageset, cpu); - int count = READ_ONCE(pcp->count); + int count; + spin_lock(&pcp->lock); + count = pcp->count; while (count) { int to_drain = min(count, pcp->batch << CONFIG_PCP_BATCH_SCALE_MAX); count -= to_drain; - spin_lock(&pcp->lock); free_pcppages_bulk(zone, to_drain, pcp, 0); - spin_unlock(&pcp->lock); } + spin_unlock(&pcp->lock); } /*