All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, "Huang, Ying" <ying.huang@intel.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Zi Yan <ziy@nvidia.com>, Oscar Salvador <osalvador@suse.de>,
	Yang Shi <shy828301@gmail.com>,
	zhongjiang-ali <zhongjiang-ali@linux.alibaba.com>,
	Xunlei Pang <xlpang@linux.alibaba.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 5.17 11/12] mm,migrate: fix establishing demotion target
Date: Fri, 13 May 2022 16:24:11 +0200	[thread overview]
Message-ID: <20220513142228.985137985@linuxfoundation.org> (raw)
In-Reply-To: <20220513142228.651822943@linuxfoundation.org>

From: Huang Ying <ying.huang@intel.com>

commit fc89213a636c3735eb3386f10a34c082271b4192 upstream.

In commit ac16ec835314 ("mm: migrate: support multiple target nodes
demotion"), after the first demotion target node is found, we will
continue to check the next candidate obtained via find_next_best_node().
This is to find all demotion target nodes with same NUMA distance.  But
one side effect of find_next_best_node() is that the candidate node
returned will be set in "used" parameter, even if the candidate node isn't
passed in the following NUMA distance checking, the candidate node will
not be used as demotion target node for the following nodes.  For example,
for system as follows,

node distances:
node   0   1   2   3
  0:  10  21  17  28
  1:  21  10  28  17
  2:  17  28  10  28
  3:  28  17  28  10

when we establish demotion target node for node 0, in the first round node
2 is added to the demotion target node set.  Then in the second round,
node 3 is checked and failed because distance(0, 3) > distance(0, 2).  But
node 3 is set in "used" nodemask too.  When we establish demotion target
node for node 1, there is no available node.  This is wrong, node 3 should
be set as the demotion target of node 1.

To fix this, if the candidate node is failed to pass the distance
checking, it will be cleared in "used" nodemask.  So that it can be used
for the following node.

The bug can be reproduced and fixed with this patch on a 2 socket server
machine with DRAM and PMEM.

Link: https://lkml.kernel.org/r/20220128055940.1792614-1-ying.huang@intel.com
Fixes: ac16ec835314 ("mm: migrate: support multiple target nodes demotion")
Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Yang Shi <shy828301@gmail.com>
Cc: zhongjiang-ali <zhongjiang-ali@linux.alibaba.com>
Cc: Xunlei Pang <xlpang@linux.alibaba.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 mm/migrate.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -3085,18 +3085,21 @@ static int establish_migrate_target(int
 	if (best_distance != -1) {
 		val = node_distance(node, migration_target);
 		if (val > best_distance)
-			return NUMA_NO_NODE;
+			goto out_clear;
 	}
 
 	index = nd->nr;
 	if (WARN_ONCE(index >= DEMOTION_TARGET_NODES,
 		      "Exceeds maximum demotion target nodes\n"))
-		return NUMA_NO_NODE;
+		goto out_clear;
 
 	nd->nodes[index] = migration_target;
 	nd->nr++;
 
 	return migration_target;
+out_clear:
+	node_clear(migration_target, *used);
+	return NUMA_NO_NODE;
 }
 
 /*



  parent reply	other threads:[~2022-05-13 14:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13 14:24 [PATCH 5.17 00/12] 5.17.8-rc1 review Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 01/12] Bluetooth: Fix the creation of hdev->name Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 02/12] rfkill: uapi: fix RFKILL_IOCTL_MAX_SIZE ioctl request definition Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 03/12] udf: Avoid using stale lengthOfImpUse Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 04/12] mm: fix missing cache flush for all tail pages of compound page Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 05/12] mm: hugetlb: fix missing cache flush in copy_huge_page_from_user() Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 06/12] mm: hugetlb: fix missing cache flush in hugetlb_mcopy_atomic_pte() Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 07/12] mm: shmem: fix missing cache flush in shmem_mfill_atomic_pte() Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 08/12] mm: userfaultfd: fix missing cache flush in mcopy_atomic_pte() and __mcopy_atomic() Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 09/12] mm/hwpoison: fix error page recovered but reported "not recovered" Greg Kroah-Hartman
2022-05-13 14:24 ` [PATCH 5.17 10/12] mm/mlock: fix potential imbalanced rlimit ucounts adjustment Greg Kroah-Hartman
2022-05-13 14:24 ` Greg Kroah-Hartman [this message]
2022-05-13 14:24 ` [PATCH 5.17 12/12] mm: fix invalid page pointer returned with FOLL_PIN gups Greg Kroah-Hartman
2022-05-13 16:40 ` [PATCH 5.17 00/12] 5.17.8-rc1 review Jon Hunter
2022-05-13 20:35 ` Shuah Khan
2022-05-14  3:14 ` Ron Economos
2022-05-14  3:38 ` Florian Fainelli
2022-05-14  3:46 ` Naresh Kamboju
2022-05-14  6:12 ` Fenil Jain
2022-05-14  7:51 ` Fox Chen
2022-05-14 14:57 ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220513142228.985137985@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=osalvador@suse.de \
    --cc=shy828301@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=xlpang@linux.alibaba.com \
    --cc=ying.huang@intel.com \
    --cc=zhongjiang-ali@linux.alibaba.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.