Thread (36 messages) 36 messages, 2 authors, 2016-08-31

[PATCH v7 05/14] arm64/numa: avoid inconsistent information to be printed

From: Will Deacon <hidden>
Date: 2016-08-26 12:47:47
Also in: linux-devicetree, lkml

On Wed, Aug 24, 2016 at 03:44:44PM +0800, Zhen Lei wrote:
quoted hunk ↗ jump to hunk
numa_init(of_numa_init) may returned error because of numa configuration
error. So "No NUMA configuration found" is inaccurate. In fact, specific
configuration error information should be immediately printed by the
testing branch.

Signed-off-by: Zhen Lei <redacted>
---
 arch/arm64/mm/numa.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 5bb15ea..d97c6e2 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -335,8 +335,10 @@ static int __init numa_init(int (*init_func)(void))
 	if (ret < 0)
 		return ret;

-	if (nodes_empty(numa_nodes_parsed))
+	if (nodes_empty(numa_nodes_parsed)) {
+		pr_info("No NUMA configuration found\n");
 		return -EINVAL;
Hmm, but dummy_numa_init calls node_set(nid, numa_nodes_parsed) for a
completely artificial setup, created by adding all memblocks to node 0,
so this new message will be suppressed even though things really did go
wrong.

In that case, don't we want to print *something* (like we do today in
dummy_numa_init) but maybe not "No NUMA configuration found"? What
exactly do you find inaccurate about the current message?

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help