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 C1316C7EE30 for ; Wed, 2 Jul 2025 07:39:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F1C98E0002; Wed, 2 Jul 2025 03:39:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 47A368E0001; Wed, 2 Jul 2025 03:39:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31B368E0002; Wed, 2 Jul 2025 03:39:25 -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 1B8C08E0001 for ; Wed, 2 Jul 2025 03:39:25 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A584A1D8880 for ; Wed, 2 Jul 2025 07:39:24 +0000 (UTC) X-FDA: 83618524248.12.16BC65C Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf29.hostedemail.com (Postfix) with ESMTP id 34750120006 for ; Wed, 2 Jul 2025 07:39:23 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=g3vpWWzw; spf=pass (imf29.hostedemail.com: domain of hare@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=hare@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751441963; 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=6Yy+f44KavbK/qUbzuJJK7UX7pQqhuH7cUMS6IpVjH8=; b=CgLASig0TBuugG+W1SEt557/AU1Iz+8WgXPM5+C0QlGFhOIOKYLn/zrwueNnLhcdkvNI+Y fS1BOfmRu84UbZUkqRihjVR7BcBdqmboQNocV7ge65U0ypJNHDxtUPPpS+O7L0qCtrwLoU NOypJ9XTNixOwF4LbOhkJC+dtUuge+0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=g3vpWWzw; spf=pass (imf29.hostedemail.com: domain of hare@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=hare@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751441963; a=rsa-sha256; cv=none; b=sdChhPLY9kmwm6iomVN5+GZDQjUrXka01iFFd52CknODge8ndDNeXBR+3GWXl3j4jl/MeN VOJimqgHbumzdRAoh4hEiSEAzQzhPSgoiSLDAcjY+Zwbu7Qmqsf1XoYn4QxJUsz3P0qIND bvc0N+wgzCd5UjBPZWUDoy6v2ENRxSw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 8896C6000A; Wed, 2 Jul 2025 07:39:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 167C8C4CEED; Wed, 2 Jul 2025 07:39:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751441962; bh=M+CLKfMtFrRANLDf617b3smqQStrK1OFmGuSKE7qk+8=; h=From:To:Cc:Subject:Date:From; b=g3vpWWzwOeWxNfx4FnDdNBEoiLXT9/4E5rP7gfnCGtRcbyh3pH49l11uUm3Bnwn2J m53ySw6NPGIJrslIbBaBL/kbvDTR9UWi8MpX3/YTEraiAwGP2ZYk8tfY3Qk4xZ2y8p WKcH4yRIULg8ze0Z281jolEYuqLZoANo5RonFdOIFOct6rVNQeDng3wfK62IpJypI3 Pb9GC1ACiONiQbUpz1LZj4ZTEZCg6j1R+Oxvjk0hYbCYpkByJ+YkoTe6oV45dZppIe FfyCp1fY+N4QJBXdrRYN+tt06+RebasStn6w6Upk8hMSvqoxVFaZTmHTWHoi1wq8gM 0vUrxsKs66VKA== From: Hannes Reinecke To: David Hildenbrand Cc: Oscar Salvador , linux-mm@kvack.org, Hannes Reinecke Subject: [PATCHv2 0/3] mm/memory_hotplug: fixup crash during uevent handling Date: Wed, 2 Jul 2025 09:39:10 +0200 Message-ID: <20250702073913.58247-1-hare@kernel.org> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 34750120006 X-Stat-Signature: e8mmnpstjs6xfosafusbx8kb7nrrykip X-HE-Tag: 1751441963-795678 X-HE-Meta: U2FsdGVkX1+GLFs3BvjfRnq7VXrg/IMKyxoaxmAcrZODqmijuco/TMWema++DJgklcQ7OVzPg6EKJ1O73duFOYQdjuzcv3G9qwAkzyGwlwtAAJzfUifmsbMnYg1DEqQWGj809WI0ZjShOJaG0cntHxgUVS4ET2yEETX67z/wcPEwf0k2Iw5xjtEsOKKHqNAujZwN3B4PAMuZOEumGCeGCJE+03ycy4inwPEWwyf3Mdl2xUrfsetMj577KFsMojbmL7a78WwR/x2ykxFjfhjzuVckJgFSy5OCIZuLn83DIse55pWtt12b9oL+1LXs1q/l0CCktifbGfq3xWJsqxycDycPhLl10fVPltNlPMdgFLrlqZVvHcJWz6jiaVyBQuFFiZsZqaYBEdVEnxs4JUtJKKXOOchFoX2e85siAiWyg8RTGIhFs7YhVDpNQNEagpIncx2Udgir5BEwe5eMR+2nQP3VWmK8hvxbcoEQ4VStTnaXpA5Rc9MzQso6ThekhM7vclg88dxzlQ7n6AvxVacSJLJmJbz+7HttLe+Abzl7lXV8tUPmQ+fPFyW+1eeHOcIptbtPGODxEWDS5xzRhP4kXB5CzTCrEm+rsJsX2DT9DTqfqI7/uMXzwHaXAJLbmP50GWva2UHiWu3OuFyLNbm/Okp9DMl8ILO/c7KUYNQSBbPZWk2RAgLm/NF0LtS53CbhAYp53Jg85Pp3mj5mJoV261JyLcwOD0useTZpZTmezt6xkkQ6VICalD3NWaFkvCYPIyc382RUAcLrJ1HvQhKsobKUiJkCw0OwsC55L1rkOEo/HPGFktV0edqdDWYTprjWU8tn8erIxTuoGRYb0t/TH7NC+4VRXA6VvizsO7U4ylK6EQrhjzN5MhFW6WETxi8FIPU99wqRlNP7d4rhS+BbEcjUzDHJI9Yq7E13w6QnU9qX0+kc2C5+1xscLeVaVJ2uCZ9L7asmfdDe5ybJMxH dEBGUgBR DMUAj8cK5eWUbXcTCrVaGdWWv7Ha84fpBXMoHee3MIkcIFopG9RDLkI7wtTq0or7sXnE0hV/q/MWTsVYOnEYj34egktsBbRySk1G2AdKDBtY4h66vdlDJjJHQVvenG1v5t6AxUxIhRSKYdZ67nVwjJ4fqe/1QF3fMwSfjrIxVPqFWsqcscpzSuDJnXnHRcVYNyQB4NudMb5Bi0VPzRe5PbMY/xo/24NIzT4/c+mZPBzjXZajUSEgwTbV/VbhlWBH98AEfltZwGN5iACwzGxHHeP6QDDMTwyWoZWMY 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: From: Hannes Reinecke Hi all, we have some udev rules trying to read the sysfs attribute 'valid_zones' during an memory 'add' event, causing a crash in zone_for_pfn_range(). Debugging found that mem->nid was set to NUMA_NO_NODE, which crashed in NODE_DATA(nid). Further analysis revealed that we're running into a race with udev event processing: add_memory_resource() has this function calls: 1) __try_online_node() 2) arch_add_memory() 3) create_memory_block_devices() -> calls device_register() -> memory 'add' event 4) node_set_online()/__register_one_node() -> calls device_register() -> node 'add' event 5) register_memory_blocks_under_node() -> sets mem->nid Which, to the uninitated, is ... weird ... Why do we try to online the node in 1), but only register the node in 4) _after_ we have created the memory blocks in 3) ? And why do we set the 'nid' value in 5), when the uevent (which might need to see the correct 'nid' value) is sent out in 3) ? There must be a reason, I'm sure ... So here's a small patchset to fixup uevent ordering. The first patch adds a 'nid' parameter to add_memory_blocks() (to avoid mem->nid being initialized with NUMA_NO_NODE), and the second patch reshuffles the code in add_memory_resource() to fully initialize the node prior to calling create_memory_block_devices() so that the node is valid at that time and uevent processing will see correct values in sysfs. As usual, comments and reviews are welcome. Changes to the original submission: - Add patch to rename memory_block_add_nid() - Add reviews Hannes Reinecke (3): drivers/base/memory: add node id parameter to add_memory_block() mm/memory_hotplug: activate node before adding new memory blocks drivers/base: move memory_block_add_nid() into the caller drivers/base/memory.c | 53 ++++++++++++++++++------------------------ drivers/base/node.c | 10 ++++---- include/linux/memory.h | 5 ++-- mm/memory_hotplug.c | 32 +++++++++++++------------ 4 files changed, 46 insertions(+), 54 deletions(-) -- 2.43.0