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 1B9AAC7EE30 for ; Tue, 1 Jul 2025 11:42:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E5076B0092; Tue, 1 Jul 2025 07:42:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 995896B00A6; Tue, 1 Jul 2025 07:42:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D23F6B00A8; Tue, 1 Jul 2025 07:42:04 -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 79D406B0092 for ; Tue, 1 Jul 2025 07:42:04 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B888C1D6E02 for ; Tue, 1 Jul 2025 11:42:03 +0000 (UTC) X-FDA: 83615506926.23.DA5D951 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 1D1DEA000E for ; Tue, 1 Jul 2025 11:42:01 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NHIDwpZX; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of hare@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=hare@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751370122; 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=LaDVMcllYOv0nrH7d6LHQf+me9LeG1gAl4NEe4ViY4U=; b=cMx9EVSpCUUG2xb8/VZ/OzcrsnDpQmQfzwAHcShTXPDCROhuNt7yi1lF6MnsOFyfMl8wOB hKU+MKDILtO6mW2DQnyi3uiQxqXxgoVAu9ljMWGd/O52YdPRMNxWsRzz61eDvteQd415s3 +5s1pZZLrg45i3qml1MC62/e7V1LSLM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751370122; a=rsa-sha256; cv=none; b=Z2fnP/8Mzl/5GqPAbLUc4BTGZ9+qZdH8f1eFKd6zahXcpzfKd+EIUxZR6OcyiuhgBPLaq2 PVuWrT7rq+ZHKJZY13/XbZK2RXAI50wjvRFC0rAywTCct8K3s2BWCGEyYIHR9lcA0xCmtb hFCL9KTHY6FlyYiI0wsSZsBKVNfSLc4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NHIDwpZX; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of hare@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=hare@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1DBD25C5401; Tue, 1 Jul 2025 11:42:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B274BC4CEEB; Tue, 1 Jul 2025 11:41:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751370120; bh=NOldZAvfhzun+lcNhSHvzdXjWOibpLzXoyFb1TnKTAQ=; h=From:To:Cc:Subject:Date:From; b=NHIDwpZXp/6DGnDBZKfs6NnJSHhIsxAuDIS2Lj8Uc9s9YxOM8XPQkd5228wl06glw PlDEmpWeqH2LTr7mvb+pmXwWJOX0EbfOGo6D7dLcpsFV/YJTnxazM9M2wfcAQ98GHl YqA2c/II48oH3ujyBWN/Q8VmHUe2WOoDefUAF9EPt7y0tgXwpWpI0xsEjWLYLz2/rb 7CHymwOBAeFjOO+TeVtlR4bJQst62FPoSrzT//rWWaXUs7xEQ1GCGaGmNNGDN9ZUIo J4JHiPIXrtWN+Kj0fFfTkMCi3bBzTlTTY6QIdczo/KEyvO3jsjzXNpK6ls/sDUwxx2 CSi0Oj1YI5xrg== From: Hannes Reinecke To: David Hildenbrand Cc: Oscar Salvador , linux-mm@kvack.org, Hannes Reinecke Subject: [PATCH 0/2] mm/memory_hotplug: fixup crash during uevent handling Date: Tue, 1 Jul 2025 13:41:52 +0200 Message-ID: <20250701114155.16452-1-hare@kernel.org> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: 65yr9q5te3z6gqimg3dy3onez8tsypsy X-Rspamd-Queue-Id: 1D1DEA000E X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1751370121-617387 X-HE-Meta: U2FsdGVkX193FjHekKcTIXxjejbAoCURFdxge63nmwGJ5NIozNtGzpRgh0EP93v0ycJEo/uTh2P0dsMBuAId39RK+VkDp5OFQgANKeBhK6523l/cNcOAnxJLivjvCMr1NyOTCOEUdqsAHa2ELaPVngC6I2RGGjrRuYPSFBspCWQq8fXkO2RTmrAwpjCOxdhnC/tAogdYiO1127BVmH2n/aVNYrgjrTxOwwwks/79qm+dgFcnGuKLb8Lz09sNJohZYauR/hO6twfOauU8y3wyhYFkxaLm2f51MB9Z9au/N2KvTwlLM7ojvU+p+cfVNYprrzgbkC9lg3sFk+zzAWHEj3TYYAVN/6K5oSti2XFq0fFwlwaU2sc1IvMnw1REizMjZLZkLOD9Psvm0iFnrGrxAgtLe0m6B7si0jg9qZOzO9fSfsjb5WRJjlvsannem5fRby9HQ6obXWswx6Xkh6mIvcwQd6dyYBx/Fl6IPSkh1m7Ap1S0QXTsCmj0P87kWwt9OEfPPBXM1bfC2lBVexL4YtCrO4rmT8Cy4KAPI5LVaYqIth/lf9RxgubqMbE19XHTOnBdCbPktqovQvlxK4YbX5bHyLI9qR4Vaa2QUCdo+9zYkH8xNU0xBDzz1kzCOp+wbfGs+sx5AmUrW+4Khc7amiLpE4qzJwhIf7QMBOKRDh25StPQCzYsH+xcrzqOWu8n8pezkRH4A2Gv/0sBwXhq/mTU859pZ7/YzRb8cTiXkFK+RHawD4SEnuvLxrC+vGvjDwkevVxZKO3gQ6R2T0qfhqM685p/OOOLOpByVL9UhgN3uUuQBPqS6NJzsSWamEZ/W0Lj5xGzLUbKFG36VwCjanNw5t0cAd8KqpCXXE/+f+drEEwTdpaJH3KiRsjzA0+DQFB/PYxU4dOZ51G/leYY1JkYJJEMn+GLLM3jrmB8rR2AxeMOzdWZEf1tHQw0DvktRUBamDqzGD1HsOOVlvi OpjYT3Bf mARmspNLiMpTsDyRHRuLuKh4Wcu5XTsKZhXc5IZ5lvFGkXYsHxfIWhHFwYiacdveEX0CKy3sC133TWRI+kExiF/fKgK2eKom4xsJA33LXwF/b7N1Ajudl/AJiDSx7lvRZ53SQHu7nKQ57/Qq3GiQorRDWjjQ2kJVrF9hGKWIKxXAHOSg3l7cE0Wn7FU99+I7mJT5ffxUNh2CN1TKAOdvGz4bhM6u4UtJypfANMG4e0i/zISVnYg/rfm/6//FHQkNG/v/NQ7BulUENA/2T17ikzBPdexje2zurhW2g 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. Hannes Reinecke (2): drivers/base/memory: add node id parameter to add_memory_block() mm/memory_hotplug: activate node before adding new memory blocks drivers/base/memory.c | 32 ++++++++++++-------------------- include/linux/memory.h | 2 +- mm/memory_hotplug.c | 32 +++++++++++++++++--------------- 3 files changed, 30 insertions(+), 36 deletions(-) -- 2.43.0