From patchwork Fri Feb 18 22:43:01 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oscar Salvador X-Patchwork-Id: 12751990 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 4A734C433EF for ; Fri, 18 Feb 2022 22:43:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EB4D6B0074; Fri, 18 Feb 2022 17:43:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 69A7F6B0075; Fri, 18 Feb 2022 17:43:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 562966B0078; Fri, 18 Feb 2022 17:43:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 463136B0074 for ; Fri, 18 Feb 2022 17:43:20 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E83A3181BDC9A for ; Fri, 18 Feb 2022 22:43:19 +0000 (UTC) X-FDA: 79157378118.22.55296BD Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf17.hostedemail.com (Postfix) with ESMTP id 4CD8240004 for ; Fri, 18 Feb 2022 22:43:19 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 1A03A210E2; Fri, 18 Feb 2022 22:43:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1645224197; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=MAAF1UrArLR3/kFKSC5XvKKA5dLaxWP8f2xQrIQUM6o=; b=WQkGpbwBk8jJmD6Ny45sTTKMcWh9pHcTfYCn5MS3AMp5JaSpUCRdAw+AGMarVTJvuzQLPO lm49jj6EOEJkxSpH/4Bx0UaDyuYxPIfDO0wtinhkvh8jFVI6UV5aPRCjZnEgj8eIiHYv7Q zqynSfPm27IVM2ohCn7MWgnvNK8K42s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1645224197; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=MAAF1UrArLR3/kFKSC5XvKKA5dLaxWP8f2xQrIQUM6o=; b=7+laXMoY04tlx5Jwv+Po738O0aJNT+0QwxjqGcw0N5HPkpHOGswsxyG7rWkSBr5g+/IYvI hO6HJzxv508wxSDQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4A85213CCE; Fri, 18 Feb 2022 22:43:16 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id P7X7DgQhEGKMQwAAMHmgww (envelope-from ); Fri, 18 Feb 2022 22:43:16 +0000 From: Oscar Salvador To: Andrew Morton Cc: David Hildenbrand , Rafael Aquini , Dave Hansen , Michal Hocko , Wei Yang , Dennis Zhou , Alexey Makhalov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador Subject: [PATCH 0/1] Fix allocating nodes twice on x86 Date: Fri, 18 Feb 2022 23:43:01 +0100 Message-Id: <20220218224302.5282-1-osalvador@suse.de> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4CD8240004 X-Stat-Signature: ztbfzpucq57z3j8mowzp31jhzhbtf1af Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=WQkGpbwB; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=7+laXMoY; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf17.hostedemail.com: domain of osalvador@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=osalvador@suse.de X-HE-Tag: 1645224199-159431 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: Hi, I was about to send this patch as a part of a cleanup patchset that goes on top of last Michal's work about properly init memoryless nodes [1], but I thought I may send it as a standalone one as it is the only real fix of that series. Discussing the fix with Michal, another concern came up, about whether memoryless-nodes but with CPUs should be marked as online at all. Here Michal and I have different opinions, while I think that memoryless-nodes with its CPUs online should be marked online, he thinks that the property 'online' applied to node has to do more with memory, and I have to confess that after having a look at some of the usages of for_each_online_node, most of them are checked to do something memory-realted afterwards, so I guess he has a point there. My main concern is that if memoryless-nodes do not get online, its sysfs showing the cpu<->numa topology will not be created and I am not sure about losing that information. E.g: i guess 'numactl -H' would not be able to show the right topolovy as it coul not walk sysfs to get it right (in case it does). Anyway, as a quick test, I wanted to see what happens if init_node_to_cpu() and init_gi_nodes(), do not online the nodes. (those nodes get online because of the CPU and Generic Initiator affinity). The outcome is that we blow up badly down the chain, and we do because of a nasty side-effect (more information can be found at the end of patch#1) Short-long story: by the time bringup_nonboot_cpus() gets called to bring up the cpus and bring up their respective nodes, we have not even registered the node_subsys bus yet, so bringup_nonboot_cpus()->..->__try_online_node->()register_one_node()->bus_add_device() will crash when dereferencing some of the bus' struct fields. We happen not to crash now, because init_to_cpu_node() and init_gi_nodes() mark the node online, and by doing that, it has the effect of __try_online_node() backing off and not calling register_one_node(). I think the whole thing is kinda broken, or at the very least subtle and fragile. I am willing to have a look at how we can make this optimal, but wanted to share with you. Anyway, It is getting late here, so I just wanted to 1) send this quick fix, 2) expose some nasty behavior and 3) kick off a discussion about how to improve this situation. [1] https://lore.kernel.org/lkml/20220127085305.20890-1-mhocko@kernel.org/ Oscar Salvador (1): arch/x86/mm/numa: Do not initialize nodes twice arch/x86/mm/numa.c | 15 ++------------- include/linux/mm.h | 1 - mm/page_alloc.c | 2 +- 3 files changed, 3 insertions(+), 15 deletions(-)