Received: by 10.213.65.68 with SMTP id h4csp1389382imn; Wed, 14 Mar 2018 20:09:28 -0700 (PDT) X-Google-Smtp-Source: AG47ELsnv7O1QGAduWiivvrP9V2SqukrwnCrvv7eAUEqeFhp7E6j4BGJFtSGnZuOcQaV5dipTx1N X-Received: by 2002:a17:902:76c9:: with SMTP id j9-v6mr6340448plt.250.1521083368482; Wed, 14 Mar 2018 20:09:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521083368; cv=none; d=google.com; s=arc-20160816; b=0nRjcVt9r+TiVcIN8I+K2a1UjCxKay6yFdLOMvBmZVqhKHF0fyYTnyGbrLQzOLSXfO +e85xacNo17kZpFMn6iw83XQCqsSNOUazeEO5Hcf7/csE9o968mC+KhNpZgW/JWIBkzT usH8y+3ecR7NkeL9raBnWYU709vpGKdN34AL8x69ydObo/45tpXEu/C+J5zvVSsrEZ0O 1Oi3gEZMELHnVrwPZJtCYsY9gZMueY5krvdy822QWW7wFUkI3LQyiji8tjC8Lia7waxo WyyCxuL7N/GRwnpgqwJiConW2ydiindzsRoyWFR9yyd/ArdLnkhnEpyPVvOnziQEWAPr 2aKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=FtReWql0KSd3BExj0GRZagiSSC1Y9dbYnFuihH8OPso=; b=XV5+YmDnCu0m2QxbXpqeSg0PPi/NxoJVaB6Qb7mZTBpJzWADjlafIN3ZT+xUhNfNYs CgrOVVZYv6stxQVR27VPoH+WrWCZAeUt2C+iDRHf2CCkHiC1VT1+WAv9pFUvSgnSHHYM edwcNl6TxXmVgAKhK39pzuszV02LXBq7qY5aaYRFbIy2zeg6B4VVQRtmMrumCoNLEF8z CkrF6GbX5kHYT2f6KrrpuOnoPlxNmKH1L6S+EJwKH5Bh5I6TqjQZShD/z7xUqQok5mTS siUIwN263TWbC3wOBAQiYpuOMMOyoXnAGg5PBuU257+jCt0jQfDkJkry8p8MFZXiIpTC n8ow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d18si2807353pgo.209.2018.03.14.20.09.13; Wed, 14 Mar 2018 20:09:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751985AbeCODIT (ORCPT + 99 others); Wed, 14 Mar 2018 23:08:19 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:59660 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751682AbeCODIR (ORCPT ); Wed, 14 Mar 2018 23:08:17 -0400 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="37834776" Received: from bogon (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 15 Mar 2018 11:08:15 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (unknown [10.167.33.83]) by cn.fujitsu.com (Postfix) with ESMTP id C5229486A78C; Thu, 15 Mar 2018 11:08:13 +0800 (CST) Received: from localhost.localdomain (10.167.226.106) by G08CNEXCHPEKD02.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 15 Mar 2018 11:08:13 +0800 From: Dou Liyang To: , CC: , , , , , , , Dou Liyang Subject: [RFC PATCH v2] ACPI / processor: Fix possible CPUs map Date: Thu, 15 Mar 2018 11:07:56 +0800 Message-ID: <20180315030756.5548-1-douly.fnst@cn.fujitsu.com> X-Mailer: git-send-email 2.14.3 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: C5229486A78C.AF723 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com X-Spam-Status: No Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rafael J told me in order for the ACPI-based physical CPU hotplug to work, there have to be objects in the ACPI namespace corresponding to all of the processors in question. If they are not present, there is no way to signal insertion and eject the processors safely. But, Kernel calculates the possible CPU count from the number of Local APIC entries in ACPI MADT. It doesn't consider with the ACPI namespace and reports unrealistically high numbers. And kernel allocates resources according to num_possible_cpus(), such as vectors, that may cause vector space exhaustion and even bugs. Depth-first search the namespace tree, check and collect the correct CPUs and update the possible map. Signed-off-by: Dou Liyang --- Changelog v1 --> v2: -Optimize the code by Andy Shevchenko's suggestion -modify the changelog drivers/acpi/acpi_processor.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c index 449d86d39965..ac45380f4439 100644 --- a/drivers/acpi/acpi_processor.c +++ b/drivers/acpi/acpi_processor.c @@ -671,6 +671,24 @@ static acpi_status __init acpi_processor_ids_walk(acpi_handle handle, } +static void __init acpi_update_possible_map(void) +{ + unsigned int cpu; + + if (nr_unique_ids >= nr_cpu_ids) + return; + + /* Don't yet figure out if it's superfluous */ + if (nr_unique_ids >= cpumask_last(cpu_possible_mask)) + return; + + for_each_cpu_wrap(cpu, cpu_possible_mask, nr_unique_ids) + set_cpu_possible(cpu, false); + + nr_cpu_ids = nr_unique_ids; + pr_info("Allowing %d possible CPUs\n", nr_cpu_ids); +} + static void __init acpi_processor_check_duplicates(void) { /* check the correctness for all processors in ACPI namespace */ @@ -680,6 +698,9 @@ static void __init acpi_processor_check_duplicates(void) NULL, NULL, NULL); acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID, acpi_processor_ids_walk, NULL, NULL); + + /* make possible CPU count more realistic */ + acpi_update_possible_map(); } bool acpi_duplicate_processor_id(int proc_id) -- 2.14.3