Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3065723imm; Thu, 17 May 2018 02:47:56 -0700 (PDT) X-Google-Smtp-Source: AB8JxZplR224Lsk0PDMmQrdqVzlwLBawrVd6HeuGCe/Xv0nh7GsEFfDMl0OqffAq75QWhueSUR4A X-Received: by 2002:a62:8d51:: with SMTP id z78-v6mr4516741pfd.69.1526550476845; Thu, 17 May 2018 02:47:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526550476; cv=none; d=google.com; s=arc-20160816; b=Kb+hlNb5qGFjDyRnuFjQ5OYD6ASHNCjKOJx6dpDS8FGGQTotv0WKSyFr/kMYeSWHHq nfo54alaStyRlAJFEr9V2LMBR/NjAhH0T2pAqr+WNLSAqgwYriCZojYfkBhgV+xlTlC1 Y45AKTBOyt2Q70Q3TVjselqTQtDfRWBvqq0Ojvg2y5m5tD1lT6tX0u6pI7/ylTDruKKw jgvV5hLUsrRSLwZFDqYePZ0Qi5emIAOo5DID6fVFJ/QalcQCuKO5WLxa9OEBKwcEyQYD 0dhuRB5FGWyAZYYzlH6wpOy7i0NkiIL6P/bSkEur/VyHC4TakaREdRWDkret1W2pXKpP c84Q== 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=1e14phHEvYl3NdpP4BPy2x93ydqeTJKniBg2GaN5PH4=; b=kOzQASbrRCO3nWrbGhIbfVA66LUpZFfNtY7XH5tsFVJfVeHsvcT5MAwdCcQtWm1/Wj Jqp0r0vIk6ElphWXLWax6aqdveu6YhLh6TbniXC0y+zjIBE97wkvKPIozwB6fZJ0uHw8 tSCSbBA6O7HMM0kkxgQBy/D0RfXaIj8Cx6ajH3W8YD+YK1Dys6AtMlq0xtmC3ZhxM+SU VCIpFYTFRYU2kjRDoiPmAehNixXtp9G09VRMXDEBwxuzU1oJ7WbsXZtrq3RjkHska/rV k52qRWPlx6E52mr+rVBbYYON7X6uPq6ehXzZOv6oUEwrPjRXm9TjSO1Tk4At9jp4CJ5m YLsA== 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 h128-v6si3729184pgc.545.2018.05.17.02.47.42; Thu, 17 May 2018 02:47:56 -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 S1752014AbeEQJrV (ORCPT + 99 others); Thu, 17 May 2018 05:47:21 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:50104 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751468AbeEQJrS (ORCPT ); Thu, 17 May 2018 05:47:18 -0400 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="40038170" Received: from localhost (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 17 May 2018 17:47:14 +0800 Received: from G08CNEXCHPEKD03.g08.fujitsu.local (unknown [10.167.33.85]) by cn.fujitsu.com (Postfix) with ESMTP id E00ED4B3ED60; Thu, 17 May 2018 17:47:08 +0800 (CST) Received: from localhost.localdomain (10.167.226.106) by G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 17 May 2018 17:47:08 +0800 From: Dou Liyang To: , , CC: , , , , , , Dou Liyang Subject: [PATCH 0/1] Remove the check of duplicate processors Date: Thu, 17 May 2018 17:46:57 +0800 Message-ID: <20180517094658.18707-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: E00ED4B3ED60.A3566 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 There is a bug in CPU hotplug code, I have two simple fix method, but I can't ensure which one is better. So sent it out, seek help. We found some processors which have the same processor ID but in different PXM in ACPI namespace. such as this: proc_id | pxm -------------------- 0 <-> 0 1 <-> 0 2 <-> 1 3 <-> 1 ...... 89 <-> 0 89 <-> 1 89 <-> 2 89 <-> 3 ...... So we create a mechanism to validate them. make the processor(ID=89) as invalid. And once a processor be hotplugged physically, we check its processor id. Commit 8e089eaa1999 ("acpi: Provide mechanism to validate processors in the ACPI tables") Commit a77d6cd96849 ("acpi/processor: Check for duplicate processor ids at hotplug time") Recently, I found the check mechanism has a bug, it didn't use the acpi_processor_ids_walk() right and always gave us a wrong result. First, I fixed it by modifying the value with AE_OK which is the standard acpi_status value. https://lkml.org/lkml/2018/3/20/273 But, now, I even think this check is useless. my reasons are following: 1). Based on the practical effect, It works well, and no bug be reported 2). Based on the code, the duplicate cases can be dealed with by if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) That seems more reasonable, let's see the following case: Before the patch, After the patch the first processor(ID=89) hot-add failed success the others processor(ID=89) hot-add failed failed So, What's your idea about it. Dou Liyang (1): acpi/processor: Remove the check of duplicates processor ids drivers/acpi/acpi_processor.c | 126 ------------------------------------------ include/linux/acpi.h | 3 - 2 files changed, 129 deletions(-) -- 2.14.3